@@ -59,7 +59,7 @@ redirect_from: /zh-cn/leadership-and-governance/
5959
6060对于稍大型点的项目,如果你已经拥有了网页的话,那么请创建一个团队的页面,或者创建一个团队领导的页面。举例来说, [ PostgreSQL] ( https://github.com/postgres/postgres/ ) 就拥有一个[ 很全面的团队页面] ( https://www.postgresql.org/community/contributors/ ) ,而且每位贡献者都拥有简短的介绍。
6161
62- 如果你的项目拥有非常活跃的贡献者社区,你或许会专门建立一个维护者的“ 核心团队” ,甚至是根据不同的话题所有者成立子的委员会(例如,安全,问题筛选,或者是社区准则)。让人们自行组织、且能够让志愿者自行找到自己喜欢的角色,而不是去分配他们。
62+ 如果你的项目拥有非常活跃的贡献者社区,你或许会专门建立一个维护者的" 核心团队" ,甚至是根据不同的话题所有者成立子的委员会(例如,安全,问题筛选,或者是社区准则)。让人们自行组织、且能够让志愿者自行找到自己喜欢的角色,而不是去分配他们。
6363
6464<aside markdown =" 1 " class =" pquote " >
6565 \[ 我们\] 为核心团队设立多个"子团队"。每个子团队都会专门的聚焦于某个特定的领域,举例来说,语言设计或程序库(...) 为了确保全局的协调和健壮,会将整体的项目设置为同一个愿景,每个子团队是由核心团队的一员。
@@ -98,9 +98,9 @@ redirect_from: /zh-cn/leadership-and-governance/
9898
9999关于开源项目有三类通用的相关治理结构。
100100
101- * ** BDFL:** BDFL 是 “ 终身仁慈独裁者” 的缩写. 在此结构下,有一个人(通常是项目的最初的作者)拥有项目中所有的最后决定权。[ Python] ( https://github.com/python ) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构,因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
101+ * ** BDFL:** BDFL 是 " 终身仁慈独裁者" 的缩写. 在此结构下,有一个人(通常是项目的最初的作者)拥有项目中所有的最后决定权。[ Python] ( https://github.com/python ) 就是一个非常经典的例子。较小的项目可能默认就是 BDFL 结构,因为他一般就是一到两位维护者。若是公司组织的项目也极有可能会采用BDFL结构。
102102
103- * ** 精英制:** ** (注: 术语 "精英制" 对于一些社群可能具有消极的含义,其拥有较[ 复杂的社会和政治的历史] ( http://geekfeminism.wikia.com/wiki/Meritocracy ) .)** 在精英制下,活跃的项目贡献者(他们用行动证明自己是“精英” )给一个正式的决策作用,决定通常会基于纯粹的投票一致性。精英制的概念首次由[ Apache Foundation] ( https://www.apache.org/ ) 提出;[ 所有的Apache 项目] ( https://www.apache.org/index.html#projects-list ) 都是基于精英制的。贡献者只能代表自己是独立的个体,不可以是公司。
103+ * ** 精英制:** ** (注: 术语 "精英制" 对于一些社群可能具有消极的含义,其拥有较[ 复杂的社会和政治的历史] ( http://geekfeminism.wikia.com/wiki/Meritocracy ) .)** 在精英制下,活跃的项目贡献者(他们用行动证明自己是"精英" )给一个正式的决策作用,决定通常会基于纯粹的投票一致性。精英制的概念首次由[ Apache Foundation] ( https://www.apache.org/ ) 提出;[ 所有的Apache 项目] ( https://www.apache.org/index.html#projects-list ) 都是基于精英制的。贡献者只能代表自己是独立的个体,不可以是公司。
104104
105105* ** 自由贡献:** 在自由贡献的模式下,做最多工作的人通常被认为是最具影响力的,但是是基于当前的工作,而不是历史的贡献。项目的重大决策是基于寻求共识的过程(对不同的声音要讨论)而不是纯粹的投票,尽可能的努力的去囊括多的社区观点。较流行的使用自由贡献模式的项目有[ Node.js] ( https://foundation.nodejs.org/ ) 和 [ Rust] ( https://www.rust-lang.org/ ) 。
106106
@@ -134,7 +134,7 @@ redirect_from: /zh-cn/leadership-and-governance/
134134
135135将商业的活动视为正常不过的事情很重要,它也只是代码的开发方法之一。为开发者付费不应该被特殊的对待,好像代码必须是无偿开发的才行;每个贡献都必须有技术的衡量标准来进行评估。人们应该在这些商业的活动中感到非常的自在,而且针对特定的增强或功能项讨论时也应是坦荡的、自然的。
136136
137- “商业” 是完全和“开源” 相容的。“商业” 仅仅是意味着某些地方有钱的参与 —— 就是说软件被用于了商业行为,也就是说项目被采用获得了认可。(当开源软件被用于非开源产品的一个部分时,这个整体的产品仍然是"专有的"软件,因为开源,它可以用于商业或非商业的目的。)
137+ "商业" 是完全和"开源" 相容的。"商业" 仅仅是意味着某些地方有钱的参与 —— 就是说软件被用于了商业行为,也就是说项目被采用获得了认可。(当开源软件被用于非开源产品的一个部分时,这个整体的产品仍然是"专有的"软件,因为开源,它可以用于商业或非商业的目的。)
138138
139139和这个世界上很多的其它商业产品一样,商业能够激励开发者去积极的贡献于项目,通过他们靠谱的提交贡献。显而易见的是,一位因花了自己的时间和精力的开发者获得报酬,理应比没有获得报酬的更具持久性,当然,这对于某些圣徒是不成立的,或者这么说吧,报酬是能体现一个贡献度的众多衡量因素的其中之一。所以将你的项目讨论聚焦于贡献上,不要让人们分散精力去思考或做其它的事情。
140140
0 commit comments