$ git checkout -b freds_fixbug42
$ git am --keep-cr --ignore-whitespace < their-patch-file.patchパッチの供給やClojureコントリビューションに興味がある場合は、開発の概要を参照してください。
スクリーニングの仕事は、BDFLが問題と提案された解決策を効率的にレビューし、組み込むことを検討できるように、ハイクオリティな問題と解決策のストリームを作成することです。このページでは一般的な用語「スクリーニング」を使用していますが、実際にはワークフローのステップの特定の場所に、コミュニティーとClojureコアチームが価値を提供できる場合があります。
トリアージ - 受信したチケットの評価（通常はAsk Clojureの質問に応えて作成されたもの）
ベッティング - 優れた「問題」を表すチケットの提出
スクリーニング - 「解決策」についてチケットとパッチを評価する
これらの異なるプロセスは、焦点は異なりますが、遭遇した問題に関する優れたストーリー、検討された解決策、パッチを伴う最終的に選択されたアプローチを示すチケットを作るという共通の目標があります。
JIRAのバグとしてマークされたチケットは、Clojureが正しく動作せず、通常はドキュメント文字列またはその他のドキュメントに従って誤った結果が生じる問題について説明する必要があります。優れたJIRAバグには次が必要です。
問題を説明する概要（タイトル）で（提案された解決策ではなく）、次のすべてが該当する場合、それらを含む説明
症状 - 問題を示すユーザーが目に見えるもの - これはしばしばトップにありますが、実際の問題が理解されるにつれて、履歴を保持するためにコメントに移動される場合があります
問題 - 問題がわかっていれば、その問題の文
実際の結果 - 実際に起こったこと
予想される結果 - 起こるべきだったこと
再現 - 簡潔なインライン再現（できればGitHubリポジトリでも、gistでも、リンクでもない）
原因 - 予期しないことが起こった理由
代替案 - 問題を解決し、それらの間のトレードオフを行う方法
提案 - 提案された解決策とそのスクリーニングの考慮事項
パッチ - 提案を実装するパッチの名前
新しいチケットの閲覧者にチケットの上から下まで読むことで、バグの起因、問題、解決策を考え出す思考、パッチで選択したソリューションについて理解することが期待されています。
改善のチケットは、「バグ」のチケットと一般的に似ていますが、これはエンハンスメントを求めているため、再現が不足する可能性があります。注目すべき主な点は、このエンハンスメントが重要である、あるいは持つ価値がある理由です。一般に、ユーザーが目標を達成するために必要となる新しい能力を提供するエンハンスメントに重点を置いていますので、やりたいことと、既存の能力ではそれができない理由を記載してください。
「改善」と「新機能」の境界線はやや曖昧で、それほど心配する必要はありません。
人気のあるユーティリティライブラリにすでに存在する関数またはユーティリティを提案する場合、チケットには既存の実装に関する調査を含める必要があります。既存の実装とどう異なるのか、どの程度人気があるのか、どの程度の能力があるのかなど。
改善のチケットは「何かを追加する」のではなく、問題に焦点を当てるほど、より多くの代替案が提案でき、最終的なソリューションがより良くなります。
トリアージ、事前審査、審査のチケットに取り組む場合は、アサイン担当者のフィールドを自分自身に設定してください。アサイン担当者がすでに誰かに設定されている場合は、チケットシステム外でpingを送信するか、コメントしてまだそのチケットを見ているかどうか尋ねてください。数日以内に応答がない場合は、アサイン担当者を変更できます。完了したら、アサイン担当者のフィールドのチェックを解除してください。
全体像の質問は、「これは有効なバグ/リクエストですか?」です。
トリアージのチェックリスト
問題は、バグ(既存機能における問題)、改善(既存機能の拡張)、または新機能(新しい機能)として正しく分類されていますか?
(改善)チケットは、提案がなぜ重要で、影響の範囲を示していますか?たとえば、https://grep.appなどのツールを使用して、パブリックコードベースで提案されたユーティリティ関数の検索頻度を調査します。
(バグ)チケットには、期待される結果と実際の結果を含む再現が含まれていますか?
現在のClojureのバージョンで問題を再現できますか?
これは既存の問題の重複ですか?
問題は実際には複数の問題ですか?
ラベルは正しいですか?既存のラベルを使用し、最後の手段として新しいラベルのみを作成してください。
利用可能なアクション
コメントを書いて、何をすべきだと考えるかについて記入する
上の問題に対処するためにチケットフィールドを変更する
複数問題ある場合は、新しいチケットを作成し、複数チケットに分割して、適切にリンクする
問題がなければ、承認フィールドをトリアージ済みとしてマークする(コメントも残す)
トリアージの準備ができたチケット: CLJ open
全体像の質問は、「これは明確に記載された問題ですか?」です。
ベッティングのチェックリスト
トリアージチェックリストのすべて(行われていない場合)
問題の記述はありますか?
記載された問題は実際に問題であり、やるべきことや解決策ではありませんか?
問題/リポジトリ/原因/代替案/提案/パッチに記載は適切に分離されていますか?
優先度のフィールドを確認する。優先度は高くなりますか、それとも低くなりますか?影響を受ける人は何人いますか?影響を受ける場合、重大度はどの程度で、回避策はありますか?
問題のパフォーマンス面に関するベンチマークと、問題を明らかにするタイミング情報があれば提示してください。（後からタイミングを再現するための十分な情報が必要です）
利用可能なアクション
コメントを書く - 審査の準備かと思われる場合、コメントにその旨を記入してください。範囲や重大さのため、注意を引く必要がある場合は、コメントにその旨を記載してください。
上記のなりすましに対処するため、記述やその他のフィールドを修正してください
確認するチケット
CLJ 1.12 候補 - 1.12 の候補を厳選したセット
ここで重要なのは、「これは問題に対する良い解決策ですか？」という質問です。
場合によっては、リッチによる審査の前に、チケットが「良い解決策かどうか」を考慮して「事前スクリーニング」を行います。これにより、この作業を前倒しすることで、プロセス後半の特定の問題を解決することができます。
注記：パッチを作成した場合は、チケットの事前スクリーニングやスクリーニングを行うべきではありません。さまざまな観点が必要です。
スクリーニングチェックリスト
審査チェックリストのすべて
原因 - 問題が分かると、できる限り明確に問題の原因を説明してください
代替案 - すべての問題に対する複数の代替解決策を提示してください（特に新機能）。常に存在する 1 つの代替案、「何もしない」を忘れないでください。問題を使用して、代替案を比較する基準を考え出してください。パフォーマンス、後方互換性、変更が発生する場所などを含む点を考慮してください。
提案された解決策 - 選択した代替案の詳細と、考慮された基準全体でそれが最善である理由を再提示してください。提案された解決策セクションは、レビュアーがコードを見た時点で驚かないような、パッチの側面を網羅する必要があります。
パッチ - パッチの評価を参照してください
パフォーマンス - チケットには十分なパフォーマンスの検討が含まれていますか？ベンチマークが必要な場合は、ベンチマークと前後のタイミングを含めてください。そのデータが含まれている場合は、ご自身のマシンで確認してください。
提案されたセクションには、後続のレビュアーがパッチで確認するすべてが完全に説明されていますか？
パッチ - 提案されたパッチの名前が記載されていますか？（自明なことのようですが…実際のところそうでないので、他のパッチが唯一のパッチであっても、常に明示的に記載してください）
確認するチケット
CLJ 1.12 候補 - 1.12 の候補を厳選したセット
CLJ スクリーニング可能 - ここでのチケット本文の変更前に、コアチームと調整してください（コメントは常に可能）
他の人による変更を適用するには、ブランチを作成してそこに変更を適用するのが最善です
$ git checkout -b freds_fixbug42
$ git am --keep-cr --ignore-whitespace < their-patch-file.patchパッチが適用されるファイルに DOS の CR/LF 行末が含まれている場合、--keep-cr が役立ちます。必要ない場合は害がないようですが、問題が発生する疑いがある場合は、オフにするか --no-keep-cr を使用してください。
--ignore-whitespace は、パッチの作成以降、マスターに対して行われた唯一の変更がコンテキストラインの空白の場合に役立ちます。このオプションがなければ、パッチが適用されない場合があります。このオプションを使用すると、スクリーナーはマスターで空白が変更されたという理由だけで、コントリビューターがパッチを更新する必要を回避するのに役立ちます。
コントリビューションライブラリコントリビューションを確定するためにこのプロセスに従っている場合は、代わりにこれを使用してください
$ git am --keep-cr -s --ignore-whitespace < their-patch-file.patch-s はコミットを承認していることを示します。スクリーニングには必要ありません。
パッチ評価チェックリスト
.patch ファイルですか（.diff ではなく）？
パッチの作者はコントリビューターですか？そうでない場合は、パッチを考慮できません。
パッチに適切なコミットコメントがありますか？「CLJ-1234 - 説明」の形式で、説明は問題に焦点を当てる必要があります。ソリューションの詳細がさらに含まれている場合は、ヘッダー行の後に続くはずです。一般に、より詳細を配置する場所はコミットコメントではなくジラに依存していますが、それらも問題ありません（正しいと仮定します！）。
git applyを使用してローカルにパッチを適用します（空白の警告はありますか？必ずしも大したことではありませんが、考慮してください）
mvn clean testを実行 - すべてのテストが合格する必要があります
パッチにテストが含まれていますか？
デフォルトでは、テストコードは直接リンクを使用してコンパイルされます。変更に直接リンクがない場合に問題が発生する可能性がある場合は、mvn -Ptest-no-direct clean testも実行します
テストは過剰ですか（実装の詳細への依存をもたらしますか）？
新しい名前空間（srcまたはテスト）がある場合は、それらをコンパイルリストに追加する必要がある場合があります - build.xmlを更新します
既存のコアマクロに対する変更は、新しい関数を呼び出すべきではありません（これは、古いランタイムで実行されている新しいコンパイルコードとの互換性の問題を引き起こします）
既存のコアマクロの変更は仕様に影響を与える可能性があります。その場合、これは考慮する必要があり、個別のcore.specsパッチが必要になる場合があります
Javaインターオペレーションを含む変更は、Javaリフレクションをチェックする必要があります（通常、インターオペレーションを持つClojure名前空間の先頭に(set! warn-on-reflection true)を追加することをお勧めします）
新しいpublic関数は、:addedメタデータを持つ必要があります
元のレプロに戻り、適用されたパッチを適用して再実行します - パッチは問題を修正しますか？
差分を読み取ります（単独または適用したものとして）。提案されたソリューションと一致することを確認します。驚くべき新機能がある場合は、チケットまたはパッチを更新する必要があります。
パッチは、周囲のコードのスタイルとコーディングガイドラインと一致しますか？（これらは単なるガイドラインであり、宇宙の固定された法則ではありません。）
ドキュメントは依然として正しいですか？
本体に型ヒントを持つインライン関数は、インライン関数でも何かが必要です