開発者向けページ¶
このページでは、パッチ、統計テスト、新しいモデル、またはサンプルを提出することによって、statsmodels の開発に貢献する方法について説明します。
statsmodels は、Github で Git バージョン管理システムを使用して開発されています。
バグレポートの提出¶
問題を再現する、短く自己完結型のコードスニペットを含めてください。
使用したstatsmodelsのバージョンを指定してください。これは
sm.version.full_versionで確認できます。問題が他の依存関係に関連していると思われる場合は、
sm.show_versions()の出力も含めてください。
コードの変更¶
まず、gitバージョン管理システムの概要については、statsmodelsのコードの扱い のセクションを確認してください。
プルリクエストが受け入れられるためには、以下の要件を満たす必要があります。これは、ソフトウェアの保守とリリースを共同作業で行う上で非常に役立ちます。
1つのブランチ。1つの機能。 ブランチは安価で、githubでは数回のクリックでブランチをマージおよび削除するのが簡単です。可能であれば、機能に取り組む際に無関係な変更をまとめて行うことは避けてください。これにより、リリースを準備する際に、何が変更されたかを追跡しやすくなります。
コミットメッセージは明確かつ簡潔である必要があります。これは、80文字未満の件名行、および必要に応じて、空行に続いてコミットメッセージ本文が続くことを意味します。非公式なコミット形式標準があり、これを守るように努めています。実際にどのように見えるかは、
git log --oneline -n 10で確認できます。コミットが特定の問題を参照または解決する場合は、コミットメッセージで言及することで、問題を解決できます。（メンテナ向け：これらの提案は、マージコミットコメントにも当てはまります。これらは、リリースノートの記録の一部です。）コードの提出には、必ずテストを含める必要があります。テストに関する注意事項を参照してください。
各関数、クラス、メソッド、および属性は、docstringを使用してドキュメント化する必要があります。numpy docstring標準に準拠しています。
新しい機能を追加する場合は、
docs/sourceの適切なファイルを編集（または作成）して、ドキュメントに追加する必要があります。ドキュメントの変更が正しく解析されることを確認してください。トップレベルの
docs/ディレクトリに移動して、次のように入力します。make clean make html変更によって、ビルド出力に警告がまったくないことを確認してください。
ドキュメントを生成するには、追加の依存関係が必要です。詳細については、
docs/README.mdを参照してください。可能な限り、PEP8 スタイルガイドラインに従ってください。
LINT=true ./lint.shを実行して、コードをlintします。git diff upstream/mainを実行して、変更をmainの内容と比較します。最後に、リリースノートに変更内容を追加してください。次のリリースのバージョン番号を持つ
docs/source/release/versionX.X.rstファイルを開き、適切なセクションに変更内容を追加します。
プルリクエストの提出方法¶
statsmodels にパッチを提出したいが、githubにあまり慣れていない場合、必要な手順は次のとおりです。
Githubで statsmodelsリポジトリをフォークします。
新しい機能ブランチを作成します。各ブランチは、1つの新しい機能またはバグ修正を含む自己完結型である必要があります。
テストスイートが合格することを確認してください。これには、Python 3でのテストが含まれます。これを行う最も簡単な方法は、プルリクエストを作成して、ボットに確認させることです。これは時間がかかる可能性があり、修正または機能拡張について不明な場合は、pytestをローカルで実行するのが最善です。
プルリクエストは、コードベースに受け入れられる前に、徹底的にレビューされます。プルリクエストが古くなった場合は、中央リポジトリの最新バージョンにプルリクエストをリベースしてください。
メーリングリスト¶
開発に関する会話は、statsmodelsメーリングリストで行われます。
ライセンス¶
statsmodelsは、Modified（3条項）BSDライセンスの下でリリースされます。