返回介绍

3.17 冲突和冲突解决

发布于 2024-10-11 21:30:14 字数 841 浏览 0 评论 0 收藏 0

我们已经看到设计权的分布和所有权的分散会导致项目角色复杂性增加,虽然它是一种有效的激励分配机制,但同时也稀释了项目领导者的权力,稀释了领导者平息潜在冲突的权力。

有关设计的技术争议看上去很容易引起内部两败俱伤的争执,但它们很少真的能引起严重冲突,这些争议通常可较容易地由领土规则(也即“责任背后是权力”)解决。

另一个解决冲突的方式是“资深者胜”——如果两个或更多个贡献者有分歧,该分歧在客观上很难解决,并且谁也不拥有该分歧的领土权,那么在整个项目中投入工作最多的一方(也即在整个项目中拥有最多领土权的一方)胜出。

(对应地,投入最少的一方输掉。很有意思的是,很多关系型数据库也采用了同样的启发性方法解决死锁问题,当两个线程在资源上造成死锁时,在当前事务中投入最少的那个线程将会成为死锁受害者并被终止掉,而运行事务时间最长的或级别更高的,则会成为胜利者。)

这些规则通常足以解决大多数的项目争议,如果还不行的话,则由项目领导人来决断。以上这些办法都不起作用的情形非常罕见。

冲突通常不会变得很严重,除非两种评判标准(“责任背后是权力”和“资深者胜”)指向不同方向且项目领导人权力较弱或者缺位时。发生这种情况最显而易见的例子是项目领导人消失后的继承权争议,我曾经历过一次这样的争斗,其过程令人厌恶、充满痛苦且旷日持久,直到所有相关方都耗尽心力而不得不交给外部人士处理时,问题才得到解决,我真心希望永远也不再和这种事扯上任何一点儿关系。

最后,若想让这些冲突解决机制生效,需要整个黑客社区愿意执行它们,唯一可用的执行机制是“批判”和“放逐”——公开谴责那些破坏习俗的人,并拒绝和他们再次合作。

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

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

发布评论

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