貢献

貢献の基本

  • 貢献する方法は、質問する、問題を報告する、ディスカッションに参加する、新機能を提案する などと簡単です。 これらはすべて貴重です! 貢献する方法はたくさんあります。 また、qteasy を *使用して行った創造的なこと (コードとプロット イメージの両方) を共有していただければ、とても感謝しています。 そしてもちろん、qteasy のコードを書くことも貢献する素晴らしい方法です。 ありがとう。

  • 通常のオープンソース貢献ガイドラインがすべて適用されます (たとえば、オープンソース貢献ガイド を参照)。 そこで、このページではqteasyのこだわりと思われる項目をほんの少しだけ記載させていただきます。

問題の報告

  • 問題の明確な説明と、作業している環境の情報を提供してください。できれば、バグ レポート テンプレート を使用し、説明に次のセクションを含めてください。

    • あなたの期待: 問題が発生したときに達成しようとしていることを説明します

    • あなたの方法: 期待される結果が得られると思われるコードを提供してください

    • 結果: あなたのメソッドで実際に得られるものを説明し、エラー メッセージを提供します

    • あなたの環境: あなたのマシン、OS、依存関係パッケージのバージョンについて教えてください。

    • 設定: qteasy 設定とローカル データソースの概要を印刷します。

    • 再現方法: 根本原因を突き止めるために、問題を再現するための例を提供してみてください。

例を提供し、ドキュメントを改善する

  • 例を提供していただいたり、ドキュメントの改善にご協力いただければ大変感謝いたします。

    • 戦略の例

    • コードスニペット

    • 視覚化

    • 誤りの訂正

  • 以下のフォーク / クローン / プル リクエスト ワークフローに従って、qteasy に貢献してください。できるだけ早くフィードバックするよう努めます。

フォーク/クローン/プル リクエストのワークフロー

  • GitHub に貢献するための標準ワークフローは フォーク/クローン と呼ばれます。 よく知らない人のために、簡単な概要といくつかの参考リンクをここに示します。

    • git の基本: git clone、git commit など に精通していることを前提としています。

  • 注: 「フォーク」とは、GitHub 上で作成され、GitHub 上に存在する単なる git clone です。 GitHub の Fork ボタンを使用してフォークを作成します。これにより、GitHub は元の Github リポジトリとフォークの間の関係を追跡できるようになります。

  • 基本的なワークフローは次のとおりです。

    1. qteasy リポジトリの フォーク を作成します。 (詳細については、以下の参考資料を参照してください。) フォークは あなたの github アカウントの下に存在します。

    2. クローン あなたの フォークをローカル マシン (git clone) に作成します。

    3. リポジトリの複製コピーを操作し、変更を git commit して、git push それらを GitHub フォーク に追加します。

    4. フォーク内のコードに満足したら、フォークの GitHub ページで プル リクエスト (PR) を開きます。 プル リクエストは、フォーク内の変更をメインの qteasy リポジトリにプルすることを効果的に要求します。 PR は、github 上で変更を確認し、それに関するコメントやディスカッションを投稿できる場所を提供します。

    5. コードレビュー後、メンテナから追加の変更を求められた場合、(元の PR がまだ開いている限り) 別のプル リクエストを再入力する必要は「ありません」。 むしろ、ローカル クローンに変更を加え、再度フォークに git push するだけです。 変更は、開いているプル リクエストに自動的に流れ込みます。

    6. 完了すると、リポジトリの管理者がフォークからの変更を qteasy リポジトリにマージします。 PR は自動的に閉じられます。 (ただし、フォークは引き続き存在し、将来追加のプル リクエストに再度使用できます。フォークを最新の状態に保つ方法については、GitHub ドキュメントを参照してください)。

  • 参考文献:

  • GitHub ドキュメント

    • https://docs.github.com/en/get-started/quickstart/contributing-to-projects

  • そしていくつかのユーザーの要点

    • https://gist.github.com/Chaser324/ce0505fbed06b947d962

    • https://gist.github.com/rjdmoore/ed014fba0ee2c7e75060ccd01b726cb8

コーディング標準

  • 私は PEP 8 のあらゆる側面を厳守するわけではありませんし、寛大でもありません。 私は道の真ん中を歩く傾向があります。何かが良くて一般的なものであれば、それは遵守されるべきです。

  • 特に気になる項目をいくつか挙げておきます。

    • コードを記述する場合は、インデントにタブを使用しないでください。 スペースを 4 つ使用します。

    • コードを作成する場合は、コードが何を行っているかを説明する明確かつ簡潔なコメントを常に提供してください。 これは、すぐには分からないコードの場合に特に重要です。

    • 重要な機能、つまり、その使用法を説明するのに数文以上かかる機能を追加する場合は、その機能の「チュートリアル ノートブック」も作成してください。 **[チュートリアル ノートブックの例については、サンプル フォルダー内の jupyter ノートブックを参照してください。]

    • 重要な機能を追加する場合は、他の回帰テストと同様に、回帰テスト ファイル テスト フォルダー内 も作成してください。 多くの場合、これを行う最も簡単な方法は、機能の「チュートリアル ノートブック」 からいくつかの例を取り上げることです (前のポイントを参照)。

    • 既存のコード ファイルで作業する場合は、そのファイルにすでに存在するスタイルを多かれ少なかれエミュレートするようにしてください。