返回介绍

作为一些个体出现,而不是一个整体

发布于 2021-02-02 13:27:32 字数 799 浏览 879 评论 0 收藏 0

你的开发者必须力求在项目的公共论坛中以一个单独的参与者出现,而不是一个单独的公司。这不是因为作为一个公司出现本身固有的一些负面含义(好的,或许有一些,但那不是本书所讨论的)。而是因为开源项目的结构配备只能处理个人实体。一个单独的贡献者可以讨论、提交补丁、获取信誉、表决等等。而一个公司不能。

此外,因为分布式的行为方式,你避免了对于刺激性中央集权的敌对。让你的开发者在邮件列表中意见并不一致。鼓励他们经常评审他人的代码,尽可能的公开,就象他们是任何其他的人。阻止他们象一个集团一样表决,因为如果你这样做,其他人就会感觉到,根据一般的原理,一定有一个有组织的力量在控制他们。

实际的非中央集权和假装的是有区别的。在特定环境下,让你的开发者协同一致会非常有用,而且如果必要还必须在幕后进行协调。例如,当发出提议时,让许多人尽早跳出来表示认可,得出正在达成共识的印象会有助于提议的进展。其他人会感到提议的动量,如果他们反对,他们需要阻止这个动量。因此,人们只会在有好的原因时才会提出反对。如果能够慎重对待反对意见,这样的精心安排也没有错。私下协议的公众表现不会因为经过预先的协调而变得不够诚实,只要他们没有用这个方法来扼杀反对意见就不会有太多害处。他们的目的仅仅是阻止那些喜欢保持个性的人提出反对意见;更多相关内容可以看Chapter 6, 交流the section called “主题越软,辩论越长”

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。
列表为空,暂无数据
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
    原文