Issue と PR の優先順位を明記する（マイルストーンまたはプロジェクトボードを利用する）

[Takym]

その機能リクエストは何らかの問題に関連しますか

今の状態ではどの Issue または PR が優先的に解決されるべきか分かり難いです。優先順位が明示されていれば、優先順位の高い項目で活発に議論が行われる様になり、また、解決策となる PR も早い段階で作成されるだろうと思います。PR ではマージされない理由が、不十分であるのか優先順位が低いのか分からず、作成者の対応が難しい状態になっています。不十分である場合にはコメントが投稿される事も承知しています。

解決策についてお書きください

GitHub にはマイルストーンという機能があり、登録された Issue や PR の進捗状況を確認する事ができます。優先順位毎にマイルストーンを作成して、Issue や PR を登録します。

あなたが考える代替案についてご説明ください

マイルストーンより高度な機能を持つプロジェクトボードもあります。プロジェクトボードはマイルストーンと併用する事もできます。

追記

別途優先順位を明記できる方法があれば、その方法でも構いません。

その他

この Issue はリポジトリの運用に影響します。アプリには直接影響しません。

[Takym]

マイルストーンやプロジェクトボードを利用すれば Issue や PR をカテゴリに分けて整理する事もできます。
こうする事で、カテゴリ毎に進捗状況を確認する事ができますし、カテゴリそのものに優先順位を付ける事もできます。

カテゴリ作成例

• 陽性情報の登録画面
  • Issues & PRs: 陽性情報の登録画面で表示される確認ダイアログのボタンラベルが「同意する」になっている #57、ディープリンク対応 #100、検査日・発症日の事前入力 #101
  • 優先順位: 高
• プロジェクト整理
  • Issues & PRs: Resource.designer.csをGitの管理から除外する提案 #59、Resource.designer.csをGitの管理から除外する #74、.editorconfig を追加する #89、Add .editorconfig #90、UTF-8 BOM が不正な位置に存在する #92、fix UTF-8 BOM to file top #97、remove UTF-8 BOM #98
  • 優先順位: 中
• リファクタリング
  • Issues & PRs: null 許容型/非許容型の有効化 #35、型、関数、変数等に説明を付記する #56、UTF-8 BOM が不正な位置に存在する #92、fix UTF-8 BOM to file top #97、remove UTF-8 BOM #98
  • 優先順位: 低
• (UTF-8 BOM が不正な位置に存在する #92、fix UTF-8 BOM to file top #97、remove UTF-8 BOM #98 の様に複数のカテゴリを指定する事もできます)

[keiji]

プロジェクトボード、いいかもしれませんね。
@halsk さんと @heykuro さん、 @cocoa-dev とも相談してみます。

マイルストーンの導入については以前、検討したのですが、オープンソースプロジェクトのリソースは必ず確保できるという保証がないので、できる人が、できることを、できるときにやるというのにはそぐわないと思い、選択肢としては除外した経緯があります。

ちなみになんですが、優先順位についてはhelp-wantedをつけたものが一番高く（なにせ助けを求めていますので）、good-first-issue（コントリビュートを奨励する目的もあるので）のIssueを解決するPull Requestはなるべくはやく見て取り込むよ。みたいなイメージです。

bugがついたものは「想定した動作と異なるから対応しなきゃいけない」けれど、作業は開発チームでやるかもしれないないのでそのあたりは調整中の段階ですね。

では、そのほかのIssueについて優先順位はどうなんですかと言う話になると思うんですが、これは実際にはどれも同じです。
現時点でCOCOAとして対応するかも決めていないので、その段階でPull Requestが出てきてもレビューや取り込みなどの具体的な結果につながらないかもしれません。

[Takym]

現在では help-wanted、good-first-issue、それ以外という順番で優先されていて、殆どの Issue と PR の優先順位は変わらないという事ですね。

マイルストーンは「進捗状況を表示する」「閉じる事ができる」点以外はラベルと同じ使い方ができます。殆ど導入コストは掛からないかと思います。ただし、注意すべき点としてマイルストーンを追加しても Issues の一覧画面には表示されません。

また、プロジェクトボードは Issue または PR が作成された段階で「ToDo」に自動的に追加されて、閉じられた段階で自動的に「終了」へ移動してくれます。「ToDo」や「終了」以外の列も自由に設定できます。自動化機能が備わっているので、こちらもコストは掛からないかと思います。

• プロジェクトボードの自動化について
• プロジェクトボードの自動化を設定する

他にも優先順位を明記できる方法があればそちらでも構いません。上記の「あなたが考える代替案についてご説明ください」に追記しておきました。

[halsk]

@Takym さん、ご提案ありがとうございます。確かに、プロジェクトボードを導入することに賛成です。
プロジェクトボードのカテゴリについては、このIssueで検討できればと思います。

• 陽性情報の登録画面
• プロジェクト整理
• リファクタリング

というカテゴリ分けは私も良さそうに思いますが、どうですかね> @keiji @heykuro

[heykuro]

@Takym さん、ご提案ありがとうございます。私もプロジェクトボード導入は良いと思います。

カテゴリですが、

• 陽性情報の登録画面
• プロジェクト整理
• リファクタリング

に加え、

• 接触通知関連
  • Issue/PR例： 接触チェックに漏れが発生する可能性について #17 HighestRiskScore が 0 のため通知が発生しない問題 #15

というのもあると良いかなと思っています(名前の付け方はともかくとして、根幹機能が陽性登録と接触通知の大きく2つのためです)。

[keiji]

根幹機能単位（陽性登録、接触通知）に分割すること、プロジェクト整理やリファクタリングのカテゴリでプロジェクトボード作成してみます。

もっと細かくするとか、カテゴリの改廃については適宜やっていくと言うことで。

[Takym]

@halsk さん、@keiji さん、@heykuro さん、ご対応ありがとうございます。

[Takym]

すみません。訂正します。
上のコメントでは

ただし、注意すべき点としてマイルストーンを追加しても Issues の一覧画面には表示されません。

と書きましたが、マイルストーンは Issues の一覧画面に表示されます。
勘違いしていました。

[keiji]

@Takym
プロジェクトボード作成しました。

https://github.com/cocoa-mhlw/cocoa/projects

今後のアクションとして、

• Issue割り当て（開発チームとの調整が必要）
• 各カラムの英語併記
• CONTRIBUTING.mdの更新

をしていきたいと思います。

[Takym]

確認しました。v1.2.3 が次のバージョン(優先順位が高い)で、v1.2.x が更にその次のバージョン(優先順位が低い)、という事ですね。

[keiji]

また詳細は記載しますが、今後は v1.2.x がメインになる予定です。

[keiji]

v1.2.3についてIssueの整理が終わりました。
分類を主目的にしているのでcloseになったIssueも載せ続けています。done列を作って配置することも検討します。

[Takym]

@keiji お疲れ様です。

[Takym]

プロジェクトボードの整備が整い安定している様に見えますのでこの Issue は閉じます。