議論リソースを効率運用する issue 進行方針

[tarepan]

内容

提案概要: 議論リソースを効率的に活用するため「長期議論停滞 issue を close」する issue 進行方針を採用したい

VOICEVOX ENGINE では多様な機能実装・仕様変更が自由に提案され、これらはより良い ENGINE を作る基盤である。
一方で、限られたリソースを効率よく運用しリソース制約の中でより良いプロダクトを作れることも重要である。

現在多くの issue では「アイデア提案 → 必要性議論 → 設計 → 実装者募集 → 着手宣言 → PR」の段階を踏んでいる。
前半の「アイデア提案 → 必要性議論 → 設計」では議論リソースが必要であるため、議論が途中で止まる issue がそれなりにあり、これらは open issue として存在し続けている。
これら open issues の一部は「当時必要性があったが、現在では必要性が下がった」という状況にある。新しいコントリビュータがこれらに「open issue だから取り組んでみるか」と手を付けると、結果として低優先度の課題を解くことになる。不幸なケースだと「提案してもらったけど、状況が変わったので採用できないかもです…」となる（なった）。
これは議論リソースの効率的運用とは言えない。

この問題は長期議論停滞 issue が open であり続けることに起因している。
昨今の運用体制改善により、議論で必要性が認められた issue は close してもロードマップ (#1106) にリンクを残す等の対応が可能であり、open であり続けるメリットは減っている。
ENGINE 運用開始から30ヶ月以上が経ち、古い open issues が目立ち始めたこのタイミングで、上記のメリットとデメリットを天秤にかける価値があると考える。

このような背景から、「長期議論停滞 issue を close」する issue 進行方針を提案します。

より具体的には次の運用方針案を考えています：

• 「必要性議論」がまとまらなかった長期停滞 issue: アイデアに感謝して close
• 「設計」が固まらず長期停滞した issue: ロードマップへリンクして close
• 「実装者募集」まで進行した issue: 実装者募集 label を付けて open 放置OK (レビュア権限で既に実験中)

Pros 良くなる点

• 議論リソースの効率的運用
• 必要性が認められた議論途上 issue のロードマップへの集約による一覧性向上

Cons 悪くなる点

• 提案管理場所の分散（issue only → issue + ロードマップ)

実現方法

• 議論
• レビュアー向け情報への記載

[Hiroshiba]

提案ありがとうございます！
まとまっていて課題点がすごくわかりやすかったです。

ちょっと論点と異なるかもなのですが、近いところに問題意識を持っています。まずそのあたりをすり合わせできればと。

新しいコントリビュータがこれらに「open issue だから取り組んでみるか」と手を付けると、結果として低優先度の課題を解くことになる。不幸なケースだと「提案してもらったけど、状況が変わったので採用できないかもです…」となる（なった）。
この問題は長期議論停滞 issue が open であり続けることに起因している。

これは「長期議論停滞 issue」だけでなく、議論が終わったものでも起こり得るなと感じました。
長いことopenになっているissueの棚卸しも必要かもですね。

より具体的には次の運用方針案を考えています：
「必要性議論」がまとまらなかった長期停滞 issue: アイデアに感謝して close
「設計」が固まらず長期停滞した issue: ロードマップへリンクして close
「実装者募集」まで進行した issue: 実装者募集 label を付けて open 放置OK (レビュア権限で既に実験中)

ラベルの運用や名称は一旦置いといて、大枠良さそうな感じがしました！
途中で必要性が下がったとかもあると思うので、必ずしもロードマップへリンクする必要はないなど細かい部分が実運用時に異なりそうです。

---

本当はコアやエディタと強調して同じ方針を取った方が良いのですが、一旦実験的にということでエンジンをこの運用で回すというのはどうでしょうか？

実現方法としてのアイデアは、フローチャートをmermaidで作ってみたり、ロードマップを将来的にProjectやDiscussionに移動させたりとかもありえそうですかね。
あとはどのラベルがどのクラスに属するかわからないので、フェーズを分けるなら全部フェーズだとわかるようにしとくと初見時の理解の助けになるかもですね！

という感じで煮詰めていくのが良いのかなと思いました。
実際に実験的にラベルを作ってみて運用してみるのも有りだと思います。（唐突に始まったので驚きましたが）
ちょっとどこかにまとまっていないとだいぶ混乱しそうなので、どこかでまとめて議論していけると良いのかなと思いました。

cc メンテナ @y-chan @qryxip

[tarepan]

議論が終わったものでも起こり得る ... 長いことopenになっているissueの棚卸しも必要かも

👍
同意です。
実装者募集 含め、open issue は停滞したら棚卸しがベストです。

大枠良さそう

👍
棚卸しは Go の方向性でその具体的なフローを議論していく、ということですね。

一旦実験的にということでエンジンをこの運用で回す

👍
ENGINE は大型プロジェクトを現状抱えていないので、改善案の試験運用に向いています。
私は賛成です。他メンテナさんの意見を伺えればと。

ちょっとどこかにまとまっていないとだいぶ混乱しそうなので、どこかでまとめて議論していけると良い

👍
ENGINE での試験運用を前提として、この issue で具体的フロー検討・現運用集約できればと思います。

---

実現方法としてのアイデア

👍
提案ありがとうございます！
まず仮運用フローを mermaid で可視化し
仮運用フローを mermaid で可視化しました。これを叩き台に運用フロー v1.0 を議論したいです。
v1.0 としては棚卸し（issue open ~ issue pending or NoGo）にスコープを絞って議論できればと思います。

pending をどう扱うか（ロードマップ記載？ Project？ Discussion？ 復帰手順は？）は v2.0 で更に議論ができればと。
フロー v1.0 が決定したらラベル名等を確定し、一旦 v1.0 実運用を回す感じになりそうですかね。

遷移条件（何ヶ月 inactive で pending 移行等）はさておき、issue 状態遷移自体で抜け漏れありそうでしょうか？

---
title: issue 運用フロー v0.0
---
stateDiagram-v2
    [*]     --> 必要性議論 : issue open
    state active {
      必要性議論 --> 設計
      設計       --> 実装者募集
      実装者募集 --> 実装 : 着手宣言
    }
    active      --> not_planned : NoGo judge
    not_planned --> [*]         : issue close
    実装        --> resolved    : PR merge
    resolved    --> [*]        : issue close
    active      --> pending
    pending     --> active

Loading

[Hiroshiba]

フロー図ありがとうございます！

設計が含まれてるの面白いですね。そこも実装者の方に結構おまかせしたりしていました。
僕たち側で手が回らなくなったらそこも募集かけても良いかも。

「設計するまでもないもの」とか「issue作ってくださった方がそのまま取り組んでくださる場合」とかは設計や実装者募集をスキップできるかもですね！
必要性判断も待たない方が良い時もあるかもと思いました。発見された方がノってる時とか。まあその代わりプルリクを棄却させていただくこともあるかもって感じですが･･･。

ラベリングは必要性議論か設計のときにって感じですかね！

[tarepan]

設計 ... そこも実装者の方に結構おまかせしたり ... そこも募集

👍
ラフな設計をメモ的にするに留めて 設計 段階を終わらせるのも全然ありだと思います。
ケースバイケースで柔軟にやれればと。

設計や実装者募集をスキップ

👍
issue 提案者が「実現方法」節でキッチリ設計してくださるケースや、issue 提案時点で draft PR を付与してくれる（着手宣言している）ケースも多々あります。その場合は「設計 や 実装者募集 をクリアして現在実装 状態」と単純に理解して良いと思います。

フロー図の意図は「ウォータフォール的に順番に達成すべき段階」ではなく「issue の移り変わる状態を示した状態遷移図」というイメージです。
なのでおっしゃるとおり、「必要性議論 をスキップとはけしからん！」ではなく「初っ端から 実装 状態ね、了解」な温度感で向き合うのがいいと考えます。棄却パターンも「頂いた PR のメリットを慎重に判断したいので 必要性議論 に立ち戻って議論しましょう」でコントリビュータの理解を得られると思います。

---

ラベリングは必要性議論か設計のときにって感じですかね！

👍
同意です。
必要性が見えたら 優先度 系 label が付与できると考えます。 OS依存 はスコープが理解でき次第順次で。

---

状態遷移の同意がある程度取れたと思いますので、pendding / not_planned 行き（長期停滞 issue 処理）の遷移条件を議論できればと思います。

• 最終コメントから何日で遷移判定とするか
• 日数は issue の状態で変えるか（例: 必要性議論 は 14日待機、実装者募集 は半年待機）

が私がパッと気になる論点です。

[Hiroshiba]

フロー図の意図は「ウォータフォール的に順番に達成すべき段階」ではなく「issue の移り変わる状態を示した状態遷移図」というイメージです。

なるほどです！
状態遷移がいくつかスキップされることもあるという考え方で納得です。まあそもそもそんなに厳格に進める雰囲気じゃないという感じですかね！

棄却パターンも「頂いた PR のメリットを慎重に判断したいので 必要性議論 に立ち戻って議論しましょう」でコントリビュータの理解を得られると思います。

確かにです。となるとこのフロー図をどこかで案内すると良さそうですね。
まあでも最初はとりあえずこの流れに従って活発にエンジンissueにラベリングを振る僕たち（ @Hiroshiba と @tarepan）が動いてみて、良さそうだったら他のレビュアの方や他のリポジトリでも同じ流れにしていけるとよさそうかなと。

---

状態遷移の同意がある程度取れたと思いますので、pendding / not_planned 行き（長期停滞 issue 処理）の遷移条件を議論できればと思います。

• 最終コメントから何日で遷移判定とするか
• 日数は issue の状態で変えるか（例: 必要性議論 は 14日待機、実装者募集 は半年待機）

が私がパッと気になる論点です。

妥当な日数を考えるのが結構時間かかりそうです 🙇
ちょっとたたき台を考えるのお願いしてもいいでしょうか 🙇

---

あとこれらの「必要性議論」ラベルとかは全部同じ概念であるということがわかるように、何かしらプレフィックスをつけるのお願いしたいです！

[tarepan]

妥当な日数 ... たたき台

👍️
最終コメントから以下の日数経った段階で pending/not_planned への遷移判定をおこなうことを提案します：

• 必要性議論 : 30 日
• 設計 : 180 日
• 実装者募集 : 180 日
• 実装 : 180 日

以下が日数の意図/根拠です：

GitHub 公式 docs の 非アクティブな Issue をクローズする で 30 日が一例として挙げられている。
経験的にも 1 ヶ月 inactive となった issue は以降の動きに乏しい。
よって 30 日を基本の遷移判定日数とした。

一度必要性が認められた場合、たとえ issue が止まっても「何か意義ある実装したいなー」という人に引き継いでもらう価値がある。そのため 30 日を超えても active であり続ける意義がある。
一方、VOICEVOX ENGINE は 0.97 PR merge/day で更新されているアクティブなレポジトリである (2023-01-01 ~ 2024-03-26 実測値)。よって必要性議論の前提条件が変わりやすく、必要性の鮮度が落ちやすい。
また実装者や追加コメントが現れないということは、ある意味で「実際のところ必要性がそんな高くない」ことも示唆している。
よって 設計 / 実装者募集 / 実装 であっても一定期間で見直し/遷移判定をおこなうべきである。

VIOCEVOX 全体では数ヶ月に 1 度大型アプデをしており、その際は 1 ヶ月ほどリソースが払底する。ゆえに停滞中 active issues を別コントリビュータが引き継げない時期がそれなりにある。
よって 30 日基本待機 + 30 日リソース払底 + 30日順次着手 として、90 日程度は最低限 active を保つ必要が見出だせる。
昨今の ENGINE では 0.42 issue open/day で issue が提案されている (2023-01-01 ~ 2024-03-26 実測値)。180日で機械的に close した場合、76 issues が定常的に open になる計算であり、このくらいが現体制下で管理可能な open issue 数の上限に感じる。
よって 90 ~ 180 日が 設計 / 実装者募集 / 実装 の待機日数として妥当と考える。

open された issue の半数程度は PR で resolved close されると仮定し、またある程度の issue が active で即引き継ぎ可能な方がコントリビュータを呼び込みやすい点を考慮すると、停滞 open issue が常時 30 程度になる「待機日数 180 日」とすることは妥当である。
よって 設計 / 実装者募集 / 実装 の待機日数を 180 日に設定した。

---

全部同じ概念であるということがわかるように、何かしらプレフィックスをつける

👍️
「state: 必要性議論 / state: 実装」「状態：必要性議論 / 状態：実装」あたりが有り得そうです。
どちらがしっくりきますか（あるいは他の案）？

[Hiroshiba]

提案ありがとうございます！！

• 必要性議論 : 30 日
• 設計 : 180 日
• 実装者募集 : 180 日
• 実装 : 180 日

根拠含めこちらが良さそうに感じました！
180日の方は様子を見てもっと代謝を激しくしてもいいかもですね！！
とりあえず運用を変えすぎないという意図でも、一旦長めに設定しておくのが良さそうに感じました！

---

「state: 必要性議論 / state: 実装」「状態：必要性議論 / 状態：実装」あたりが有り得そうです。
どちらがしっくりきますか（あるいは他の案）？

他のラベルに合わせて「状態：」が良さそうに思いました！