「雑に立てられるissue」で疲弊しないためにOSS開発者ができること - 2021-12-04 - ククログ

要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切るといいよ。 結城です。 GitHub Actionsに関することならなんでもありらしいアドベントカレンダーとのことでしたので、ほんのちょっとかすっているだけではありますが、4日目にエントリーさせて頂きます。 「軽率に寄せられる報告や要望がOSS開発者を疲弊させる」という問題について語るOSS開発者は少なくないです。私の観測範囲内では最近も、イシュートラッカーにissueを立てようとすること自体に待ったをかける記事1や、「要望には初手で『なぜ自分で実装しない？』と訊ね、次に『継続的にメンテナンスしてくれるの？』と訊ねるドライな対応がおすすめ」という趣旨に受け取れる発言など

[bamch0h]

雑にissue立てられて疲弊してみたいわ！

[ledsun]

issueの時限クローズ機能はgithubで提供してくれたらいいな

[sezemi]

“「プロジェクトの手離れをよくしておく」” なるほど

[nntsugu]

“要約：OSS開発プロジェクト運営者の側でとれる対策はいくつかあるよ。issueは基準を設けてどんどん閉じてしまおう。GitHubならActionsで自動化も簡単だよ。自動テストを整備するように、必要なコストだと思って割り切る

[mas-higa]

筑波大シラバス「KdBもどき」は逆に PR 来るけど issue 書いてくれないって困ってたな。

[hiroomi]

“issueとしてはクローズすると同時に、フォーラムへ誘導する”OSSに限らず商用、オンプレでもあり得る話なのと、目的意識を関越的確認する話なんでしょうね。

[door-s-dev]

方針としてはすごい参考になる。ただGitHub Issueはイシュートラッカーとして必要な機能が備わってないので、他のちゃんとしたイシュートラッカーを運用した方がいいと思う

[teppeis]

経験に基づく知見すごい

[raimon49]

具体案が並んでいてとても学びが多い。スコープを明示するの本当に大事だ。

[mojimojikun]

issueではないけどお問い合わせ対応で似たような事やってた。(´・ω・`)ﾀｲﾍﾝﾀﾞﾖﾈ

[circled]

issue欄は閉じてしまい、discussion欄で問題や機能についてユーザに議論させ、そこのup/down voteの数に応じて重要性を決めて対処すれば良いかと。

[Shinwiki]

チケットオープンとクローズの権利を利用者に持たせてるとこじゃねえの

[tito1201]

いい内容だった。