开发者和用户的交流

来源:csslayer.tk 作者:csslayer.tk
  

原文地址: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社区保持友爱,保持用户和开发者的关系良好。


时间:2011-09-29 15:37 来源:csslayer.tk 作者:csslayer.tk 原文链接

好文,顶一下
(2)
100%
文章真差,踩一下
(0)
0%
------分隔线----------------------------


把开源带在你的身边-精美linux小纪念品
无觅相关文章插件,快速提升流量