Zenn
🗒️

OSSのタスク管理あれこれ

2024/11/20に公開
タスク管理
tech

@sanposhiho といいます。Kubernetesを中心に複数のOSSをメンテしています。
この記事ではたまに聞かれるOSS周りのタスク管理方法をまとめます。

タスク管理手法

Kubernetesにはフルタイムのコントリビューターも僕のような趣味コントリビューターもどちらも多く、平日土日に関わらず開発が活発に行われています。この状態だと、ちょっとissueやPRをレビュー/Watchしたりするだけで、ほぼ毎日メールが来るような状態に陥ります。

特に、僕はKubernetes SchedulerのエリアでApprover(= PRを最終承認できる人)の権限を持っている関係で、平日だとそこらじゅうから毎日メンションが飛んできます。この状態だと、数日サボった後に戻ってくるだけでメールが数十件溜まっていることはザラです。

昔は特に何も考えずGmailを眺めて、「あ〜これまだ返信してなかったっけな」「あ〜これレビュー打ち返さなきゃ」でいけていましたが徐々に追いつかなくなりました。下手に権限を持っているため、返信忘れがそのまま議論をブロックしてしまうことになることも多く、これはまずいと対策で色々管理の方法を試してみました。

1. GmailをそのままTODOリストとして使う

https://blog.p1ass.com/posts/keep-inbox-empty/

つまりこれです。
届くメール全部に対して空っぽ管理をするのはめんどくさすぎて無理だったので、GitHubからのメールのみを対象にlabelをつけて別の受信ボックスを作り、そこを毎日見る、という形で始めました。

この方法で「対応していないGitHubからのメールが他のメールに埋もれて見逃す」ことは無くなり、最低限の目標は達成できました。

ただ、僕の場合、基本的に
「一日に受け取るGitHubからのメールの数」>「僕の一日に対応できるメールの数」
となっています。
平日にメールを大量に受けながら、優先度の高いものだけ先に打ち返し、休日に残りのやつを優先度高い順に打ち返す、と言うことをしているわけです。

そのため、この方法だとそもそも毎日全てのメールに対応するのが無理なので、基本的にメールは貯めていくことになり、土日には大量の未読メールリストがただ溜まっている形になります。
見逃すよりはマシですが、溜まったメールに対して管理がしにくく、いざ土日にどれから手をつけるかがわかりにくい、と言う点がありました。
例えば優先度をメモっておいたり、例えば「PRレビュー」「Issueでの議論」「自分のPRに対するレビュー」などでグループ分けできれば...

2. Google ToDo List

と言うことで、届いたGmailをGoogle ToDo List に登録する形に変えてみました。

これである程度メールをグループ分けできるようになり、便利になりました。

この時点で

  1. 他者からのPRのレビュー依頼
  2. Issueにおける議論への返答
  3. 自分の出したPRが受けたレビューへの対応

の管理に関しては、必要十分といった感じになり、初期の目標は達成できました。

3. GitHub Project

ただ、しばらくして追加で「自分にassignされているIssueの管理」「自分で作成したIssueの管理」も行いたくなります。
それらは単純によくある「GitHub Issueを通したタスクの管理」であるため、別でGitHub Projectを使い始めました。

そのタイミングで一元管理のためにメールで受ける通知に関しても、Google ToDo ListからGitHub Projectへの移行を考え始めました。

以下をベースに、GitHubからのメールをフィルタリングした後でGitHubのIssueとして起票するGASを書きました。

https://github.com/linyows/gmail-to-github-issues

実際移行してみると、一元管理と言う点を抜いても、Google ToDoよりも多機能なので使いやすく超満足でした。

受け取ったメールはIssueになり、GitHub Projectに登録され、以下のようにUnsortedに並んでいきます。

screenshot

そして、毎朝Unsortedのメールの仕分けを行います。この仕分けのタイミングで、対応の必要ない通知のIssueはloseします。また、興味のないIssue(後述)に関してはUnsubscribeし、この先メールが来ないようにしておきます。

  • Label
    • Reviewing: 他者からのPRのレビュー依頼
    • Being reviewed: 自分の出したPRが受けたレビューへの対応
    • ToDo: その他対応が必要なこと。Issueにおける議論への返答など
  • Priority
    • 各種freeze前など、締切のあるPRは早めに対応する必要がある。
    • (その他、積極的に議論に絡まないと嫌な方向に進んでしまいそうな議論や、返信が遅い相手との議論なども優先度を上げておく。大事。)

そして、対応が終わったメールのIssueはCloseし、CloseのタイミングでGitHub Projectから弾かれるようになっています。

また、この方法のいいところは、対応のタイミングでIssueにメモを残せることです。
返信に際して行なった調査のメモや、頭の中の思考プロセスもメモとして残しておけますし、長文の返信を書いているときは下書きをIssueに残しておくこともできます。
メールのIssueが以下のように大元のPR/Issue上に表示されるため、たまに「あれ、なんで昔の僕こんなこと言ったんだ？」「どういう調査をしてこの返信をしたんだ？」みたいなのをそこから見返すことができたりします。

振り返って過去のIssue/PRを見てみると、相手の返信の下にメールのIssueがリンクされています。

リンクされたメールのIssueをみると、ノートが見えます。

というわけで、最終的にこの方法に落ち着いて、多分これで一年位タスク管理を続けています。

また、前述の「自分にassignされているIssueの管理」「自分で作成したIssueの管理」に関しては↓をそのまま使わせてもらってます。

https://zenn.dev/shunsuke_suzuki/articles/add-github-issue-pr-to-project

Dashboard上では同様にLabelで仕訳が行われています。

リポジトリごとに以下のように仕分け:

その他タスク周りのこと

本筋から逸れますが、ツール的な意味ではなく、タスク管理でその他意識していることです。

他の人に渡せそうなIssueは積極的に他の人に投げる。

Kubernetesは、現状超少数のメンテナが超大量のPRを捌くと言う構図になっています。
そして、PRがマージされるには基本的に2人のレビューを受ける必要があります。

SIG-Schedulingに関しては、直近は某社がメンテナを足してくれたのでギリギリなんとかなっていますが、去年から今年の夏あたりまでは2人の積極的なレビュワーがほぼ全てのPRをレビューしている状態でした。"2人"には僕を含んでいます、つまり僕らどちらかが作成したPRは特にレビューに時間を要しました。

そのため最近ではやることが明確でわかりやすく他の人に渡せそうなIssueは積極的に他の人に投げるようにしています。昔は「全部俺が実装して手柄にしてやるぜ！」という感じだったことを考えると成長を感じます。

例えば、QueueingHintという機能では途中まで自分一人で実装を進めていましたが、前述の理由で進捗が遅くなってしまったので、途中でみんなに投げて自分はレビューに回りました。(日本からのcontributorが多く助かりました！)

また、同様に他の人のPRのレビューに関しても積極的に他の人にお願いするようにしています。これにより、僕に回ってくるタイミングでは綺麗な状態で回ってくることが増え、非常に大助かりしています。また、将来的なReviewerを増やすという長期的な目線からしても、メリットがありそう、と思っています。

興味のないIssue/PRには関わらない or 優先度を下げる

大前提、僕の場合はあくまでも趣味であり、使える時間も限られているので、興味のないIssueやPRから来たメンションの対応優先度はかなり下げています。なんなら僕が返信しなくてもブロッカーにならなそうな場合は即Unsubscribeしています。(e.g., グループメンションが来た場合は、「...誰か返信してくれるやろ!」)

...とはいえメンテナの数が減ってきているので、そうも行かなくなる日が来てしまいそうな雰囲気も感じています。

Discussion