【转载】（译文）开发者和用户的交流

原文地址：http://blog.martin-graesslin.com/blog/2011/09/developer-and-user-interaction/

译者：

对一个自由软件项目，例如KDE的许多项目来说，需要的不是用户，而是更多开发者。不能进行开发的用户帮助不大。因为让用户学习编程并修复bug是完全可以接受的。

以上观点和用户要求修复bug或者辱骂那些花费空闲时间完成了不起的项目的开发者一样荒谬。

我想指出的是，对自由软件项目来说，用户和开发者的关系是十分特殊的。我们既需要开发者，也需要用户。开发一个没人用的软件有什么意思？如果没有开发者那么新软件又从哪来？

最近发生在邮件列表上的事，以及以前发生的类似事件，让我最终写下了这篇酝酿已久的blog。我希望这篇blog可以帮助改善用户和开发者的交流。我要首先指出我并非这方面的专家，以下意见都是个人的观点和感受。

自由软件的价值

自由软件是件很了不起的事情：成百上千的开发者用他们的业余时间编写软件，并且不仅仅免费提供这些软件，同时也给予了你们对代码做任何想做的事情的权利。不止如此，你还可以直接向开发者进行反馈：通过汇报Bug，通过邮件列表，通过Blog，还有其他各种渠道。每个用户都可以直接和开发者交流。用户和开发者之间没有昂贵的支持热线。在你想要抱怨和开发者交流时请请牢记这点。这是我们非常重要竞争力，如果失去它对我们是重大损失。

开发者并不邪恶

没有开发者想要消灭他自己的软件。没有开发者是有意引入Bug的。没有开发者忽视Bug修复。无论你怎么想，开发者都不是邪恶的。他们和你作为用户相比，对一个成功的产品更加感兴趣。这是他们花时间做的事情，这是他们喜欢做的事情。如果一个开发者没有修复一个Bug，或者压根就没回应，并不是他不在乎，更有可能的是他可能没注意到，或者是他没有遇到，或者是他这会没空，或者还有其他原因。但不会是对用户的忽视。同时开发者不会有意移除功能来伤害用户。他们想的比一堆功能更多更远。有时候必须将朽木移除才能让事情变得更好。这个决定可能对你不好，但是总体来说对多数人更有益。开发者不会为了修改而修改——实际我们很懒的。

你并不是开发者

记住你并不是开发者。不要尝试和开发者讨论技术细节：你赢不了的。不论你的观点多好，不论你有多么聪明，开发者更有可能是这个领域的专家，并且对问题有更好的看法。如果他告诉你一件事情不可能，那么多半就是这样的。如果他告诉你他修复不了一个bug，那事实就是如此。如果他不得不移除一个功能，那么他确实不得不这么做。请接受事实，不要争辩，否则你只是在做蠢事而已。

开发者可能很忙

即使是开发者也可能很忙：他们白天有工作，他们可能在上学，他们可能要写论文。如果他们不能立即回复你的bug汇报，请保持淡定。也许需要几天，甚至几个月，才能得到回复。虽然这并不理想，但是事情就是这样的。请同时尊重开发者的私生活：不要在IRC不经过允许就直接询问他们，不要给他们个人发送邮件来要求修复Bug。至少对我来说，这是一个用来确定Bug近期不会修复的办法。想想吧，如果每个人都通过私人邮件汇报Bug，这就完全没法承受了。

Bug只属于Bug Tracker

这很显然，不是吗？Bug Tracker是唯一可以保证Bug被跟踪的工具。文章中的评论并不会修复Bug，邮件列表的邮件也可能被忽视。请使用Bug Tracker。尽管它看起来像个垃圾场，但这是最好的办法了。

不用指出明显的事实

在Bug Tracker处于未解决状态的Bug就是还没修复的Bug。你没必要在每个小版本发布的时候都来汇报说这个Bug还没有修复。如果Bug被修复了，那么这个Report就会被标记为关闭，或者你也可以来关闭它。重复指出明显的事实仅仅会使得我已经很满的邮箱更加拥挤，而且不会增加我在下次发布修复这个Bug的概率。

并非所有Bug都是平等的

就算那个bug真的对你影响很大，不过也不要假设所有人都遇见了这个Bug。很可能没有一个开发者使用过程和你相同。因此一个明显的Bug可能对开发者来说也是完全不可见的。同时开发者在运行一个和你不同的版本：他们运行的是最新的开发版，他们不会注意到老版本上的Bug。因此不要假设所有人都遇见了你的Bug。

每个人都有他重视的Bug

是的，你不是唯一一个遇见bug的人。在写这篇文章的时候，KDE的Bug Tracker有23374个打开的Bug汇报，并且每周会增加400新的bug汇报（会关闭更多）。因此每个用户都有他自己的非常重要的Bug等待修复。同时那些打开的Bug已经超出了开发者修复的能力。正因为这是软件，因此这个现象很正常。因此请不要催促赶快把某个bug修复掉。正因为我是开发者，因此我决定了哪个Bug应该修复，如果我发现你认为你的Bug比其他人的更重要，我可能回去修复其他人的Bug。

不要辱骂

尽管这很显然，但实际不是。不要辱骂开发者。这没有任何帮助。难道你认为如果你在骂我之后我就会去修复你的问题吗（我并没遇到这个问题）？辱骂毫无建设性并且十分有害。请记住我们花费了业余时间。如果我因为我的爱好而挨骂，那我有可能就会选择其他爱好。和让开发者离开社区相比，你的问题一点都不重要。

我们没在走GNOME的路

在需要添加或者移除一个被需要的功能的时候，这是我最讨厌的一种争论方式。没人要走GNOME的路，并且这是对我所尊重的GNOME开发者极大的侮辱。这样的争论没有任何帮助：你想要一个功能，并且你尝试用这种方式来说服我？如果你需要用真实的需求说服我们添加功能，请记住开发者不光是需要维护一堆功能而已。
新特性是需要代价的

每个新增的功能都意味着需要维护更多的代码，有更多的代码路径可能因此出问题，需要花费更多的时间，只有少数用户才会用到对应的代码并因此使得测试变得更加困难。有些是合适的功能，有些是不合适的功能。如果开发者拒绝了你的想法，请接受它。他需要考虑的比仅仅增加一堆功能更多。同时也请想想你的那个很棒的相反难道以前就没人考虑过吗？另外请使用 brainstorm.forum.kde.org 来建议新的功能。其他方式都有可能被忽视。

开发者的邮件列表是属于开发者的

如果用户能够通过阅读内部邮件列表来跟随开发进度，这是件很棒的事。但是请记住这是一个需要让开发者畅所欲言的地方。他们在这里交流想法他们可能在这里争论他们的想法。不要随便跳进来并说你认为开发者有多愚蠢。邮件列表不是给用户而是用于获得其他开发者有价值的反馈的。请记住这点，不要把讨论带领到错误的方向。

你不需要学会C++才能帮助我们

所有人都能提供帮助，所以请来帮助我们吧。说服开发者修复你的bug的最好的办法就是加入社区。文档需要撰写，翻译需要进行，市场团队需要帮助，用户支持缺乏人员，设计人员需要更多人手，bug tracker需要清理。特别是如果你讨厌你的bug没有得到修复，请帮助开发团队清理无用和重复的bug汇报。

我希望这些能够帮助KDE社区保持友爱，保持用户和开发者的关系良好。

声明：笨兔兔原创文章，博客文章遵循CC协议，转载需注明@笨兔兔，本文链接地址

文稿投递|文章写作规范|欢迎加入QQ群:121584708（此群已满）；2群：170591351；Gtalk群:[email protected]

您可能也喜欢：

Linux用户须知7款交流工具

系列：Ubuntu 开发（一）

系列：Ubuntu 开发（二&三）

Ubuntu 9.10+ 用户安装 Medibuntu

笨兔兔“在线交流试验田”

无觅