Bugzilla和News

××××××××××××××××××××××××××××××××××××××
作者：王乐珩
欢迎访问joyfire.net
××××××××××××××××××××××××××××××××××××××

　　Bugzilla、新闻组或者邮件列表都是收集用户反馈的工具。项目最初发布后，最大的
问题就是解决用户报告的BUG。

　　每个和你联系的用户都该记录email地址，以便用来保持他对你的项目的兴趣，例如利
用群体邮件对新版本进行通告。但是实际上这些用户应该存在两个子集，一个是普通用户
列表，另一个是更重要的帮助者。就像《大教堂与集市》里说的，程序发布后，作者会被
潮水般“我要怎么做才能帮你”的邮件淹没，但90%名义上的志愿者根本帮不上任何忙。它
们的价值甚至连报告BUG的用户都不如。

　　真正有价值的是发来这样邮件的人：“hi，我下载了你的源代码，发现BUG，这是修
改后的补丁”，“刚好，这里有段代码可以增加你软件的功能”。他们才是项目发展的动
力，而且很多人会变成你技术上的老师或者生活上的好友，应该和他们建立牢固关系。另
外，负责人最后一件应该做的事情，就是在失去维护项目的兴趣或者能力前，找到合适的
接替者。你认为最合适的人选会在哪里呢？

　　由上面的建议可以看出，用户反馈并不总是有用的，太多的要求会超出作者的能力范
围之外，不切实际的许诺和幻想也都是由此而来。很多失败的案例里，卤莽虚荣地宣布没
有把握的宏伟幻想，或者妄想一天之内就建立完美的志愿者团队100%负责软件各部分，最
终都导致浮精疲力尽却一无所获。像做生活中任何事情一样，应该谨慎冷静地思考后再开
始，然后保持低调、坚韧和适度乐观，在软件和团队没有完全成熟前，确保自己能掌握一
切。

　　有人总结说，项目启动以后只需要做三件事：说“YES”、说“NO”、把新代码加入新
版本，其中说“NO”更多。有些时候选择纯粹是就一种选择，没有理由，但是解释和仲裁
必须让对方信服，这就是累人的地方。

up

分多可以捐出去呀

"保持低调、坚韧和适度乐观"
呵呵，看看大家常常喊出来的口号就知道保持低调有多难了。