# 建木治理框架

**Repository Path**: bigcoder84/governance

## Basic Information

- **Project Name**: 建木治理框架
- **Description**: 建木社区治理框架
- **Primary Language**: Unknown
- **License**: MulanPSL-2.0
- **Default Branch**: master
- **Homepage**: None
- **GVP Project**: No

## Statistics

- **Stars**: 0
- **Forks**: 53
- **Created**: 2023-01-10
- **Last Updated**: 2024-05-31

## Categories & Tags

**Categories**: Uncategorized

**Tags**: None

## README

# 建木治理框架

本文档概述了一组政策，以便为贡献者加入**建木**项目提供公平的环境和开放的流程。

## 治理模式

**建木**项目的个人贡献者可以成为团队的成员，每个团队都有明确的目的与职责以及所负责维护的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](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后删除分支。

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

## 修改治理模式

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

## Gitee组织设置

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