ライセンスと著作権¶
プログラム コードを提供する場合、特別な合意がない限り、その変更や新しいプログラム コードはリポジトリが使用しているライセンスと同じライセンスで提供することに同意したものとみなされます。
参考
Weblate のライセンス では、ライセンスについて詳しく説明しています。
良いパッチを書くために¶
変更は分割して記述する¶
11 個の問題を修正したとされる巨大なパッチを受け取っても、そのうち 10 個は議論で合意できなかったり、9 個はすでに別の方法で修正されていたりすると、とても扱いづらくなります。
理想的には、各修正は個別の パッチ / コミット として分け、何を修正したのか明確な説明を付けるべきです。そうすることで、保守担当者や他の関係者が必要な変更だけを選択して適用できます。
また、変更が分割されていると、将来的な問題やバグの再発調査のための二分法がはるかに容易になります。
ドキュメント¶
ドキュメント作成は面倒な作業ですが、誰かが必ず完成させる必要があります。プログラム コードの変更と同時にドキュメントを提出していただければ、作業がとても楽になります。メソッド、複雑なコードブロック、ユーザーに見える機能についても必ずドキュメントを作成してください。
テストケース¶
テストにより、機能が想定どおりに動作していることを迅速に確認できます。この状況を維持し、改善するためには、追加されるすべての新機能と関数をテストスイートでテストすることが必要です。追加されたすべての機能には、ドキュメントどおりに動作することを検証する有効なテストケースが最低 1 つ必要です。
コミットメッセージ¶
Git コミットは Conventional Commits 仕様に従う必要があります。
型チェック¶
新しいコードでは、PEP 484 の型ヒントを使用してください。Weblate では mypy を使用して型チェックを行っています（Django アプリの型チェックを可能にするプラグインがあるため）。
コードベース全体が型アノテーションで完全にカバーされているわけではありませんが、一部のモジュールは CI で型チェックが強制されています。
コーディング規約と低品質コードの検出¶
コードは PEP 8 コーディング規約に従い、ruff コード整形ツールを使用して整形してください。
コードの品質を検査するには、ruff を使用できます。その設定は pyproject.toml に保存されています。
これを実行する最も簡単な方法は、pre-commit をインストールすることです。リポジトリには、コミットされたファイルが正常であることを確認するための設定が含まれています。インストール後（pre-commit は、すでに pyproject.toml に含まれています）、Weblate の実行フォルダで pre-commit install を実行して有効にします。これにより、すべての変更が自動的に検査されます。
手動で検査を実行し、すべてのファイルを検査する方法:
pre-commit run --all
セキュア コーディング¶
Weblate のコードはすべて、 セキュリティ設計原則 を念頭に記述してください。
AI ガイドライン¶
プロジェクトにコンテンツを投稿する場合、その内容をそのまま使用する許可を Weblate に与えることになります。また、そのコンテンツを提供する権利が自分にあることの確認が必要です。変更を提出することで、その変更がプロジェクトに採用され、プロジェクトのライセンスのもとで再配布されることに同意したものとみなされます。作成者は、ライセンスのないコードをプロジェクトに提出しないよう徹底する責任があることを明確に認識しておくことが必要です。
これは AI を使用したかどうかに関係なく適用されます。
プルリクエストを提出する際は、もちろん、提案が質の高いものであり、ガイドラインに沿った最善の努力に基づいていることを確認してください。一般的な目安として、AI の助けを借りて提出されたことが誰かに分かる場合は、まだ改善の余地があるということです。
AI の助けを借りて記述されたコードをプロジェクトで採用することもありますが、コードはコーディング標準規約に従い、明確に記述され、文書化され、テストケースを備え、通常の要件をすべて満たしていることが条件です。