1. 关于我们

开源建木社区在“木兰开源社区”孵化成立的开源子社区，致力于为国内开发者与DevOps人员提供极致用户体验，提升开发、上线、运维的效率，让软件用户专注于提供业务价值。

开源建木社区正在孵化的项目有建木、元开源治理框架、开源高校课程体系等项目

建木

建木是一个面向DevOps领域的极易扩展的开源无代码(图形化)/低代码(GitOps)工具。可以帮助用户轻松编排各种DevOps流程并分发到不同平台执行。

元开源

开源建木社区以建木治理模式为基础推出了“元开源”治理框架，为广大开源项目提供完整的开源治理解决方案。

开源教学

开源建木团队与CCF、GitLink、东华大学、温州大学等高校和组织合作、共同研发高校开源课程体系、促进产学研用各方面的开源领域交流，让学生理论与实践相结合的方式参与到开源项目，培养开源人才。

https://www.gitlink.org.cn/glcc

2. 发展历程

3. 治理框架

治理模式

建木项目的个人贡献者可以成为团队的成员，每个团队都有明确的目的与职责以及所负责维护的git库列表。

团队通过在Gitee上的Issue与Pull Requests等功能进行协作与共创。理想情况下，团队会根据职责边界进行划分，来承担建木项目在不同领域的职责。一个代码库通常应该只属于一个团队，以便于多个团队可以在不同领域进行合作。

例如：

• 核心团队对RFC流程和相关设计原则拥有权威，但不能直接推送到建木代码库。
• 维护团队有权管理建木代码库并提交RFC以制定符合建木核心设计原则的路线图。
• 核心团队与维护团队合作，以确保新的提案不会带来不必要的风险或成为代码维护的负担。
• 维护团队通过对建木代码库的Pull Requests来实现提案的规划和实施，日常BUG修复。
• 基础架构团队维护建木项目所涉及的基础代码库、基础配置、CI\CD环境、测试环境和资源等基础设施及所需代码维护。
• 社区团队负责建木各媒体渠道的运营，通过线上、线下的活动吸引建木贡献者和用户，并建立开源共赢的生态合作。

随着更多职责边界被发现，团队可能会从更大的团队中分离出来。应特别注意承担过多职责的团队，因为可能会忽略重要的领域。

贡献者

贡献者描述可以提交到./contributors目录下，提交的Pull Requests将由核心团队成员进行审查。欢迎贡献者们提交，之后你的相关信息会体现在对应的发布贡献者清单中。

该文件的名称应与您的gitee账号一致，每个./contributors/*.yml 文件都有以下字段：

• name - 贡献者的真实姓名，或者如果不想公开，也可以使用昵称。
• gitee - 贡献者的Gitee登录名。

每个贡献者都将被授予建木Gitee组织的成员资格。这并不会带来太多权限的提升，因为所有代码库的访问权限都是由所负责的团队单独管理。

团队

团队描述可以提交到./teams目录下。提交的Pull Requests将由所负责的团队成员审核，核心团队将会联系所有受影响的团队或个人进行审核。

每个 ./teams/*.yml 文件都有以下字段：

• name - 团队名称，与文件名相同,使用英文小写。
• purpose - 团队关注点的一个简要描述。
• responsibilities - 团队职责的详细列表，或一个职责列表说明的链接。
• members - 团队的贡献者列表，例如./contributors/foo.yml的foo。
• repos - 团队的Gitee代码库列表。

每个团队都必须有一个明确的目的来说明其目标，团队还负责维护其职责清单。这样做可以为新人澄清团队的范围，并且更容易判断团队何时超负荷从而决定何时对团队进行拆分或重组。

每个团队都列出了与./contributors下的文件名相对应的成员（不带 .yml）。

每个团队都列出了具有维护权限的Gitee代码库。

虽然每个团队都可以确定自身的工作模式与流程，但还是强烈建议每个团队的工作都能做到公开透明，无论是在Gitee上还是在其他可以公开访问的工具上，只要这样做有利于团队与社区发展。

建议：团队流程可以在一个由团队专门管理的新代码库中定义。可以通过向此代码库提交PR来创建团队代码库。请参阅代码库。

议事规则

除非通过团队自己的流程另有说明，否则任何决策都是通过团队成员投票达成。

每项决策都需要66%以上的投票比例才能通过。（实施上述流程也将需要66%的投票比例。）

投票可以通过PR审查、发表评论或其他某种形式的记录来发起，过程和结果最好是能永久保存。

团队不需要有指定的领导者，团队可以选择指定一名领导者并通过团队之间的投票来定义他们的角色和职责。

成员准入与退出机制

加入团队

要提议添加团队成员（您自己或代表其他人），请先提交将他们添加为贡献者PR，然后再提交将他们列为所需团队成员的PR。

将某人添加到团队的PR需要足够多的批准审阅者才能通过投票过程。审查PR的社区团队成员负责根据目标团队的规模和投票流程确定所需的投票数，并在获得必要的票数后合并PR，如果无法获得必要的票数则关闭PR。

核心治理团队的加入规则并无特殊性，投票可能完全是基于成员的主观判断，加入的难度因团队而异。一般来说，没有事先交流或前期的信任基础的申请几乎肯定会被拒绝。

离开团队

团队成员可以随时通过提交PR将自己从成员列表中删除来选择离开团队，自愿离开团队不需要投票。

要将其他人从团队中删除，请提交PR，它将使用与加入相同的投票流程。被提名要除名的成员也一样可以参与投票。

建议：各团队定期回顾贡献者和团队成员对项目的贡献情况，来决定吸纳和移除团队成员，从而保障团队内的活跃度。

创建新团队

可以随时通过提交PR来申请组建新团队，由核心团队审核后组建和确定团队成员和初始职责。（只有一个成员的团队不是一件好事，所以请尽量招募团队成员。）

如果一个新团队是从更大的团队中拆分出来的，您将必须协商相关代码库的所有权，理想情况下将它们完全转移到新团队。（这显然需要得到原始团队的批准。）

代码库说明

建木项目的代码库描述放在./repos目录下，更新的Pull Requests将由基础架构团队审查。

每个./repos/*.yml文件都有以下字段：

• owner - 代码库所属空间地址（企业、组织或个人的地址path）。
• repo - 代码库路径（path）。
• name - 代码库名称。
• description - 代码库描述，可选。
• private - 代码库公开或私有。
• default_branch - 默认分支。
• homepage - 主页（eg: https://jianmu.dev），可选。
• has_issues - 允许提Issue与否，默认：允许（true）。
• has_wiki - 提供Wiki与否，默认: 提供（true）。
• can_comment - 允许用户对代码库进行评论，默认：允许(true)。
• issue_comment - 允许对“关闭”状态的 Issue 进行评论，默认：不允许(false)。
• pull_requests_enabled - 接受 pull request，协作开发，默认：允许（true）。
• online_edit_enabled - 是否允许代码库文件在线编辑，默认：允许（true）。
• lightweight_pr_enabled - 是否接受轻量级 pull request，默认：允许（true）。

所有代码库均配置为合并PR后删除分支。

代码库的永久删除必须由基础架构团队的成员手动完成。

Gitee组织设置

除了本文档外，此代码库还包含建木Gitee组织状态的实时配置，所有配置都会自动应用并每天同步以防止漂移。

治理模式变更

核心团队将审查此流程 (README.md) 的Pull Requests。

4. 行为准则

为了营造一个开放积极的社区氛围，促进社区持续健康发展，无论是项目贡献者还是维护者，均需遵守建木社区行为准则。该准则列出了我们对参与者在建木社区贡献时一些鼓励和不可接受的行为。任何违反该准则的人可能会被社区禁止。

我们鼓励

1. 分享、互助、开放、包容；
2. 宽容和理性地对待不同的看法和意见；
3. 相互尊重；
4. 正向、积极的语言；
5. 专注于对社区有利的事情。

我们不允许

1. 违规行为的报告
2. 不雅词句、人身攻击、故意骚扰和恶意使用；
3. 色情、激进时政、意识形态方面的话题。

我们的义务

项目维护者有责任和义务评判哪些是违规行为，并认真公正地处理这些违规行为。 项目维护者有权利和义务去删除、编辑、拒绝违背本行为准则的评论（comments）、提交（commits）、代码（codes）、问题（issues）等贡献；项目维护者可暂时或永久地封禁行为不当、威胁、冒犯、有害的参与者。

违规行为的报告

如果你发现了社区的违规行为，请通过support@jianmu.dev联系我们来举报。 我们将认真对待并调查，妥善地予以必要的回应。同时，我们有义务保密举报者的信息。