在开源项目中缺乏问题跟踪设施是否可能是不参与/贡献的动机？

Question

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

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

其他人在想什么？

Answer 1

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

开放式问题跟踪系统是我称之为“开放式开发过程”的一个组成部分 - 任何感兴趣的人都可以看到开发人员的决策，并为讨论做出贡献。

有些项目并不真正有一个开放的问题跟踪系统（或一个好的），但仍然有公开可见的讨论列表，也许是一个IRC频道，其中总是有人，可能是论坛/公告板等。我认为这些项目在为他们做出贡献方面仍然具有相当的吸引力。

Answer 2

我个人发现，当我在很多不同的开源项目中工作时，我并没有真正成为更大群体的一部分。但是，我确实发现了错误，并希望报告它们，并希望了解之前是否找到了问题，以及何时以及是否要修复它。

对于我个人而言，一个开放的错误跟踪器或邮件列表，我可以在其中拍摄一次性电子邮件以通知人们该错误，这比必须注册邮件列表或注册错误跟踪器更好。我已经有足够的帐户，我不需要另一个用于该软件。

因此报告错误所涉及的摩擦肯定是一个问题，也能够查看错误的状态并让它们可搜索是一个很大的帮助，以确定我是否将我的问题报告给项目

所以是的，开放式问题跟踪，易于使用，易于查看（挖掘页面20分钟不是我的乐趣）并且最重要的是只需要一点点摩擦来获取想要的功能/ bug的报告

Answer 3

我参与的许多项目仍在邮件列表上执行所有操作。如果一个bug进来（并得到确认，并且可以修复），它会在存储库中放入某种BUGS文件。当事情得到解决时，会记录文件中的条目。

不是我的偏好，而是其他贡献者习以为常的东西。可能有人不想要托管bug系统的麻烦，处理它可能吸引的垃圾邮件等等。可能是项目没有得到很多错误或功能请求吗？

'你应该'真正围绕代码的真正问题，不是吗？或者通过与任何特定群体合作，您可以学到多少东西？如果你开始做出贡献并表明自己是友好和有用的，那么在建议像trac或bugzilla这样的东西时你可能不会遇到任何阻力。

唯一能让我考虑转向任何特定项目的事情就是完全没有任何版本控制。但是，即使在那时，我也必须权衡我所放弃的与管理补丁的麻烦和粗暴的合并。