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

Question

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

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

其他人在想什么？

Answer 1

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

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

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

Answer 2

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

就我个人而言，一个开放的错误跟踪器或邮件列表，我可以在其中发送一次性电子邮件来通知人们该错误，这比必须注册邮件列表或注册错误跟踪器更好。 我已经在各地拥有足够的帐户，我不需要为该软件再创建一个帐户。

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

所以，是的，开放式问题跟踪、易于使用、易于查看（花 20 分钟浏览一个页面并不是我的乐趣所在），最重要的是，获得所需功能/错误的报告时几乎不需要任何麻烦。

Answer 3

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

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

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

唯一让我考虑避开任何给定项目的事情是完全缺乏任何类型的版本控制。 但是，即便如此，我也必须权衡我会放弃什么与通过快速合并来管理补丁的麻烦。