开源项目错误提交用户指南

暂无读者喜欢此文。
annoying bugs

Opensource.com

我最近在 Facebook 上发布了关于 Fedora 20 的 GNOME 3.10 测试日的行动号召,并得到了一些回复,这让我开始思考从普通大众到开发者,每个人是如何为开源项目提交和修复错误的。

这是当时的互动

我: 大家好,我们明天来测试 GNOME 3.10 和 Fedora 20 吧!

用户: 不确定是否有帮助,但是当我在我的笔记本电脑上登录并使其休眠时,就无法再次登录了。这是在 Fedora 19 上。

我: 那就提交一个 bug。

用户: 我只是给你一个测试的想法。而且我认为 bug 跟踪器需要一个账户。

为什么要向 Bugzilla 提交 bug?

开发者与用户的比例是 1:100,甚至有时更高,因此必须使用像 Bugzilla 这样的跟踪系统,问题才能得到解决,bug 才能被发现和修复。这也能确保其他用户意识到这个问题。如果这个问题在不同的硬件上都很常见,其他人会添加更多信息,这有助于更快地解决问题。

我与上述用户的互动也突显出,一些用户可能不想创建 Bugzilla 账户来提交问题/bug。但是,如果你发现了一个问题而不报告,它可能在相当长一段时间内都无法得到修复。报告 bug 也是一个回馈你正在使用的开源项目的机会。

现实情况是,对于任何开源项目来说,开发者和质量保证人员都是稀缺资源。他们有自己的计划和目标,需要在新产品发布期间按时完成。因此,尽管通过社交媒体、聊天甚至当面“告诉”某人可能很容易,但最好的做法是在该开源项目使用的跟踪系统中提交 bug。

开源项目的心态

Google 的开源主管 Chris DiBona,很好地总结了开源社区(由开发者和用户组成)是如何运作的(以及为什么有时它会很“残酷”)

我认为这是因为开源项目能够只与有生产力的人合作,而忽略其他人。这种行为可能会显得非常苛刻或排斥,而事实也正是如此:对任何不做出贡献的人来说,都是残酷的苛刻和排斥。

所以,我想我所说的是,开源世界中实践的适者生存是一种相当残酷的机制,但它在生产高质量软件方面非常有效。但这对新手来说确实很艰难...

开源社区的每个成员都投入了大量的空闲时间和资源来开发项目并使其成功。因此,重要的是要实施从开始到结束的精简工作方式;并且每个人都遵守这些规则。

提交问题 / 提交 bug

  • 登录到正在使用的跟踪系统(例如,Bugzilla)
  • 创建一个测试用例
  • 描述重现问题/bug 的步骤
  • 奖励: 如果存在,将其添加到测试日 wiki 页面;然后,如果其他人有空闲时间,他们可以在可能的情况下进行测试

开源项目既有趣又具有挑战性。而且,参与的最佳方式,我们也希望你能这样做,就是在可能的情况下伸出援手。每一份贡献都很重要!

User profile image.
Alex 是 Red Hat 的 QA 合同工,负责超过 1400 个 bug,是一位通用的开源开发者和企业家。他住在索非亚谷,那里正在成为东欧初创公司创始人和技术黑客的聚集地!Twitter: @atodorov_

9 条评论

正如文章中所述,存在一个问题。你需要登录到跟踪系统才能正确报告 bug。如果报告 bug 的人是开发者或具有类似心态的人,这可以很好地工作,但是随着 Linux 变得越来越流行,会发生什么呢?

我确切地知道,在 Ubuntu 系统上,bug 系统是自动化的,大多数人会取消...因为“太复杂了”。Windows 上也发生了同样的事情,而且我非常确定微软让它变得更容易,因为他们不关心你的隐私。

我实际上没有解决方案,我只是指出了我看到的一些问题。

你是对的,但我不知道为什么这是一个问题。

每当网络上出现新的酷炫服务时,人们似乎都没有注册新账户的问题,但会抵制在 bug 跟踪系统上注册账户。不确定这是为什么。

你说“为酷炫而注册”是对的,但大多数情况下,这是为了他们认为可能会再次使用的服务(或者已经使用了一段时间但没有账户的服务)。
根本问题是用户看到了注册和提交 bug 的一堆问题,并且不认为它那么重要。

一种选择可以是允许匿名发布 bug - 就像发送到 Android 应用商店账户的报告一样。你无法真正联系到用户,但至少该问题已记录在 bug 跟踪器中。

然后单点登录会有所帮助:在 community.jboss.org 上拥有账户的用户也可以将其用于 Jboss.org Jira bug 跟踪实例。
现在回到“酷炫” - 如果提交(新的)bug 也会获得成就/徽章系统的积分,那么甚至会有一个激励去完成提交 bug 的麻烦事。

另一件事是提交 bug 本身通常太复杂了。你必须选择一个类别,可能还要选择严重程度等等。特别是 Bugzilla 用户界面对于新用户来说可能非常吓人。
这里的类别可以设置为默认的“ - 不知道”,放在首位。这将给开发者带来更大的负担,让他们正确地归档问题,但它可以防止用户在此时放弃(而且如果用户选择了一个类别,它可能完全是假的)。

我看到你引用 Chris DiBona 的话“开源是一项艰难的业务” - 但我们真的需要保持这样吗?

用户提供的信息本身就是一个有效的问题,需要进行一些检查,因此如果用户不想为 bug 跟踪器注册账户,我们作为拥有账户的人,也可以直接说“嘿,没问题,你有什么具体的电脑型号.... ”然后用这些信息打开一个 bug,并将 URL 提供给用户。

也可以在用户和开发者之间引入另一个“层级”。查看 Joomla Bug Squad:http://docs.joomla.org/Bug_Squad

他们检查论坛,帮助用户解决他们的问题,对跟踪器进行分类等等。他们有时也会为用户提交 bug。这减轻了开发人员的额外工作/负担,并且用户获得了帮助。

我们曾经有过这样的团队,不止一次。但它总是消亡。我知道极少数项目有稍微成功的团队,而更多项目则有已经死亡/休眠/夭折的团队。这似乎是那些足够枯燥乏味且吃力不讨好的任务之一,很难让人长期坚持下去。

在对那些严重缺乏*有用*信息或缺乏相关背景信息的 bug 进行分类后,我写了以下笔记(显而易见的信息,只是大声说出来)
https://wiki.openstack.org/wiki/BugFilingRecommendations

(它还包含指向 Fedora 和 mozilla 社区 bug 编写指南实践的 URL。)

嘿,谢谢 Alex 提交了对开源开发者有帮助的文章,这对我和我的朋友们的开发项目真的很有用,我遇到了很多问题,也得到了领导的帮助,但是你在这里发表文章来解决问题。我真的很想阅读更多这方面的文章,如果你有的话请与我们分享。

在我看来,使用 facebook/google 等登录可以大大减少创建新账户的障碍。但请确保你不要我的朋友列表和各种其他权限,否则我就不和你玩了!

报告 bug 的另一个问题是开发者缺乏兴趣。有时,用户甚至被要求提供大量需要花费时间收集的信息。然后没有人关心用它做任何事情...只是在说反话。

维护一个不是你开发的软件包更糟糕,因为你没有完全的控制权。可悲的是,通常上游开发者对修复东西不感兴趣,然后链条中的每个人都会感到沮丧。

知识共享许可协议本作品根据知识共享署名-相同方式共享 3.0 未本地化版本许可协议进行许可。
© . All rights reserved.