2024-03-19

FLOSSのIssue消化戦略

何かがスケールすると発生し始める問題の一つに、「FLOSSの有名税」とでも言うべきものがあると筆者は考えている。

以前、expressjs/expressがスパムPR爆撃を受けていた件が話題になっていた。ざっくり言うと、GitHubのPRの作り方を説明するチュートリアルをYouTubeに出していたIT教育系動画投稿者がいて¹、それを観た大量のバカが実際にスパムPRを作成しまくったという事件だ。

expressjs/expressの件はさすがに極端な例だけど、そこまでいかなくとも、そのソフトウェアが有名になるにつれて、作成される（スパムではない）Issueが多すぎてメンテナーが対処しきれなくなるという事態は往々にして発生する。これ自体は仕方のないことだし、メンテナーが疲弊するのも理解できるが、そのせいで自動クローズbotみたいな仕組みを導入し始めるのは、いくらメンテナンスが大変でもやってはいけないことだと思う。それは隠密的なメンテナンスの放棄に等しいし、Issueという仕組みの意義を破壊してしまう。問題があってIssueが作成されたのであれば、問題が解決していないのにIssueをクローズするのは、メンテナーの自己満足、欺瞞であり、臭いものに蓋をしているだけである。それをわかっていてやるのであればまだいいが、メンテナーは本当にその不評を被る覚悟があるのだろうか。

自動クローズbotの導入方法がGitHubの公式ドキュメントに書かれているということも、なかなかに信じがたい。Issueのクローズ理由の一つに“stale”があるので、動きがないIssueをクローズするというのはGitHub的には正当なのかもしれない。

個人的には、Issueの分類やクローズ理由としての“stale”というのは、ソフトウェアの他の部分で機能追加したりバグ修正したりすることによって、そのIssueに挙げられた問題が副作用的に解決していた場合を指しているのかと思っていたが、その認識がおかしいのかもしれない。というか、そもそも「解決していた」なら“resolved”扱いでいいのかもしれない。そうなってくると、筆者の立場としては、クローズ理由から“stale”を削除するべきという話になる。

「ソフトウェアに問題がある」という旨のIssueを「Issue作成日時が古いから」という理由でクローズしていいケースというのは存在しない。表立ってメンテナンスを放棄していたとしても、である。オープンなIssueは「治っていない問題」の一覧であり、いくら古くても問題が残っている限りIssueを残しておかなければならない。それがメンテナンス放棄ということの意味である。

手動で作成された、ちゃんと意味のあるIssueを自動で²クローズしていいケースというのも存在しない。Issue消化に関する自動化として最大限考えうるのは、「重複するかもしれない既存のIssueをAIでリストアップしてチェックボックスを出しておき、メンテナーによってチェックされたらそのIssueのduplicateとしてクローズする」とか、「質の低い（再現手順がないなど）可能性のあるIssueにそういうタグをつける」などといった、あくまで「判断をメンテナーに任せる」自動化だけだろう。

あまりGitHubでIssueを漁ることがない人には、何を当たり前のことをと思われるかもしれないが、実際にそうやってクローズされているIssueがGitHubにはたくさんある。特に大きいプロジェクトほどそのような傾向が認められる。

思うに、自動クローズなどをやり始めてしまうのは、Issueをカスタマーサポートのようなものだと考えているメンテナーたちだろう³。カスタマーサポートというものは、その成り立ちからして、問題ベースではなくカスタマーからのアクションベースで動いているものだ。苦情がなければ動かなくていいという行政的な考えと、自動クローズとの間には親和性がある。しかしFLOSSにおいては、ユーザーとメンテナーを立場上分離するような考え方や、それら人間を中心とする考え方ではなく、ソフトウェアそれ自体を中心とする考え方で開発を進めるべきだし、それに基づけば、メンテナーの労力の都合でソフトウェアの問題がなかったことにされるというのは、発想すらあり得ないような事態だ。

正しい方法で大量のIssueに対処するなら、各メンテナーの稼働時間を増やすか、メンテナーの数を増やすしかないのだが、それはそれでまた別の問題が発生するおそれが出てくるので、難しい。とにかく、何かがスケールすればするほどその世界は崩壊に向かっていく、というのが自然の摂理なのだろう。政治の直面する不可能そのものである。結局のところこれは倫理や良心の問題であって、考え方が異なる人たちがいる以上、無くなることはないのかもしれない。

Footnotes

一応、少なくともコメントでは「実際にはテスト用のPRを送らないように」という旨の免責文が出されてはいる。筆者は動画本体は観ていないので確かなことは言えないが、動画の中にも同じ旨の注意はあったらしい。 ↩
「自動で」というのは「人間の判断なく」という意味。関連付けられたPRのマージに従ってクローズされるケースは、人間の判断によるので含まない。 ↩
メンテナーにそう思わせてしまうGitHubのUIにもいささか問題があるかもしれないが、かといってどうデザインすればいいのかという案は筆者には湧いてこない。おそらく、そもそもGitHubのような場所で中央集権的にソフトウェアを管理するのをやめる必要がある。 ↩