open-source - 开源项目中缺乏问题跟踪设施是否可能是不参与/贡献的诱因？

Question

在决定您是否参与一个相当大的开源项目以便为其代码库做出贡献时，该项目的问题跟踪设施（即跟踪错误和功能请求）对于您做出贡献的决定有多重要？

仍然有许多非平凡的（巨大的代码库）开源项目，它们没有正式进行问题跟踪——虽然一些贡献者可能确实仍然以各种“待办事项”列表的形式私下做这件事，但我个人有发现缺乏可用性和确定使用问题跟踪是缺乏组织、结构和整体项目协调的一个相当可靠的指标。

其他人在想什么？

Answer 1

我会说这将是一个相当重要的因素。

开放式问题跟踪系统是我所说的“开放式开发流程”的一个组成部分——任何对此感兴趣的人都可以看到开发人员正在做出的决定，并为讨论做出贡献。

有些项目并没有真正的开放问题跟踪系统（或一个好的），但仍然有公开可见的讨论列表，也许是一个总是有人在的 IRC 频道，也许是一个论坛/公告板等。在我看来，这样项目在贡献方面仍然相当有吸引力。

Answer 2

我个人发现，虽然我与很多不同的开源项目一起工作，但我从来没有真正成为一个更大的团队的一部分。但是，我确实发现了错误并想报告它们，并想知道之前是否发现了该问题，以及何时以及是否要修复它。

就我个人而言，一个开放的错误跟踪器或邮件列表，我可以在其中发送一封一次性电子邮件以通知人们错误，这比注册邮件列表或注册错误跟踪器要好。我到处都有足够的帐户，我不需要另一个用于该软件的帐户。

因此，报告错误所涉及的摩擦绝对是一个问题，而且能够查看错误的状态并使其可搜索对于确定我是否将我的问题报告给项目有很大帮助。

所以，是的，开放问题跟踪、易于使用、易于查看（浏览一个页面 20 分钟不是我的乐趣），最重要的是，只需很少的摩擦即可获得所需功能/错误的报告。

Answer 3

我参与的许多项目仍然在邮件列表中完成所有工作。如果出现错误（并得到确认，并且可以修复），则将其放入存储库中的某种 BUGS 文件中。随着事情得到解决，文件中的条目会被记录下来。

不是我的偏好，而是其他贡献者习惯和喜欢的。可能是有人不想麻烦托管错误系统、处理它可能吸引的垃圾邮件等。难道该项目没有收到很多错误或功能请求？

“你应该”的真正问题真的围绕着代码，不是吗？或者通过与任何特定的团队合作，您可以学到/教多少？如果您开始做出贡献并表现出友好和有用的态度，那么在提出 trac 或 bugzilla 之类的建议时，您可能不会遇到任何阻力。

唯一能让我考虑避开任何给定项目的是完全缺乏任何类型的版本控制。但是，即使那样，我也必须权衡我将放弃的东西与管理带有活泼合并的补丁的麻烦。