--- title: "Django への初めてのパッチを書く" version: 1.9 locale: ja source: https://docs.djangoproject.com/ja/1.9/intro/contributing/ canonical: https://djangodocs.dev/ja/1.9/intro/contributing/ --- # Django への初めてのパッチを書く ## はじめに 少しでもコミュニティへ恩返しをしたいと思われますか? それは Django の簡単なバグフィックスや小さな機能追加かもしれません。 その願いを叶える最適な方法は Django 自体への貢献です。最初は気が重いかもしれませんが、実際はとても簡単です。私達がプロセス全体を詳しく解説するので、その例から学ぶことができるでしょう。 ### このチュートリアルは誰を対象としていますか? > **See also** > > パッチの送り方について知りたい方は、 [Submitting patches](/ja/1.9/internals/contributing/writing-code/submitting-patches/) をご覧ください。 このチュートリアルは、少なくとも Django がどのように動作しているかの基本的な理解があることを想定しています。つまりチュートリアル [初めての Django アプリ](/ja/1.9/intro/tutorial01/) を十分に理解していることを想定しています。また、Python 自体をよく理解している必要があります。もしそうでない場合、 [Dive Into Python](http://www.diveintopython3.net/) は Python プログラマーになるための素晴らしい (かつ無料の) オンラインドキュメントです。 バージョン管理システムと Trac をよく知らない方でも、このチュートリアルとリンク先から、始めるに十分な情報を得ることができます。しかし、Django に定期的に貢献したい場合は、このツールの詳細について知りたいかもしれません。 このチュートリアルでは、できるだけ多くの方が使用できるように可能な限り解説したいと思います。 > **困ったときは:** > > もしこのチュートリアルを通じて理解できないことがあれば、 [django-developers](/ja/1.9/internals/mailing-lists/#django-developers-mailing-list) にメッセージを送るか [#django-dev on irc.freenode.net](irc://irc.freenode.net/django-dev) で他の Django ユーザーとのチャットが助けになるでしょう。 ### このチュートリアルの範囲はなんですか? 初めて Django にパッチを送る手順を詳しく解説します。このチュートリアルを終えると、関連するツールとプロセス両方についての基本的な理解を得ることができます。具体的な範囲は以下の通りです: - Git のインストール - 開発版の Django の複製をダウンロード - Django のテストスイートの実行 - パッチへのテストを書く - パッチのコードを書く - パッチをテスト - 変更のパッチファイルを生成 - より多くの情報を得る方法 チュートリアルを終えたら、次は [Django への貢献](/ja/1.9/internals/contributing/) を参照してください。このドキュメントには、多くの重要な情報が含まれており、Django に定期的に貢献したい方は是非一読してください。あなたの疑問への答えが見つかるはずです。 > **3系の Python が必要です！** > > このチュートリアルは3系のPythonの使用を想定しています。 [Python's download page](https://www.python.org/download/) またはOSのパッケージ管理システムを用いて、最新のバージョンをインストールしてください。 > **Windowsを使用している方へ** > > WindowsにPythonをインストールする際、 "Add python.exe to Path" のオプションにチェックを入れると、コマンドラインからいつでも利用できるようになります。 ## ソースコードの管理 あなたはコントリビューターとして私たちDjangoコミュニティをオープンかつ包摂的なものでありつづけることを援助できます。私たちの ソースコードの管理 \ を参照し、フォローして下さい。 ## Git のインストール このチュートリアルでは、最新の Django 開発版のダウンロードとその変更のパッチファイルを生成するために Git をインストールする必要があります。 Git がインストールされているかどうかを確認するために、コマンドラインで `git` を入力します。もし入っていない場合は、ダウンロード及びインストールするために、 [Git's download page](http://git-scm.com/download) を参照してください。 > **Windowsを使用している方へ** > > WindowsにGitをインストールする際、 "Git Bash" オプションを選択し、シェルからGitが操作できるようにしておくことをおすすめします。このチュートリアルは Git Bash がインストールされていることを想定しています。 もし Git について詳しく知らない場合は、(インストール後に) コマンドラインから `git help` と入力するとコマンドの使い方を確認できます。 ## Django 開発版の複製を取得 Django への貢献の第一歩はソースコードの複製の取得から始まります。コマンドラインで、 `cd` コマンドを使い、Django をローカルに複製するディレクトリに移動します。 以下のコマンドで Django のソースコードリポジトリをダウンロードします: ```console $ git clone https://github.com/django/django.git ``` 今やあなたはDjangoのローカルコピーを手に入れました、"pip"を使ってどんなパッケージでもインストールできるのと同じように、Djangoもインストールできます。Pythonに含まれる機能である *virtual environment* (もしくはvirtualenv)は、プロジェクトごとにインストールされたパッケージが互いに害を及ぼすことないよう、別々のディレクトリで維持することを可能にする、もっとも便利な方法です。 ホームディレクトリの `.virtualenvs/` 以下に、すべてのvirtualenvを 1 箇所においておくといいです。もしまだそのフォルダが存在しないなら作成しましょう。 ```console $ mkdir ~/.virtualenvs ``` それではアプリケーションを実行するために新しいvirtualenvを作りましょう: ```console $ python3 -m venv ~/.virtualenvs/djangodev ``` 新しい環境があるパスはコンピュータに保存されました。 > **Windowsを使用している方へ** > > ビルトインの `venv` は、 Windows 用にはシステムシェル(`.bat`) やPowerShell(`.ps1`)のためだけに作られたアクティベーションスクリプトであるため、WindowsのGit Bash shellを使用していても動作しません。その代わりに\`\`virtualenv\`\`パッケージを使用します: > > ``` > $ pip install virtualenv > $ virtualenv ~/.virtualenvs/djangodev > ``` > **Ubuntuを使用している方へ** > > いくつかのバージョンのUbuntuでは上記のコマンドは失敗するでしょう。まず `pip3` があることを確認し、 `virtualenv` パッケージを使用します。 > > ```console > $ sudo apt-get install python3-pip > $ # Prefix the next command with sudo if it gives a permission denied error > $ pip3 install virtualenv > $ virtualenv --python=`which python3` ~/.virtualenvs/djangodev > ``` virtualenvを有効化すれば設定は終わりです: ```console $ source ~/.virtualenvs/djangodev/bin/activate ``` もし `source` コマンドが使えない場合、代わりに `.` を試してみてください: ```console $ . ~/.virtualenvs/djangodev/bin/activate ``` > **Windowsを使用している方へ** > > Windows上でvirtualenvを有効にするために、実行してください: > > ``` > $ source ~/virtualenvs/djangodev/Scripts/activate > ``` ターミナルの新しいウィンドウを開いたときは、virtualenvを有効にする必要があります。 [virtualenvwrapper](https://virtualenvwrapper.readthedocs.io/en/latest/) はこれをより簡単にできるツールです。 これより `pip` を通じてインストールした何もかもが、他の環境やシステムワイドなパッケージから分離されて、新しいvirtualenvにインストールされます。また、どの環境を使っているのかがわかるように現在有効なvirtualenvの名前がコマンドラインに表示されます。先ほどクローンしたDjangoのコピーをインストールして作業を続行します: ```console $ pip install -e /path/to/your/local/clone/django/ ``` 現在インストールされたDjangoはあなたのローカルコピーを参照しています。あなたが行ったどのような変更も迅速に確認できます、これはあなたが最初のパッチを作成するときの大きな助けになります。 ## 旧リビジョンの Django に戻す このチュートリアルでは、ケーススタディとして [#24788](https://code.djangoproject.com/ticket/24788) を用います。そのために、まず Django のバージョンをパッチが適用される前の git のバージョンに戻します。これによりスクラッチからパッチの作成、 Django のテストスイートの実行を含む全ての手順を解説します。 **チュートリアルでは trunk ではない古いリビジョンの Django を使用しますが、自分のパッチを作成する場合は Django の最新の開発版を使用する必要があります!** > **Note** > > このチケットのパッチは Paweł Marczewski 氏により書かれ、これは [commit 4df7e8483b2679fc1cba3410f08960bac6f51115](https://github.com/django/django/commit/4df7e8483b2679fc1cba3410f08960bac6f51115) で Django に適用されました。よって [commit 4ccfc4439a7add24f8db4ef3960d02ef8ae09887](https://github.com/django/django/commit/4ccfc4439a7add24f8db4ef3960d02ef8ae09887) が適用される前の Django のリビジョンを使用します。 Django のルートディレクトリ (このディレクトリには `django`, `docs`, `tests`, `AUTHORS`, 等が含まれています) へ移動します。次にチュートリアルで使用する Django の旧リビジョンをチェックアウトします。 ```console $ git checkout 4ccfc4439a7add24f8db4ef3960d02ef8ae09887 ``` ## 最初に Django のテストスイートを実行する Django へ貢献する際、変更したコードが Django の他の領域にバグを混入しないことが非常に重要です。変更後に Django の正常動作を確認するには Django のテストスイートを実行します。すべてのテストに合格した場合は、その変更により Django が壊れていないことが確認できます。Django のテストスイートを実行したことが一度もない場合、その出力結果を把握しておくために一度テストスイートを実行しておくことを推奨します。 Django のテストスイートを走らせる前に、まずは Djangoの `tests/` ディレクトリに `cd` で移動して、依存関係をインストールしてください: ```console $ pip install -r requirements/py3.txt ``` テストスイートを実効する準備が出来ました。もし GNU/Linux, Mac OS X 等 Unix 系OSを使用している場合、下記のコマンドを実行します: ```console $ ./runtests.py ``` それでは一息つきましょう。Django 全体のテストスイートは 9600 以上のテストが含まれており、コンピュータの速度により 5 〜 15分程度かかります。 Django のテストスイートを実行中に、各テストの状態を文字のストリームで確認することができます。 `E` はテストにエラーが発生したことを表し、 `F` はテストのアサーションが失敗したことを表しています。これらは共にテスト失敗となります。`x` と `s` はそれぞれ期待する失敗とスキップを表しています。ドットはテストの成功を表しています。 スキップされたテストは、テストを実行するために必要な外部ライブラリがインストールされていないことが原因です; 依存については [Running all the tests](/ja/1.9/internals/contributing/writing-code/unit-tests/#running-unit-tests-dependencies) を参照し、関連するテストを実行してください (このチュートリアルでは必要ありません)。 Once the tests complete, you should be greeted with a message informing you whether the test suite passed or failed. Since you haven't yet made any changes to Django's code, the entire test suite **should** pass. If you get failures or errors make sure you've followed all of the previous steps properly. See [Running the unit tests](/ja/1.9/internals/contributing/writing-code/unit-tests/#running-unit-tests) for more information. If you're using Python 3.5+, there will be a couple failures related to deprecation warnings that you can ignore. These failures have since been fixed in Django. 開発中の､最新の Django ではステーブルとは限りません｡トランクバージョンで開発を行う場合､ [Django の継続インテグレーションビルド](http://djangoci.com) をチェックしてください｡これで､テストの失敗があなたのマシンだけのものか､ Django 公式のビルドによるものかが分かります｡各ビルドについてのリンクをクリックすれば､ "Configuration Matrix" という､ 各 Python のバージョン､ DB バックエンドに対応したテストの失敗を閲覧できます｡ > **Note** > > このチュートリアルや､各チケットで作業する際は､ SQLite のテストで十分です｡しかし可能 (か必要な場合は) [他のデータベースでテストを実行する](/ja/1.9/internals/contributing/writing-code/unit-tests/#running-unit-tests-settings) を参照してください｡ ## チケットにテストを書く 大抵の場合､ Django にアクセプトされるパッチはテストを含んでいます｡リグレッションテストを書くことで､ Django にバグを再混入していないと後に保証できます｡レグレッションテストは､バグが存在しているときに落ちるように書き､バグが修正された後にパスするように書かれるべきです｡新機能を含むパッチでは､その新機能が正しく動作すると保証するためにテストが必要です｡その際も同じように､新機能が無い際には落ち､実装されてから通るテストを書くべきです｡ これをするには､コードに変更を加える前に先にテストを書くのが良いでしょう｡この開発手法は [テスト駆動開発](https://en.wikipedia.org/wiki/Test-driven_development) と呼ばれ､プロジェクト全体にも単一のパッチにも適応可能です｡テストを書いた後には､テストを走らせて確かに落ちることを確認します (バグ修正や昨日の追加はまだしてないので落ちます)｡ 新しいテストが落ちない場合は落ちるよう修正しましょう｡ともかく､バグが存在していようとも通るテストは将来バグが再発するのを防ぐのに､何の役にもたちません｡ ハンズオンでの例題 ### チケット #24788 にテストを書いてみましょう チケット [#24788](https://code.djangoproject.com/ticket/24788) は、Formクラスにおいてクラスレベルの属性 `prefix` を指定可能にするという小さな機能追加を、このように提案しています: ``` […] forms which ship with apps could effectively namespace themselves such that N overlapping form fields could be POSTed at once and resolved to the correct form. ``` このチケットを解決するには､ `prefix` 属性を `BaseForm` に追加します｡このクラスのインスタンスを作成する時、 `__init__()` メソッドに `prefix` を渡すと、作成されたインスタンスに `prefix` がセットされます。 しかし `prefix` を渡さない(または `None` を与える)場合、クラスレベルのprefixが使用されます。変更を加える前に､変更が正しく動作し､これからも動作し続けることを確認するためにテストをいくつか追加します｡ Django の `tests/forms_tests/tests/` フォルダに移動して `tests_forms.py` ファイルを開きます。以下のコードを test\_forms\_with\_null\_boolean \`\` 関数の直前の 1674 行目に追加します: ``` def test_class_prefix(self): # Prefix can be also specified at the class level. class Person(Form): first_name = CharField() prefix = 'foo' p = Person() self.assertEqual(p.prefix, 'foo') p = Person(prefix='bar') self.assertEqual(p.prefix, 'bar') ``` この新しいテストは、 クラスレベルの `prefix` が期待通りに設定されていることと、インスタンスの生成時にまだ `prefix` パラメータが渡されていることを確認します。 > **でもテストをするのはすこし難しそうです……** > > テストを書いたとこがない場合は､最初は難しく見えるかもしれません｡ですが実は､テスティングはプログラミングにおいて *とても* 重要なことです｡ここではテストについて詳細に紹介します｡ > > - Django のための良いテストの書き方は [Writing and running tests](/ja/1.9/topics/testing/overview/) のドキュメントに記載されています。 > - Dive Into Python (Python初心者のための､オンラインの無料の本) では素晴らしい [初めてのユニットテスト](http://www.diveintopython.net/unit_testing/index.html) という章があります｡ > - After reading those, if you want something a little meatier to sink > your teeth into, there's always the Python [`unittest`](https://docs.python.org/3/library/unittest.html#module-unittest) documentation. ### 新しいテストを走らせる ```BaseForm `` にはまだ変更を加えていませんので､テストは落ちます｡ ``forms_tests `` フォルダの全テストを走らせて､実際に何が起こるか観てみましょう｡コマンドラインで ``tests/``` ディレクトリに `cd` して､以下を実行してください: ```console $ ./runtests.py forms_tests ``` テストが正しく実行されれば､追加したテストメソッドに対応する1つのテストが失敗するでしょう｡テストがすべて通れば､上記した新しいテストを正しいフォルダ､クラスに追加したことを確認してください｡ ## チケットにコードを書く 次は :ticket:24788 \` で説明されている機能を Django に追加します｡ ### チケット #24788 のコードを書いてみましょう `django/django/contrib/forms` フォルダーに行って､ `forms.py` ファイルを開いてください｡ 72行目にある `BaseForm` クラスを見つけて､以下の `prefix` クラス属性をすでにある `field_order` 属性の下に追加してください: ``` class BaseForm(object): # This is the main implementation of all the Form logic. Note that this # class is different than Form. See the comments by the Form class for # more information. Any improvements to the form API should be made to # *this* class, not to the Form class. field_order = None prefix = None ``` ### テストが通ることを確認する Django への変更が完了したあと､コードが正しく動作すると確認するため､先ほど書いたテストを実行してください｡Djangoの `form_tests` フォルダーに `cd` で移動して､以下を実行してください: ```console $ ./runtests.py forms_tests ``` あぁ､テストを書いていて良かったですね｡以下のように1つテストが落ちています: ``` AssertionError: None != 'foo' ``` ```__init__``メソッドの中に条件文を追加するのを忘れていました。``django/forms/forms.py``` の87行目の\`\`self.prefix = prefix\`\`を参照して変更します。条件文を追加しましょう: ``` if prefix is not None: self.prefix = prefix ``` 再実行すればテストがすべてパスするはずです｡もしそうでない場合､ `BaseForm` クラスと新しいテストが正しくコピーされているされていると確認してください｡ ## Django の テストスイートをもう一度走らせる パッチとテストが正しく動作していることを確認できたら､ Django のテストをすべて走らせて､変更が Django の別の場所にバグを仕込んでいないか確認しましょう｡すべてのテストが通るという事は､追加したコードがバグフリーだと保証します｡大量のバグや手戻りを発見できます｡そうでないとバグを見逃してしまうでしょう｡ Django の全てのテストスイートを走らせるには `cd` で Django の `tests/` ディレクトリ移動して実行してください: ```console $ ./runtests.py ``` どのテストも失敗していない間は、作業を続けることができます。 ## ドキュメントを書く この機能は新しいので､ドキュメントに書かれるべきです｡ `django/docs/ref/forms/api.txt` の 1068行目 (ファイルの最後) に追記してください: ``` The prefix can also be specified on the form class:: >>> class PersonForm(forms.Form): ... ... ... prefix = 'person' .. versionadded:: 1.9 The ability to specify ``prefix`` on the form class was added. ``` この新機能は将来のリリースに含まれるとともに、Django 1.9のリリースノート、ファイル `docs/releases/1.9.txt` 164行目以降の"Forms"のセクションに追加されています。 ``` * A form prefix can be specified inside a form class, not only when instantiating a form. See :ref:`form-prefix` for details. ``` ドキュメントの書き方についてもっと知りたい場合は [Writing documentation](/ja/1.9/internals/contributing/writing-documentation/) を参照してください｡ここでは､ versionadded\` の書き方についてや､ ドキュメントのコピーをローカルでビルドしてみて､ HTML をプレビューする方法などが書かれています｡ ## 変更のパッチを生成する Trac にアップロードされたり､他のDjangoに適応されるパッチを作りましょう｡パッチの内容を見るために､以下のコマンドを実行してください: ```console $ git diff ``` チュートリアルの初めでチェックアウトした最初のリビジョンと､(修正した) 現在の Django のコピーとの違いを表示します｡ パッチを見終わったら､ `q` キーをタイプしたコマンドラインに戻りましょう｡パッチの内容が良さそうなら､以下のコマンドを実行して､現在のワーキングディレクトリにパッチを保存してください: ```console $ git diff > 24788.diff ``` Django のルートディレクトリに `24788.diff` というファイルが作られるでしょう｡このパッチは変更のすべてを含んでおり､このようになります: ```diff diff --git a/django/forms/forms.py b/django/forms/forms.py index 509709f..d1370de 100644 --- a/django/forms/forms.py +++ b/django/forms/forms.py @@ -75,6 +75,7 @@ class BaseForm(object): # information. Any improvements to the form API should be made to *this* # class, not to the Form class. field_order = None + prefix = None def __init__(self, data=None, files=None, auto_id='id_%s', prefix=None, initial=None, error_class=ErrorList, label_suffix=None, @@ -83,7 +84,8 @@ class BaseForm(object): self.data = data or {} self.files = files or {} self.auto_id = auto_id - self.prefix = prefix + if prefix is not None: + self.prefix = prefix self.initial = initial or {} self.error_class = error_class # Translators: This is the default suffix added to form field labels diff --git a/docs/ref/forms/api.txt b/docs/ref/forms/api.txt index 3bc39cd..008170d 100644 --- a/docs/ref/forms/api.txt +++ b/docs/ref/forms/api.txt @@ -1065,3 +1065,13 @@ You can put several Django forms inside one ``
`` tag. To give each >>> print(father.as_ul())
    • + +The prefix can also be specified on the form class:: + + >>> class PersonForm(forms.Form): + ... ... + ... prefix = 'person' + +.. versionadded:: 1.9 + + The ability to specify ``prefix`` on the form class was added. diff --git a/docs/releases/1.9.txt b/docs/releases/1.9.txt index 5b58f79..f9bb9de 100644 --- a/docs/releases/1.9.txt +++ b/docs/releases/1.9.txt @@ -161,6 +161,9 @@ Forms :attr:`~django.forms.Form.field_order` attribute, the ``field_order`` constructor argument , or the :meth:`~django.forms.Form.order_fields` method. +* A form prefix can be specified inside a form class, not only when + instantiating a form. See :ref:`form-prefix` for details. + Generic Views ^^^^^^^^^^^^^ diff --git a/tests/forms_tests/tests/test_forms.py b/tests/forms_tests/tests/test_forms.py index 690f205..e07fae2 100644 --- a/tests/forms_tests/tests/test_forms.py +++ b/tests/forms_tests/tests/test_forms.py @@ -1671,6 +1671,18 @@ class FormsTestCase(SimpleTestCase): self.assertEqual(p.cleaned_data['last_name'], 'Lennon') self.assertEqual(p.cleaned_data['birthday'], datetime.date(1940, 10, 9)) + def test_class_prefix(self): + # Prefix can be also specified at the class level. + class Person(Form): + first_name = CharField() + prefix = 'foo' + + p = Person() + self.assertEqual(p.prefix, 'foo') + + p = Person(prefix='bar') + self.assertEqual(p.prefix, 'bar') + def test_forms_with_null_boolean(self): # NullBooleanField is a bit of a special case because its presentation (widget) # is different than its data. This is handled transparently, though. ``` ## 次はどうしましょうか? おめでとうございます! Django への最初のパッチができました! パッチの書き方を習得したので､ Django のコードベースを改善するためにスキルを活かしましょう｡パッチを生成して､Tracのチケットに貼り付けるのは便利ですが､ git を使っている場合は､ [git ワークフロー](/ja/1.9/internals/contributing/writing-code/working-with-git/) の利用がオススメです｡ 変更をローカルでコミットしなかった場合は､ git のブランチを始めに戻すために以下を実行してください: ```console $ git reset --hard HEAD $ git checkout master ``` ### 新しい貢献者のための情報 Django へのパッチを書き始める前に､貢献するために見ておいたほうがいい情報があります: - Django のドキュメントの [チケットをクレームして､パッチを送信する](/ja/1.9/internals/contributing/writing-code/submitting-patches/) を読んでください｡ Trac でのエチケットやチケットをクレームする方法やパッチに適切なコーディングスタイルなど､重要なことを網羅できます｡ - Django への初めての貢献者は [初めての貢献者へのドキュメント](/ja/1.9/internals/contributing/new-contributors/) を読んでください｡Django に初めて協力する人たちへの良いアドバイスがあります｡ - 貢献について､より多くの情報を知りたいなら､ [貢献についての Django のドキュメント](/ja/1.9/internals/contributing/) を参照してください｡そこにはたくさん有用な情報がありまし､質問があれば､このドキュメントが1番役に立ちます｡ ### 実際にチケットを探してみましょう ドキュメントをたくさん読んだ後は､実際のパッチを書けるのでチケットを探してみましょう｡ "easy picking" タグが付いたチケットを見つけてください｡このチケットは大抵はより簡単なものなので､初めての貢献者には適切でしょう｡ Django への貢献に慣れてきたあとは､難しく､複雑なチケットを書き始めれるでしょう｡ 今すぐ始めたいなら (責める人はいません！)、　[パッチが必要な簡単なチケット](https://code.djangoproject.com/query?status=new&status=reopened&has_patch=0&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority) か [パッチに改善が必要な簡単なチケット](https://code.djangoproject.com/query?status=new&status=reopened&needs_better_patch=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority) を見つけましょう。テストを書きなれているなら [テストが必要な簡単なチケット](https://code.djangoproject.com/query?status=new&status=reopened&needs_tests=1&easy=1&col=id&col=summary&col=status&col=owner&col=type&col=milestone&order=priority) でもよいでしょう。ただ、チケットのクレームに関するガイドラインに従ってください。 Django ドキュメントの [チケットをクレームしてパッチを送る](/ja/1.9/internals/contributing/writing-code/submitting-patches/) で記述されています。 ### 次は何をしましょうか？ チケットにパッチが追加されたあとは、別の人間の目でレビューされる必要があります。パッチをアップロードしたりプルリクエストを送信したあとは、チケットのメタデータから "has patch" フラグを設定してください。 "doesn't need tests" や、その他のメタデータはレビューのためにあります。貢献する際にはいつもスクラッチからパッチを書くというわけではありません。既存のパッチをレビューすることをまた素晴らしく役に立つ貢献です。詳細は [Triaging tickets](/ja/1.9/internals/contributing/triaging-tickets/) を参照してください。