OpenBRAS社区章程


OpenBRAS社区章程
OpenBRAS  Community Charter

1,OpenRAS社区的网址是www.openbras.org.cn或www.openbras.org。

2,OpenBRAS社区的目标是推广软件化或虚拟化或微服务化的BRAS(Broadband Remote Access System)系统,BRAS系统能实现软件和硬件解耦,支持控制面和转发面可以分离,控制面支持通用化的云平台,转发面支持通用化的硬件,例如网卡,服务器,白盒交换机等,同时能不断丰富BRAS功能和内涵,能扩展到Central Office端局相关功能。

3,OpenBRAS社区以透明,公开,协作的方式来运作。采用吸引广泛的社会生态系统包括个人或组织(公司)参与,基于专业技术人员贡献,且社区委员会具有决策权的治理模式。和大多数开源社区一样,OpenBRAS社区委员会包括技术委员会和运营委员会,参与社区的相关角色包括维护者Maintainer,贡献者Contributor,递交者Committer,和用户User等。

4,OpenBRAS社区委员会Community Committee(以下简称CC)成员的组成包括社区的发起者和社区的主要维护者。
4a, 社区委员会的构成:
I,社区委员会的成员包括个人或组织(公司)。
II,社区委员会下设技术委员会Technical Committee(以下简称TC)和运营委员会OCOperation Committee(以下简称OC)。
III,每个成员,包括个人或组织(公司),在技术委员会或运营委员会中只能拥有一个席位和投票权。
IV,社区委员会采用投票机制来做出决策。投票规则采用大多数开源社区的设计,相关投票决策采用多数同意原则。
V,现阶段,委员会的成员在包括相关参与方。委员会主席为中国电信广州研究院。技术委员会和运营委员会采用招募制。TC负责社区的技术相关工作,OC负责社区的运营和推广等工作。TC和OC暂各设一名总监,采用竞聘制或推荐制,按要求向委员会主席汇报工作情况和安排工作计划。
VI,随着社区运作的成熟,对社区项目有贡献的相关角色,包括维护者,贡献者,递交者和用户,都可以被任命或选举为委员会的成员。任命的办法和原则参考其它开源社区的设计,经当前委员会经2/3以上同意后,修订为章程的补充条款。

4b, 社区委员会具有以下职责:
I,清楚地沟通社区内外的开源策略
II,拥有和监督战略的执行
III,促进开源产品在商业产品和服务中的有效使用
IV,确保开源代码的高质量和频繁发布
V,与开发者社区进行合作,并看到有效性回馈其他项目
VI,在组织中培养开源文化
VII,维护开源许可遵从性审查和监督
VIII,社区委员会负责指导并与运营委员会和技术委员会一起协商制定社区发展策略。包括OpenBRAS的范围(项目的总体范围),技术愿景和方向,以及对技术委员会的发布指南(例如,通过定期安排的发布周期交付)。委员会通常在具体技术问题,子项目范围或方向上不做决策,只保证相关技术和项目属于OpenBRAS社区的范围和方向。

4c,衡量社区委员会的工作好坏的依据:
I,项目是否得到很好的维护和支持
II,代码是否记录良好
II,是否明确定义了如何参与社区和贡献

5,技术委员会
5a,技术委员会负责社区的所有技术相关的指导和监督。技术委员会制定和协调项目发布日期,发布质量标准,技术最佳实践,监控技术进展,协调提交者和项目负责人之间的技术冲突,以及组织所有项目之间的协作。 OpenBRAS的技术委员会将由核心项目负责人组成。每个项目都有一名技术负责人,该人员将代表技术委员会的项目。项目负责人将通过该项目提交者的投票选出。如果项目最初只有一个提交者,那么该人将成为项目负责人。此外,OpenBRAS的活跃提交者将在组织形成六个月后选出其他技术委员会成员,以确保提交者的多样性。

5b,技术委员会的选举
I,满足本章程的4a章节V和VI条款规定。
II,技术委员会可随时修改选举程序。
III,任何遵守本章程的人或组织(公司)都可以成为贡献者和提交者参与项目。贡献者包括社区中为项目提供代码,文档或其他技术工件的任何人; 提交者是能够修改(“提交”)源代码,文档或其他技术工件的贡献者。通过现有提交者的多数批准和技术委员会的批准,贡献者可以成为提交者。提交者也可以通过其他现有提交者的多数和技术委员会的批准移除其身份。
IV. 技术委员会可以选举技术总监,并经社区委员会任命。技术总监主持技术委员会工作,并亲自或指定技术委员会成员作为与运营委员会或社区委员会的主要沟通联系人。

5c. 投票
I 技术委员会进行决定需要投票来推动项目,技术委员会所有成员都有一票投票权。
II. 技术委员会的法定人数要求所有投票成员中至少有50%出席。如果未达到法定人数,技术文员会可以继续开会,但将无法在会议上做出任何决定。
III 如果出席人数满足法定人数,则在会议上通过表决作出的决定需要达到出席者的多数票。如果通过电子投票来作出的决定需要大道所有投票的多数票。
IV 如果技术委员会无法通过投票做出决定或解决问题,技术委员会的任何投票成员可将此事项提交给社区委员会,以获得社区委员会的协助以达成解决方案。

5d  技术委员会职责
技术委员会负责与项目技术有关的监督的所有方面,其中可能包括:
I。协调项目的技术方向,包括实现项目任务和范围的架构和项目;
II。根据技术委员会制定,批准和维护的项目生命周期文件批准项目或系统提案(包括但不限于孵化,弃用和子项目范围的变更);
III。在所有项目中组织子项目和删除项目并促进技术协调(API,数据模型等);
IV。建立小组委员会或工作组,专注于跨项目技术问题和要求;
v。在需求,高级架构方面协调技术社区与最终用户社区的互动,实施经验,用例等;
VI。修改社区代码的审查政策;
VII。与外部和行业组织就项目技术问题进行沟通;
VIII。任命代表与其他开源或开放标准社区合作;
IX。建立社区规范,工作流程,发布版本和安全问题报告政策;
X。经系列经理批准,采用和修改任何捐赠程序或程序;
XI。确定技术委员会投票成员的组成,并为任何技术角色选举或成员选举建立选举程序和修改选举程序文件;
XII。讨论,寻求共识,并在必要时就与影响多个项目的代码库相关的技术问题进行投票;

6. 遵守规则
6a。本章程受社区和项目项目系列协议和LF项目运营协议的约束。贡献者将遵守LF项目可能采用和修订的LF项目的政策,包括但不限于https://lfprojects.org/policies/中列出的政策。
6b, TSC可以为项目采用行为准则(“CoC”),但需经系列经理批准。项目的贡献者将遵守CoC,或者如果项目特定的CoC未获批准,则遵守https://lfprojects.org/policies/中列出的LF项目行为准则。
6C。在修改或采用适用于该项目的任何政策时,LF项目将在该政策生效前至少30天在其网站上公布该修订或采纳的政策;但是,如果对LF项目的商标政策或使用条款进行任何修改,任何此类修订在LF项目网站上公布后生效。
6d。所有参与者必须允许任何符合本章程要求的个人或组织的公开参与以及TSC为所有参与者采取的任何政策,无论竞争利益如何。换句话说,项目社区不得寻求根据任何标准,要求或理由排除任何参与者,而不是那些合理的,并且在非歧视的基础上应用于项目社区的所有参与者。
6e 该项目将始终以透明,开放,协作和道德的方式运作。所有项目讨论,提案,时间表,决策和状态的输出应该公开,并且所有人都可以轻松看到。任何可能违反此要求的行为都应立即报告给LF项目经理。

7,社区资产
7a, 社区对项目使用的所有商务或服务的商标拥有所有权。项目参与者对任何项目商标的任何使用均应满足社区的许可和要求,并符合社区的利益。
7b, 项目应允许并根据社区的许可,开发和拥有所有Project GitHub和社交媒体账户,以及项目社区创建的域名注册。

8,知识产权
8a,社区承认并满足所有上游(开源)代码的许可和许可证要求,包括依赖性要求。
8b,社区项目所有新贡献的代码和文档必须使用Apache License 2.0许可。
8c,社区承认所有新贡献代码的版权应由版权所有者保留为独立的作品,且不需要贡献者或版权所有者将版权转让给项目或社区。
8d,提供的代码文件应包含许可信息。社区技术委员会可以在任何时候(包括在提交之前)进行许可合规性审查,以验证贡献是否符合章程的相关条款。

9,补充条款
该章程的修改,需要通过整个OpenBRAS社区投票进行。经社区成员投票,并超过三分之二投票同意后,可进行修改并作为章程的补充条款。

10,OpenBRAS社区的各种角色说明
10a,维护者Maintainer
维护者采用自愿制和邀请确认制。
维护者应对社区全面负责。负责设定项目的战略目标,并与社区进行明确沟通。还必须了解整个社区,尽可能满足各种相互矛盾的需求,并确保项目的长期发展。
随着项目的扩展,关键是要确保合适的人选对项目施加影响,以及社区团结一致,共同实现项目主管的愿景。因此,维护者的职责是确保提交者作出有利于项目的正确决策。一般来说,只要提交者能够遵循项目策略,维护者会允许他们以自己喜欢的方式提交。

11b,贡献者Contributor
贡献者是不想成为提交者,或者维护者还未赋予其成为提交者的社区成员。贡献者对项目作出有价值的贡献,但通常没有直接更改项目代码的权限。贡献者参与项目的途径包括邮件列表等通信工具,以及就问题跟踪器中的问题提交报告和修补程序。
任何人都可以成为贡献者。贡献者无需对项目作出承诺,无具体技能要求,也无需经过筛选。

要成为贡献者,社区成员只需为项目作出一两个有益的贡献。一些贡献者早已成为项目的用户,并在以下一两个领域有所作为:
· 支持新用户(当前用户往往能最有效地支持新用户)
· 报告 bug
· 识别需求
· 提供美工和 Web 设计
· 编程
· 协助项目基础设施建设
· 撰写文档
· 修复 bug
· 添加功能

随着贡献者项目经验的增加和对项目了解的深入,项目主管对他们的依赖逐渐加深。此时,他们就会逐步担任起提交者的角色。

11c,递交者Committer
提交者是曾经为项目作出有价值的贡献,目前直接向资源库编写代码并筛选他人代码的参与者。
提交者是程序员,但有时也可能是其他贡献者。
提交者通常关注项目的某个方面,并以其专业技能和理解水平赢得社区和项目主管的尊重。提交者无需正式任命,为项目主管提供指导和支持的有影响力的社区成员即是提交者。
提交者无法决定项目的整体发展方向。但是他们受到项目主管的重视。提交者的职责是确保项目主管了解社区需求和共同目标,参与项目开发或促成对项目的贡献。他们往往对自己负责的具体领域拥有非正式的控制权,并有权直接对某些领域的源代码进行修改。也就是说,提交者虽然没有明确的决策权,但他们的行为往往与项目主管的决策具有同等效力。

11d,用户User
用户是对项目有需求的社区成员。他们是社区最重要的成员。没有了用户,项目将毫无意义。
任何人都可以是用户,没有具体要求。

我们鼓励用户尽可能多地参与到项目和社区中来。用户的参与确保项目团队能够满足用户的需求。
常见的用户活动包括(但不限于)以下方面:
· 推广项目
· 从新用户的角度,告知开发者项目优势和劣势
· 提供精神支持(一句“谢谢”就是很大的鼓励)
· 提供资金支持
持续参与到项目和社区中的用户往往会发现他们越来越深入其中。此类用户可能会进而发展为贡献者。

12,此文档修订于2018年7月15日