Laravel 禁 issue 只收 PR,我举双手赞成
上周 Laravel 宣布禁止提交 issue,只能提 PR。第一反应是这也太离谱了,用户连问题都不能报,难道要人人读懂源码?但仔细琢磨了一下,这个决定其实相当合理,甚至值得更多开源项目跟进。
最直接的好处是垃圾 issue 会大幅减少。愿意花时间写 PR 的人,至少说明他对这个问题真的在意,会认真描述复现步骤和期望行为。而那些机器人、灌水党、随手甩一句「用不了」的人,根本不会多走这一步。对维护者来说,从 PR 里拿到的信息量远大于 issue,定位和修复的成本都更低。有人担心这会抬高普通用户的参与门槛,我觉得在 AI 时代这个顾虑基本不成立。你完全可以把问题描述给 AI,让它生成一个 PR 草稿,再自己检查一遍提交。提 PR 和提 issue 的操作成本,现在已经非常接近了。更深层的原因是开源项目普遍资源不足,根本应付不了激增的 issue。过去那种「把问题抛出来等别人解决」的模式,在 AI 让贡献门槛骤降之后,反而应该转向「大家一起动手改」。这不是傲慢,而是维护者被逼出来的生存策略。当然,这招不是所有项目都适用。文档类、使用咨询类的仓库,一刀切禁 issue 只会把用户推走。但对代码型项目,尤其是维护者长期过载的那种,Laravel 这个尝试值得观察一阵子。
最直接的好处是垃圾 issue 会大幅减少。愿意花时间写 PR 的人,至少说明他对这个问题真的在意,会认真描述复现步骤和期望行为。而那些机器人、灌水党、随手甩一句「用不了」的人,根本不会多走这一步。对维护者来说,从 PR 里拿到的信息量远大于 issue,定位和修复的成本都更低。有人担心这会抬高普通用户的参与门槛,我觉得在 AI 时代这个顾虑基本不成立。你完全可以把问题描述给 AI,让它生成一个 PR 草稿,再自己检查一遍提交。提 PR 和提 issue 的操作成本,现在已经非常接近了。更深层的原因是开源项目普遍资源不足,根本应付不了激增的 issue。过去那种「把问题抛出来等别人解决」的模式,在 AI 让贡献门槛骤降之后,反而应该转向「大家一起动手改」。这不是傲慢,而是维护者被逼出来的生存策略。当然,这招不是所有项目都适用。文档类、使用咨询类的仓库,一刀切禁 issue 只会把用户推走。但对代码型项目,尤其是维护者长期过载的那种,Laravel 这个尝试值得观察一阵子。
评论
登录后即可发表评论
参与讨论,和出海同行交流想法与经验
还没有评论,来抢沙发吧
说说你的看法,第一条评论最显眼