From 35ac4d4beac100bc426915c3867cc44ba3c74544 Mon Sep 17 00:00:00 2001 From: ORH <512574561@qq.com> Date: Wed, 25 Nov 2020 10:29:06 +0800 Subject: [PATCH] =?UTF-8?q?update(5.3):=20=E6=8E=92=E7=89=88?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...73\347\220\206\346\236\266\346\236\204.md" | 22 +++++++++---------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git "a/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" "b/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" index 57c1e8d..609cfb5 100644 --- "a/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" +++ "b/\347\254\254\344\272\224\351\203\250\345\210\206\342\200\224\342\200\224\345\274\200\346\272\220\346\262\273\347\220\206/\345\274\200\346\272\220\351\241\271\347\233\256\347\232\204\345\270\270\350\247\201\346\262\273\347\220\206\346\236\266\346\236\204.md" @@ -1,18 +1,18 @@ -### 3种常见的开源项目治理架构。 +### 3 种常见的开源项目治理架构。 - **BDFL:** BDFL 是英文“benevolent dictator for life” 的缩写。中文翻译为“仁慈的终身独裁者” 。在此架构下，有一个人（通常是项目的最初的作者，或者是社区选举的一个人）拥有项目中所有最后的决定。较小的项目可能默认就是 BDFL 结构，因为此类项目一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构，以便掌握项目的决策权。 - 例如：Python 就是一个非常经典的BDFL例子。在此架构下，“独裁者”如何进行权力的交接？如果想扩展阅读也可以关注下Python 之父 Guido van Rossum的退位邮件。“[python-committers] Transfer of power” -https://mail.python.org/pipermail/python-committers/2018-July/005664.html + **BDFL:** BDFL 是英文「benevolent dictator for life」的缩写。中文翻译为「仁慈的终身独裁者」。在此架构下，有一个人（通常是项目的最初的作者，或者是社区选举的一个人）拥有项目中所有最后的决定。较小的项目可能默认就是 BDFL 结构，因为此类项目一般就是一到两位维护者。若是公司组织的项目也极有可能会采用 BDFL 结构，以便掌握项目的决策权。 +例如：Python 就是一个非常经典的 BDFL 例子。在此架构下，「独裁者」如何进行权力的交接？如果想扩展阅读也可以关注下 Python 之父 Guido van Rossum 的退位邮件。[[python-committers] Transfer of power](https://mail.python.org/pipermail/python-committers/2018-July/005664.html) - **Meritocracy （精英制）: ** 在精英制下，活跃的项目贡献者（他们用行动证明自己是”精英”）给出一个正式的决策作用，决定通常会基于纯粹的投票一致性。精英制的概念首次由Apache Foundation 提出；所有的Apache 项目 都是基于精英制的。贡献者只能代表自己是独立的个体，不可以是公司。 - (注: 术语 “精英制” 对于一些社群可能具有消极的含义，其拥有较复杂的社会和政治的历史 .) + **Meritocracy（精英制）:** 在精英制下，活跃的项目贡献者（他们用行动证明自己是「精英」）给出一个正式的决策作用，决定通常会基于纯粹的投票一致性。精英制的概念首次由 Apache Foundation 提出；所有的 Apache 项目都是基于精英制的。贡献者只能代表自己是独立的个体，不可以是公司。 +(注: 术语「精英制」对于一些社群可能具有消极的含义，其拥有较复杂的社会和政治的历史。) - **Liberal contribution（自由贡献）: ** 在自由贡献的模式下，做最多工作的人通常被认为是最具影响力的，但是是基于当前的工作，而不是历史的共享。项目的重大决策是基于寻求共识的过程（对不同的声音要讨论）而不是纯粹的投票，尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有Node.js 和 Rust 。 + **Liberal contribution（自由贡献）:** 在自由贡献的模式下，做最多工作的人通常被认为是最具影响力的，但是是基于当前的工作，而不是历史的共享。项目的重大决策是基于寻求共识的过程（对不同的声音要讨论）而不是纯粹的投票，尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有 Node.js 和 Rust。 应该选择哪一种模式了呢？每个模式都有优点，也有缺点。如果是非公司开源项目，可以在开始的时候简单定义基本的流程。例如，你可以将某些预期的行为定义清楚，贡献的流程是如何的，或者项目是如何启动的，等等。如果是公司开源的项目，在启动之前，应该做一些讨论，如公司将会如何维护项目，随着项目的发展，决策该如何定夺。可以公开的解释一下，开源之后，公司是否还继续参与贡献，还是完全由社区决定，等等。没有最优的答案，一切在于出自内心的选择。 -##三种治理架构对应的模板，供参考： -# BDFL 模式模版 -# 精英模式模版 -# Node.js 的自由贡献规则 \ No newline at end of file +### 三种治理架构对应的模板，供参考： + +- BDFL 模式模版 +- 精英模式模版 +- Node.js 的自由贡献规则 -- Gitee