From 2c8bd156a33be5af041b37cf8047111d64efcb5f Mon Sep 17 00:00:00 2001 From: yangli Date: Sat, 28 Dec 2019 17:47:38 +0800 Subject: [PATCH] =?UTF-8?q?=E6=A0=B9=E6=8D=AE=E4=BB=8A=E5=A4=A9=E7=9A=84?= =?UTF-8?q?=E6=9C=80=E6=96=B0=E6=84=8F=E8=A7=81=E4=BF=AE=E6=94=B9?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Governance.md | 26 ++-- README-ch.md | 60 ---------- README.md | 111 +++++++++++++----- SIG&project-list.md | 25 ---- SIG-list.md | 18 +++ community-membership.md | 66 +++++------ security | 1 + zh/Gitee-Management/Gitee-management-guide.md | 22 +++- zh/contributors/README.md | 48 ++++---- zh/contributors/coding-conventions.md | 2 - zh/contributors/expectations.md | 14 --- zh/contributors/installation.md | 3 - zh/contributors/non-code-contributions.md | 8 +- zh/technical-committee/governance/README.md | 78 +++++++----- ...ents.md => SIG-governance-requirements.md} | 24 ++-- ...roject-governance.md => SIG-governance.md} | 74 ++++++------ .../governance/template-charter/OWNERS.yaml | 0 .../template-charter.md} | 30 ++--- .../governance/template-release.md | 2 +- 19 files changed, 305 insertions(+), 307 deletions(-) delete mode 100644 README-ch.md delete mode 100644 SIG&project-list.md create mode 100644 SIG-list.md create mode 160000 security delete mode 100644 zh/contributors/coding-conventions.md delete mode 100644 zh/contributors/expectations.md delete mode 100644 zh/contributors/installation.md rename zh/technical-committee/governance/{SIG&project-governance-requirements.md => SIG-governance-requirements.md} (63%) rename zh/technical-committee/governance/{SIG&project-governance.md => SIG-governance.md} (44%) create mode 100644 zh/technical-committee/governance/template-charter/OWNERS.yaml rename zh/technical-committee/governance/{template-SIG&project-charter.md => template-charter/template-charter.md} (33%) diff --git a/Governance.md b/Governance.md index 105a70f3d..dbe9aacd5 100644 --- a/Governance.md +++ b/Governance.md @@ -31,23 +31,23 @@ openEuler社区遵循[社区行为准则](code-of-conduct.md) -### SIG/项目 +### SIG ------ -openEuler社区主要的组织构成是**SIG和项目**。 +openEuler社区主要的组织构成是**SIG**。 -每个SIG和项目的共同目的都是针对特定的一个或多个主题，推动交付成果输出，并争取让交付成果成为openEuler社区发行的一部分。SIG/项目的每个可识别的部分都属于该SIG/项目，包括存储库、目录、API、测试、问题、PR等。 +每个SIG的共同目的都是针对特定的一个或多个主题，推动交付成果输出，并争取让交付成果成为openEuler社区发行的一部分。SIG的每个可识别的部分都属于该SIG，包括存储库、目录、API、测试、问题、PR等。 -SIG/项目在任何给定时间内必须至少有一个，或多个Maintainer。Maintainer负责SIG/项目的运作，通过SIG/项目的治理实现特定的目标，并与团队成员一起与技术委员会、其他SIG/项目组、用户进行交流协同。 +SIG在任何给定时间内必须至少有一个，或多个Maintainer。Maintainer负责SIG的运作，通过SIG的治理实现特定的目标，并与团队成员一起与技术委员会、其他SIG组、用户进行交流协同。 -每个SIG/项目都必须有一个章程，其中规定了SIG/项目的范围（主题、代码库、目录等）、职责、权限区域，如何选择/授予权限/领导权的成员和角色，如何制定决策和解决冲突，如何管理章程等信息，请参考[SIG/项目章程](/technical-committee/governance/SIG&project-governance.md)。在一些跨SIG/项目流程（如发布流程）和资产（如存储库）的广泛指导原则约束下，SIG/项目可以相对自定义的更改其操作方式。 +每个SIG都必须有一个章程，其中规定了SIG的范围（主题、代码库、目录等）、职责、权限区域，如何选择/授予权限/领导权的成员和角色，如何制定决策和解决冲突，如何管理章程等信息。在一些跨SIG流程（如发布流程）和资产（如存储库）的广泛指导原则约束下，SIG可以相对自定义的更改其操作方式。 -SIG/项目组内的交流必须是公开的，以确保其他SIG/项目组的社区成员可以找到讨论、会议、涉及和决策的记录，SIG/项目也需要定期向社区传递项目的工作概要。 +SIG组内的交流必须是公开的，以确保其他SIG组的社区成员可以找到讨论、会议、涉及和决策的记录，SIG也需要定期向社区传递项目的工作概要。 -有关SIG/项目的治理的更多详细信息，请参考[SIG/项目治理](/technical-committee/governance/SIG&project-governance.md)、[SIG/项目治理要求](/techniacl-committee/governance/SIG&project-governance-requirements.md)。 +有关SIG的治理的更多详细信息，请参考[SIG治理](technical-committee/governance/SIG-governance.md)、[SIG治理要求](techniacl-committee/governance/SIG-governance-requirements.md)。 -[openeuler.yaml]()中记录了每个SIG/项目。 +[SIG文件夹](sig/)内记录了openEuler社区当前的所有SIG。 @@ -55,19 +55,21 @@ SIG/项目组内的交流必须是公开的，以确保其他SIG/项目组的社 ----- -SIG/项目是在公开场合运作的自愿团体，任何人都可以加入。但因为某些领域需要谨慎处理（例如安全性），所以委员会不公开成员资格，而且并不总是公开运作。 +SIG是在公开场合运作的自愿团体，任何人都可以加入。但因为某些领域需要谨慎处理（例如安全性），所以委员会不公开成员资格，而且并不总是公开运作。 技术委员会可以根据需要，在有限的时间内成立某一特定委员会。委员会的成员资格由技术委员会决定，但所有委员会成员必须是[社区成员](community-membership.md)。与项目一样，委员会也有章程，并定期向社区和技术委员会报告。 +[Committee文件夹](committee/)内记录了openEuler社区当前的所有的委员会。 + ## 跨项目沟通和协调 -一方面，跨SIG/项目协调的成本是昂贵的，虽然社区的大部分工作不需要协调，但仍然避免不了有跨越边界的工作（依赖等）。在这种情况下，期望多个SIG/项目之间互相协调并达成共识比较困难，组建联合工作组就显得很有意义了。 +一方面，跨SIG协调的成本是昂贵的，虽然社区的大部分工作不需要协调，但仍然避免不了有跨越边界的工作（依赖等）。在这种情况下，期望多个SIG之间互相协调并达成共识比较困难，组建联合工作组就显得很有意义了。 -另一方面，一些SIG确实会对所有SIG/项目产生影响，比如发布、测试、打包等。即使都不需要这些的软件，有时也可能需要进行变更或影响到其他SIG/项目。在这种情况下，所有SIG/项目都应遵守社区范围内的沟通流程。 +另一方面，一些SIG确实会对所有SIG产生影响，比如发布、测试、打包等。即使都不需要这些的软件，有时也可能需要进行变更或影响到其他SIG。在这种情况下，所有SIG都应遵守社区范围内的沟通流程。 -例如：具有影响力的提案需要在社区范围内公告，以便于其他SIG/项目组的成员有机会提供反馈和指导。不过本领域的项目拥有本领域的决策权。如果跨项目争议时间较长，则可以上升到技术委员会。 +例如：具有影响力的提案需要在社区范围内公告，以便于其他SIG的成员有机会提供反馈和指导。不过本领域的项目拥有本领域的决策权。如果跨项目争议时间较长，则可以上升到技术委员会。 diff --git a/README-ch.md b/README-ch.md deleted file mode 100644 index 13d377dca..000000000 --- a/README-ch.md +++ /dev/null @@ -1,60 +0,0 @@ -# openEuler社区 - -欢迎来到openEuler社区！ - - - -## 社区愿景 - -openEuler的愿景是：**通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展**。 - - - -这里加入openEuler社区并为之贡献的起点。 - - - -## 沟通交流 - - -openEuler社区有多种沟通渠道，请参考[社区交流](/communication)。 - - - -## 社区治理 - - -openEuler有以下受官方支持的组织类型： - -+ **委员会**：被授予承担一些敏感的主题的一组人。虽然社区鼓励尽可能开放，但是由于这组人所承担的主题的敏感性，允许进行私人的交流。比如安全委员会、打包委员会等 - -+ **SIG**：专注于**一个领域**的持久和开放的团队，该团队通过定期的任务和活动实现特定的交付目标。SIG具有公开透明的程序，要遵循openEuler的行为准则。任何人都可以参与并作出贡献。SIG的交付件要进入社区发行范围，可以向技术委员会提交申请，请参考相关[申请指导](/technical-committee/governance/README.md)。 - -+ **项目**：为实现**特定交付目标或成果**，由项目团队协作完成的任务（集）。项目组和SIG（特定兴趣小组）的区别在于，项目组专注于某一特定的交付成果。SIG（特定兴趣小组）专注于一个技术领域的技术贡献和创新孵化。比如*容器SIG*把*k8s*项目引入本小组的兴趣范围。为简化管理规则，项目管理和SIG治理共用一套机制。 - - **说明**： - -- 项目可以属于一个SIG团队，成为SIG团队的子项目（共用SIG的治理机制），也可以单独治理 - - 项目有两个阶段：孵化阶段和成熟阶段。成熟项目的软件包可以进入社区发行光盘。孵化项目可以申请软件包进入社区发行的`/extra`（不在光盘内的额外的软件包）目录或`/experimental`（探索、实验性质的软件包）目录 - -+ **工作组**：为了解决跨SIG/项目边界的问题而临时成立的小组。工作组不拥有任何代码或长期交付件。可以通过相关的SIG进行报告。比如社区安全编码工作组等。 - - 有关这些组织的更多详细信息，可以参看[完整的管理文档](/technical-committee/governance.md)。SIG/项目可以由自己的贡献策略（在本SIG/项目组的repo中的”README“或”CONTRIBUTING“文件中描述）（例如sig-qa/CONTRIBUTING.md），以及自己的邮件列表、IRC频道等。 - -如果您需要了解SIG/项目结构和组织的更多信息，请参阅[SIG/项目治理](/technical-committee/governance/SIG&project-goveranace.md)信息。 - - - -## 贡献 - - -做出贡献的第一步是从[openEuler的SIG/项目列表中选择](SIG&project-list.md)。开始参加SIG/项目会议，加入IRC频道并订阅邮件列表。SIG/项目通常会由一系列`help-wanted`的ISSUE，这些ISSUE可以帮助新的贡献者参与进来。 - -该[贡献指南](/guide/README.md)提供了如何让你的想法和bug修复被看到和接受的方法，其中包括详细的说明： - -1.如何提出问题 - -2.如何找到可以工作的内容 - -3.如果打开一个PR - diff --git a/README.md b/README.md index b58fa5456..3460d56c9 100644 --- a/README.md +++ b/README.md @@ -1,29 +1,82 @@ -# openEuler Community - -Welcome to openEuler community! This repository will guide you to get started for joining and contributing to openEuler community. This would be a good starting point for any activities in openEuler community. - -### Communicating - -The [Communicating](en/communication.md) lists all the communication channels including chat(IRCs), mail(mail lists) and meeting(meeting channels), by which you can join openEuler community conveniently. - - - -### Learn to use - -Please refer to [Learning](en/use-guide.md) to learn how to use. - - -### Contributing - -Picking the [SIGs](en/Sigs.md) would be a good start for the first step to contribute. After that, join into the IRC channel, and subscribe the relevant mail list. Each SIG has a set of issues with "Help wanted" label that will help new contributors to start the first contribution. Additionally, fixing the docs issues would be another good start point for who is not familiar with coding. - -The [CONTRIBUTING.md] in each project provides the detailed instruction on how to contribute step by step. However, before you submit the PR, please ensure the [CLA](en/CLA.md) signed. Please follow the steps - -> - COPY the [CLA](en/CLA.md) -> - Add your information -> - Send it to contact@openeuler.org - - -### Members - - +# openEuler社区 + +[English](#en) + + + +欢迎来到openEuler社区！ + + + +## 社区愿景 + +openEuler的愿景是：**通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展**。 + + + +这里加入openEuler社区并为之贡献的起点。 + + + +## 沟通交流 + + +openEuler社区有多种沟通渠道，请参考[社区交流](communication/)。 + + + +## 社区治理 + + +openEuler有以下受官方支持的组织类型： + ++ **委员会**：被授予承担一些敏感的主题的一组人。虽然社区鼓励尽可能开放，但是由于这组人所承担的主题的敏感性，允许进行私人的交流。比如安全委员会、打包委员会等 + ++ **SIG**：专注于**一个领域**的持久和开放的团队，该团队通过定期的任务和活动实现特定的交付目标。SIG具有公开透明的程序，要遵循openEuler的行为准则。任何人都可以参与并作出贡献。所有的SIG都存在于`sig`文件夹下； + + **子项目**：子项目是SIG内为实现**特定交付目标或成果**而成立的，可以独立工作。子项目有一个或多个仓库，是openEuler社区内主要交付成果的输出组织，所有的子项目都在其所属的SIG内。项目的交付件要进入社区发行范围，可以向技术委员会提交申请，请参考相关[申请指导](technical-committee/governance/README.md)。 + + **子项目有两个阶段：孵化阶段和成熟阶段**。成熟项目的软件包可以进入社区发行光盘。孵化项目可以申请软件包进入社区发行的`/extra`（不在光盘内的额外的软件包）目录或`/experimental`（探索、实验性质的软件包）目录 + ++ **工作组**：为了解决跨SIG边界的问题而临时成立的小组。工作组不拥有任何代码或长期交付件。可以通过相关的SIG进行报告。比如社区安全编码工作组等。 + + 有关这些组织的更多详细信息，可以参看[完整的管理文档](governance.md)。SIG可以由自己的贡献策略（在本SIG/项目组的repo中的”README“或”CONTRIBUTING“文件中描述）（例如sig-qa/CONTRIBUTING.md），以及自己的邮件列表、IRC频道等。 + +如果您需要了解SIG/项目结构和组织的更多信息，请参阅[SIG治理](technical-committee/governance/SIG-goveranace.md)信息。 + + + +## 贡献 + + +做出贡献的第一步是从[openEuler的SIG/项目列表中选择](SIG-list.md)。开始参加SIG/项目会议，加入IRC频道并订阅邮件列表。SIG/项目通常会由一系列`help-wanted`的ISSUE，这些ISSUE可以帮助新的贡献者参与进来。 + +该[贡献指南](guide/README.md)提供了如何让你的想法和bug修复被看到和接受的方法，其中包括详细的说明： + +1、如何提出问题 + +2、如何找到可以工作的内容 + +3、如何提交一个PR + + + + +

openEuler Community

+Welcome to openEuler community! This repository will guide you to get started for joining and contributing to openEuler community. This would be a good starting point for any activities in openEuler community. + +### Communicating + +The [Communicating](https://gitee.com/openeuler/community/blob/master/en/communication.md) lists all the communication channels including chat(IRCs), mail(mail lists) and meeting(meeting channels), by which you can join openEuler community conveniently. + +### Learn to use + +Please refer to [Learning](https://gitee.com/openeuler/community/blob/master/en/use-guide.md) to learn how to use. + +### Contributing + +Picking the [SIGs](https://gitee.com/openeuler/community/blob/master/en/Sigs.md) would be a good start for the first step to contribute. After that, join into the IRC channel, and subscribe the relevant mail list. Each SIG has a set of issues with "Help wanted" label that will help new contributors to start the first contribution. Additionally, fixing the docs issues would be another good start point for who is not familiar with coding. + +The [CONTRIBUTING.md] in each project provides the detailed instruction on how to contribute step by step. However, before you submit the PR, please ensure the [CLA](https://gitee.com/openeuler/community/blob/master/en/CLA.md) signed. Please follow the steps + +> - COPY the [CLA](https://gitee.com/openeuler/community/blob/master/en/CLA.md) +> - Add your information +> - Send it to [contact@openeuler.org](mailto:contact@openeuler.org) \ No newline at end of file diff --git a/SIG&project-list.md b/SIG&project-list.md deleted file mode 100644 index fc122feb9..000000000 --- a/SIG&project-list.md +++ /dev/null @@ -1,25 +0,0 @@ -# SIG、项目和委员会清单 - -大多数社区活动都组织为SIG/项目。SIG/项目都遵循这些[准则](../Govern.md)。每个SIG/项目组的资料都在该SIG/项目的目录中。如果需要，可以[申请一个新SIG/项目](/technical-committee/governance/README.md) - -### 主要的SIG/项目清单 - -| SIG/项目名称 | 类型 | Maintainer清单 | 联系方式 | SIG/项目会议时间 | -| ------------ | ---- | -------------- | -------- | ---------------- | -| qa | SIG | | | | -| pm | SIG | | | | -| release | SIG | | | | -| | | | | | -| | | | | | - - - - - -### 主要的委员会清单 - -| 名称 | 标签 | 成员 | 联系方式 | -| ---------- | ---- | ---- | -------- | -| 安全委员会 | | | | -| | | | | - diff --git a/SIG-list.md b/SIG-list.md new file mode 100644 index 000000000..8bb64fc19 --- /dev/null +++ b/SIG-list.md @@ -0,0 +1,18 @@ +# SIG清单 + +大多数社区活动都组织为SIG。SIG都遵循这些[准则](Governance.md)。每个SIG的资料都在该SIG的目录中。如果需要，可以[申请一个新SIG/项目](technical-committee/governance/README.md) + + + +### 主要的SIG清单 + +- [sig-qa](sig/sig-qa/) +- [sig-pm](sig/sig-pm/) +- [sig-packaging](sig/sig-packaging/) +- [sig-iSula]() +- [sig-iTurn]() + + + + + diff --git a/community-membership.md b/community-membership.md index 0b03980f1..b92075353 100644 --- a/community-membership.md +++ b/community-membership.md @@ -1,54 +1,50 @@ # 社区成员 -本文简要描述了openEuler社区中贡献者角色的各种职责。大部分角色的职责限于这些SIG/项目内： +本文简要描述了openEuler社区中贡献者角色的各种职责。大部分角色的职责限于这些SIG内： -| 角色 | 职责范围（简要描述） | 要求 | 定义的文件 | -| ----------- | --------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------ | -| Contributor | 社区的积极贡献者 | | Gitee注册成员 | -| Committer | 审核其他成员的贡献 | SIG/项目的积极贡献者，经验丰富，愿意投入精力参与到审核工作 | openEuler SIG/项目拥有的存储库中OWNERS文件中的*Maintainer*条目。openEuler SIG/项目的openeuler.yaml中对应SIG/项目的*developer*条目 | -| Maintainer | SIG/项目或子SIG/项目的Owner | 经验丰富，富有责任心、出色的技术能力和沟通能力 | openEuler SIG/项目拥有的存储库中OWNERS文件中的*Maintainer*条目。openEuler SIG/项目的openeuler.yaml中对应SIG/项目的*developer*条目 | +| 角色 | 职责范围（简要描述） | 要求 | 定义的文件 | +| ----------- | -------------------- | ----------------------------------------------------- | ----------------------------------------------------------- | +| Contributor | 社区的积极贡献者 | | Gitee注册成员 | +| Committer | 审核其他成员的贡献 | SIG的积极贡献者，经验丰富，愿意投入精力参与到审核工作 | openEuler SIG拥有的存储库中OWNERS文件中的*Maintainer*条目。 | +| Maintainer | SIG或子项目Owner | 经验丰富，富有责任心、出色的技术能力和沟通能力 | openEuler SIG拥有的存储库中OWNERS文件中的*Maintainer*条目。 | +*说明*：Maintainer和Committer在Gitee的权限上不做区分，两者的区分主要是集中在SIG治理的管理范围上。详细可以见下面的描述。 -## 新的贡献者 -现有成员应该欢迎[新的贡献者](contributing.md)加入社区。我们有关于如何开始贡献的指导文档： +## 新的贡献者 -- [openEuler贡献者指南](/contributors/guide/README.md) +欢迎新成员加入社区。我们有关于如何开始贡献的指导文档请参考：[openEuler贡献者指南](/contributors/guide/README.md) ## 既有社区成员 -既有的社区成员应证明他们遵守本文中的原则，熟悉SIG/项目的组织、角色、政策、软件、约定等，以及相关的技术和/或写作能力。特性角色的期望、职责和要求，在下面列出。 - +既有的社区成员应证明能够遵守本文中的原则，熟悉SIG的组织、角色、政策、软件、约定等，以及相关的技术和/或写作能力。社区成员角色的期望、职责和要求，请参考下面的内容。 -### 贡献者 Contributor ------ +## 贡献者 Contributor +贡献者是社区中持续活跃的贡献者，他们可以认领问题和PR，可以参与SIG组活动，并且可以为PR提交前完成测试。 -贡献者是社区中持续活跃的贡献者，他们可以认领问题和PR，可以参与SIG/项目组活动，并且可以为PR提交前完成测试。 - -#### 要求 +### 要求 + Gitee上的注册会员 -+ 为SIG/项目或社区做出多方面贡献，包括不限于： ++ 为SIG或社区做出多方面贡献，包括不限于： + 在Gitee上提交或审核PR + 在Gitee上对问题进行归档或评论 - + 参与SIG/项目、子项目或社区讨论 - -+ 订阅dev@openeuler.org（社区开发公共邮件列表） -+ 已阅读[贡献者指南](/contributors/guide/README.md) -+ 积极参与1个或多个SIG/项目或子项目 + + 参与SIG或社区讨论 ++ 订阅[社区开发公共邮件列表](dev@openeuler.org) ++ 已阅读[贡献者指南](contributors/README.md) ++ 积极参与1个或多个SIG -#### 责任与权利 +### 责任与权利 + 响应被分配的问题和PR + 贡献的代码应该 @@ -61,15 +57,15 @@ + 可以针对PR自动运行测试。`/ok-to-test`不是必要的 + 可以使用`/ok-to-test`为具有`needs-ok-to-test`标签的PR进行操作，并使用诸如`/close`对PR进行关闭。 -**注意**：经常贡献代码的成员应积极的参与代码审查，并努力成为SIG/项目的*审核者*。 +**注意**：经常贡献代码的成员应积极的参与代码审查，并努力成为SIG的*审核者Committer*。 ## 审核者 Committer -审核者能够在SIG/项目或某SIG/项目的某些部分中审核代码的质量和正确性。审核者对代码库和软件工程原理非常了解。 +审核者能够在SIG或SIG的某些部分中审核代码的质量和正确性。审核者对代码库和软件工程原理非常了解。 -定义者：openEulerSIG/项目拥有的存储库中OWNERS文件中的*developer*条目。 +定义者：openEulerSIG拥有的存储库中OWNERS文件中的*developer*条目。 ### 要求 @@ -77,15 +73,15 @@ + 作为主要审阅者至少参与了6次PR的审阅 + 审阅或合并至少20个基本PR到代码库 + 熟悉代码库 -+ 可以自我提名，或由该SIG/项目的审核者或维护者或由机器人提名 ++ 可以自我提名，或由该SIG的审核者或维护者或由机器人提名 ### 责任与权力 + **评审PR**：对Contributor提交的PR完成评审，评审可以参考社区的[编程建议]()和[安全编程规范]()。 + **分发处理问题**，请参考“[问题处理流程]()“。 -+ **跟踪依赖性问题**：在开发分支中，其他SIG/项目组的软件包的更新可能会到导致破坏本SIG/项目内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。 -+ **如有接口变更，通知可能会影响到的SIG/项目**：其他SIG/项目或团队会依赖本SIG/项目，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG/项目。具体请参考[接口变更通知流程]()。 -+ **更新和维护软件包版本**：遵守社区的[软件包更新质量控制策略](/group-pm/)完成软件包的更新。 ++ **跟踪依赖性问题**：在开发分支中，其他SIG组的软件包的更新可能会到导致破坏本SIG内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。 ++ **如有接口变更，通知可能会影响到的SIG**：其他SIG或项目会依赖本SIG的软件包，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG。具体请参考[接口变更通知流程]()。 ++ **更新和维护软件包版本**：遵守社区的[软件包更新质量控制策略]()完成软件包的更新。 + **和上游社区合作**，包括： + 将所有变更推送到上游社区 + 参与上游社区邮件列表 @@ -103,7 +99,7 @@ 维护者是软件包的维护者，能够像Committer一样审查和批准代码贡献。代码审查的重点是代码质量和正确性，而批准的重点是对贡献的整体接受度。**所有Committer的责任与权力，Maintainer均具有**。除此之外，Maintainer还承担了团队的技术路线、内外协调等工作。 -**定义**：openEuler SIG/项目拥有的存储库中OWNERS文件中的*developer*条目 +**定义**：openEuler SIG拥有的存储库中OWNERS文件中的*developer*条目 @@ -117,9 +113,9 @@ ### 责任与权力 -- **确定SIG/项目的技术路线**：包括规划和决策SIG/项目技术方向、路标规划、架构演进。 -- **制定SIG/项目的发布计划**：确定SIG/项目的关键需求和发布计划；参与社区的PM活动，并协调SIG/项目计划和社区版本的里程碑时间表匹配 -- **参与社区协调活动**：作为SIG/项目的代表参与openEuler技术委员会或理事会组织的活动和特定会议等 -- **召集SIG/项目组会议**：定期召集SIG/项目组会议，决策SIG/项目组内上升的争议 +- **确定SIG的技术路线**：包括规划和决策SIG技术方向、路标规划、架构演进。 +- **制定SIG的发布计划**：确定SIG的关键需求和发布计划；参与社区的PM活动，并协调SIG计划和社区版本的里程碑时间表匹配 +- **参与社区协调活动**：作为SIG的代表参与openEuler技术委员会或理事会组织的活动和特定会议等 +- **召集SIG组会议**：定期召集SIG会议，决策SIG内上升的争议 diff --git a/security b/security new file mode 160000 index 000000000..15d3bed3c --- /dev/null +++ b/security @@ -0,0 +1 @@ +Subproject commit 15d3bed3c7a38af4195fe27ce8db68588b4474e1 diff --git a/zh/Gitee-Management/Gitee-management-guide.md b/zh/Gitee-Management/Gitee-management-guide.md index f177e289a..168c86e07 100644 --- a/zh/Gitee-Management/Gitee-management-guide.md +++ b/zh/Gitee-Management/Gitee-management-guide.md @@ -53,9 +53,29 @@ repository还有license、CLA等要求，请参见[openEuler项目模板]() -### 创建repository +### 创建一个Repository +``` yaml +repositories: + - name: abattis-cantarell-fonts + description: "fonts repo" + type: private +``` +如果你想要在openEuler社区里面新增一个仓库，你可以基于上面的示例提交一个pull request修改 +[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)或者[src-openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/src-openeuler.yaml)。 + +* `abattis-cantarell-fonts`: 你想创建的新仓库名字。 + +* `fonts repo`: 新仓库描述。 + +* `private`: 表示仓库的类型。 + + `private`意味着新仓库只对某些特定的人群可见。 + + `public`意味着新仓库对所有人可见。 + +一旦你的pull request被合入，```openeuler-ci-bot```将会立即创建一个新仓库。 diff --git a/zh/contributors/README.md b/zh/contributors/README.md index 54c04ccb2..0226d737c 100644 --- a/zh/contributors/README.md +++ b/zh/contributors/README.md @@ -13,12 +13,12 @@ + [社区期望](#id1-3) - [您的第一个贡献](#id2) - [找到您感兴趣的工作](#id2-1) - - [了解SIG/项目](#id2-1-1) - - [找到您感兴趣的SIG/项目和respository](#id2-1-2) + - [了解SIG](#id2-1-1) + - [找到您感兴趣的SIG和respository](#id2-1-2) - [开始您的贡献](#id2-2) - [给你自己分配一个issue](#id2-2-1) - [提出问题](#id2-2-2) - - [SIG/项目贡献者指南](#id2-2-3) + - [SIG贡献者指南](#id2-2-3) - [社区贡献指导](#id2-2-4) - [沟通](id2-3) - [Gitee工作流程](#id3) @@ -56,36 +56,31 @@ openEuler是一个开源社区。因此它完全依赖于社区提供开发，

您的第一个贡献

+随时欢迎您的加入！在社区上总是有可以改进的文档（比如您正在阅读的），可以澄清的代码，可以重构或注释的函数或变量，始终需要测试的代码。我们将帮助您了解openEuler SIG的组织方式，并引导您顺利的开始您的第一个贡献。您可以选择解决问题、编写代码，或者检视和合并等工作。所以如果您感兴趣，现在就行动吧~~ -随时欢迎您的加入！在社区上总是有可以改进的文档（比如您正在阅读的），可以澄清的代码，可以重构或注释的函数或变量，始终需要测试的代码。我们将帮助您了解openEuler SIG/项目的组织方式，并引导您顺利的开始您的第一个贡献。您可以选择解决问题、编写代码，或者检视和合并等工作。所以如果您感兴趣，现在就行动吧~~ - -如果您对开发过程有疑问，请随时加入我们的[邮件列表](dev@openeuler.org)，并在邮件标题内用“【开发过程疑问】”作为标题 写出你的疑问和困惑，openEuler团队会定期扫描邮件列表上的内容，并尽力确保您的问题得到解答。 +如果您对开发过程有疑问，请随时加入我们的[开发邮件列表](dev@openeuler.org)，并在邮件标题内用“【开发过程疑问】”作为标题 写出你的疑问和困惑，openEuler团队会定期扫描邮件列表上的内容，并尽力确保您的问题得到解答。

找到您感兴趣的工作

-

了解SIG/项目

- -#### SIG/项目和Repository +

了解SIG

-我们将社区按照不同的SIG/项目来组织，以便于更好的管理和改善工作流程。 +#### SIG和Repository -SIG/项目组是开放的，欢迎任何人加入并参与贡献。SIG/项目组内部会定期开会，每一个SIG/项目都有一个公共频道。每一个SIG/项目在Gitee上都会拥有一个repository，单击SIG/项目名称中的链接，可以获取每个SIG/项目的`README.md`。在`README.md`里可以查找到SIG/项目包含的子项目。每一个SIG/项目在Gitee上也会拥有至少一个repository。 +我们将社区按照不同的SIG来组织，以便于更好的管理和改善工作流程。 +SIG组是开放的，欢迎任何人加入并参与贡献。SIG组内部会定期开会，每一个SIG都有一个公共频道。每一个SIG在Gitee上都会拥有一个或多个repository，单击SIG名称中的链接，可以获取每个SIG的`README.md`。在`README.md`里可以查找到SIG包含的子项目和子项目的额repository。 +

找到您感兴趣的SIG和repository

-

找到您感兴趣的SIG/项目组和repository

+找到适合您贡献的SIG组，可以帮助您在正确的地方提出问题，为您的贡献提供更高的知名度和更快的社区响应速度。您可以查看[SIG列表](/../SIG-list.md)，以便您最快速的定位到自己感兴趣的领域。 -找到适合您贡献的SIG/项目组，可以帮助您在正确的地方提出问题，为您的贡献提供更高的知名度和更快的社区响应速度。您可以查看[SIG/项目列表](./../../SIG&project-list.md)，以便您最快速的定位到自己感兴趣的领域。 - -在openEuler的Repository列表下搜索SIG/项目名称，也可以找到对应子SIG/项目的repository。如果搜索不到，您可以尝试在dev@openeuler.org中寻求帮助。同样，请在邮件列表内用“【开发过程疑问】”作为标题 写出你寻找的SIG或项目。 +在openEuler的Repository列表下搜索SIG名称，也可以找到对应子SIG的repository。如果搜索不到，您可以尝试在dev@openeuler.org中寻求帮助。同样，请在邮件列表内用“【开发过程疑问】”作为标题 写出你寻找的SIG或项目。

开始您的贡献

-找到您感兴趣的SIG/项目的repository后，您会发现在repository内有可以拉取的代码，也有适合初学者的issue，还有交付成果的产品文档。您可以在repository中找到文档方面的改进需求，通过改进文档的过程，您也可以熟悉社区的代码提交/构建检查/合并等过程。详细可以参阅本文以了解工作流程。 - 如果您的兴趣不在编写代码方面，可以在[《非代码贡献指南》](non-code-contributions.md)中找到感兴趣的工作。 @@ -101,10 +96,8 @@ SIG/项目组是开放的，欢迎任何人加入并参与贡献。SIG/项目组 尽管社区鼓励每个人贡献代码，但是当您报告问题或缺陷的时候，也是值得赞赏的。问题应提交到对应的repository下面。您可以查看[问题提交指南](issue-submit.md)以获取更多的信息。提交问题时，请确保遵守问题提交准则。 - -

SIG/项目贡献指南

- -每个SIG/项目或子项目的编码语言、开发环境、编码约定等都可能是由差异的。所以每一个SIG/项目或其子项目都可能有自己的贡献者指南——一般是`CONTRIBUTING.md`文件。除了这些文件外，SIG/项目可能还会提供其他指南信息。这些信息位于SIG/项目或子项目的特定社区目录中。 +

SIG贡献指南

+每个SIG或子项目的编码语言、开发环境、编码约定等都可能是由差异的。所以每一个SIG或其子项目都可能有自己的贡献者指南——一般是`CONTRIBUTING.md`文件。除了这些文件外，SIG可能还会提供其他指南信息。这些信息位于SIG或子项目的特定社区目录中。 @@ -133,8 +126,8 @@ openEuler遵循标准的[Gitee PR请求流程](https://gitee.com/help/articles/4 对于新贡献者来说，常遇到的问题是： -+ 在您的第一个PR之前没有正确的签署CLA,请参阅[签署CLA](./../CLA.md) -+ 为PR在SIG/项目组内找到合适的检视者，并保证自己的贡献遵循SIG/项目组内特定的贡献准则（请参阅[了解SIG/项目]()） ++ 在您的第一个PR之前没有正确的签署CLA（请参阅[签署CLA](/../CLA.md)） ++ 为PR在SIG组内找到合适的检视者，并保证自己的贡献遵循SIG组内特定的贡献准则（请参阅[了解SIG](/../SIG-list.md)，从其中查找感兴趣的SIG提供的贡献者指导） + 处理在PR上失败的测试用例，这些测试用例可能与您引入的更改无关（请参阅） + 不遵守一些[良好的编码实践]() + 在提交的信息中包含了可能关闭issue的关键字，比如XXXXXXXX等 @@ -145,10 +138,10 @@ openEuler遵循标准的[Gitee PR请求流程](https://gitee.com/help/articles/4 对于贡献者，关于代码检视的重要性的简要说明，请参阅[代码检视](expectations.md)。为了使您的提交更容易被接受，您需要： -+ 遵循SIG/项目组的[编码约定](coding-conventions.md) ++ 遵循SIG组的[编码约定]() + 准备完善的提交信息 + 如果一次提交的代码量较大，建议将大型的内容分解成一系列逻辑上较小的内容，分别进行提交会更便于检视者理解您的想法 -+ 使用适当的SIG/项目组和监视者标签去标记PR：机器人会发送给您消息，以方便您更好的完成整个PR的过程 ++ 使用适当的SIG组和监视者标签去标记PR：机器人会发送给您消息，以方便您更好的完成整个PR的过程 @@ -176,7 +169,7 @@ todo：待qa团队补充具体的测试活动内容 持续集成会将这些测试活动在PR提交前完成，结果会出现在XXXX上 -[sig-qa组]()是负责测试活动的官方机构，他们的相关测试自动化工具在test-fra中。如果您你希望自己的基础架构上能运行XXX测试，可以考虑采用。 +[sig-qa组](/../sig/sig-qa/)是负责测试活动的官方机构，他们的相关测试自动化工具在test-fra中。如果您你希望自己的基础架构上能运行XXX测试，可以考虑采用。 @@ -212,7 +205,6 @@ todo：待qa团队补充具体的测试活动内容 [社区常规交流方式](./communication) -

大事记

openEuler参加了XXXXXX，每年在XXXXXXX，关于这些事件和其他社区事件信息可以在[openEuler事件]()页面上找到 @@ -221,4 +213,4 @@ openEuler参加了XXXXXX，每年在XXXXXXX，关于这些事件和其他社区

聚会

-我们遵循针对开发者的聚会的XXXXX准则，您可以通过XXXXX上的直接消息或通过电子邮件与XXXX联系。来加入我们把~ \ No newline at end of file +我们遵循针对开发者的聚会的XXXXX准则，您可以通过XXXXX上的直接消息或通过电子邮件与XXXX联系。来加入我们把~ diff --git a/zh/contributors/coding-conventions.md b/zh/contributors/coding-conventions.md deleted file mode 100644 index 23b32f0a3..000000000 --- a/zh/contributors/coding-conventions.md +++ /dev/null @@ -1,2 +0,0 @@ -# 编码约定（C/C） - diff --git a/zh/contributors/expectations.md b/zh/contributors/expectations.md deleted file mode 100644 index 90bddc649..000000000 --- a/zh/contributors/expectations.md +++ /dev/null @@ -1,14 +0,0 @@ -## 代码检视指南 - -首先感谢所有为openEuler成为一个成功的操作系统，以及一个成功的社区付出时间和精力的人们。 - -openEuler的愿景是：**通过社区合作，打造创新平台，构建支持多处理器架构、统一和开放的操作系统openEuler，推动软硬件生态繁荣发展**。 - - - -本文描述了我们对openEuler社区成员的期望。它涵盖了对所有成员的行为期望以及所有积极贡献者的代码检视期望。 - - - -代码检视 - diff --git a/zh/contributors/installation.md b/zh/contributors/installation.md deleted file mode 100644 index ca47e44b7..000000000 --- a/zh/contributors/installation.md +++ /dev/null @@ -1,3 +0,0 @@ -# 安装指南 - -[todo]待提供 \ No newline at end of file diff --git a/zh/contributors/non-code-contributions.md b/zh/contributors/non-code-contributions.md index 0966ff878..1afabef12 100644 --- a/zh/contributors/non-code-contributions.md +++ b/zh/contributors/non-code-contributions.md @@ -5,7 +5,7 @@ ## 外向型社区工作 -- 参与[社区交流](/../communication)，包括帮助引导社区新人贡献社区，回答社区上的疑问等， +- 参与[社区交流](/../communication/)，包括帮助引导社区新人贡献社区，回答社区上的疑问等， - 运维社区通信工具，包括联系主持社区会议等 - 共同组织社区聚会，包括openEuler开发者大会等， - 管理社区“大事件”等，包括查看管理讨论中的事件 @@ -22,9 +22,9 @@ -## 项目组内的特定角色 +## SIG内的特定角色 -以下的角色对于openEuler中的每一个项目或SIG都很重要。如果您对项目中的特定主体感兴趣，可以通过多种不同的方式为特定的项目组做出贡献。 +以下的角色对于openEuler中的每一个SIG都很重要。如果您对项目中的特定主体感兴趣，可以通过多种不同的方式为特定的项目组做出贡献。 - 文献资料 - 项目/SIG专业知识领域的通用文档 @@ -36,7 +36,7 @@ - 项目管理 - 确认任务、问题等的所有权 - 管理PR，管理项目组分类和标签，编辑PR相关文本 - - 为项目/SIG等组织和帮助召开会议 + - 为SIG等组织和帮助召开会议 diff --git a/zh/technical-committee/governance/README.md b/zh/technical-committee/governance/README.md index 158bff6d7..4f27f4ccf 100644 --- a/zh/technical-committee/governance/README.md +++ b/zh/technical-committee/governance/README.md @@ -1,71 +1,91 @@ -# SIG/项目 Charter指南 +# SIG 管理指南 - 所有openEuler社区的SIG/项目都必须有一个章程（Charter）来明确SIG/项目的范围和治理规则。 + 所有openEuler社区的SIG都必须有一个章程（Charter）来明确SIG的范围和治理规则。 -+ 范围必须明确定义SIG/项目负责指导和维护的领域 -+ 治理规则必须说明SIG/项目中的职责，以及拥有这些职责的角色和工作开展方式 ++ 范围必须明确定义SIG负责指导和维护的领域 ++ 治理规则必须说明SIG中的职责，以及拥有这些职责的角色和工作开展方式 -## 申请新SIG/项目章程的步骤 +## 申请新SIG的流程 -1.将[模板](template-SIG&project-governance.md)复制到community/proj*YOURPROJECT*/charter.md下的新文件中（[范例]()） +**1、在community下创建新SIG的文件夹并拷贝进模板文件** -2.为便于更好的理解模板里的内容，建议先阅读[建议书和要求](SIG&project-governance-requirement.md) +请将[模板文件夹](template-charter/)中的两个文件（分别是charter.md、OWNERS）复制到community/sig/sig-YOURSIG*/下面。 -3.填写您的SIG/项目申请模板 +**2、完成新SIG章程的填写** -4.请根据您申请模板中定义的SIG/项目，SIG/项目中的角色、以及SIG/项目的Repository信息更新[openeuler.yaml](https://gitee.com/openeuler/infrastructure/blob/master/repository/openeuler.yaml)。SIG/项目的Repository请参考[openEuler的Repository说明](/../../Gitee-management/Gitee-management-guide.md) +为便于更好的理解章程模板里的内容，建议先阅读[建议书和要求](SIG-governance-requirement.md)，完成新项目的charter.md -5.在openeuler.yaml中添加您的SIG/项目，以及这个SIG/项目拥有的子项目 +**3、完成新项目成员的配置** -6.用修改好的charter.md和openeuler.yaml ，创建一个Pull Request，并在您的团队内对申请书内的SIG/项目范围和治理章程达成一致的意见 +请在OWNERS文件中完成对SIG成员的配置 -7.请将SIG/项目章程（charter.md）发送给技术委员会审查（网址为tc@openEuler.org），并在正文中包含主题“*新SIG/项目提案*”和PR的链接 +**4、完成新SIG的Repository的配置** + +请参考[openEuler的Repository说明](/../../Gitee-management/Gitee-management-guide.md)，完成SIG和项目所拥有的Repository的配置。 + +- 如果您的项目在openEuler社区只维护软件包，请点击[src-openeuler.yaml](/repository/src-openeuler.yaml)，在其中按照格式把你的项目添加进来。 +- 如果不是以上的情况，请单击[openeuler.yaml](/repository/openeuler.yaml)，并按照内部的格式在文件的最后把您的SIG添加进来 + +**5、在sig文件夹的sig.yaml内添加新SIG的相关信息** + +根据以上的信息，打开sig文件夹下[sig.yaml](sig/sigs.yaml)文件，在末尾添加新sig的相关信息。 + +**6、提交PR** + +将修改好的文件夹内的charter.md，以及openeuler.yaml（或src-openeuler.yaml）和repository.yaml提交 ，创建一个Pull Request，并在您的团队内对申请书内的SIG范围和治理章程等达成一致意见 + +**7、向TC发送邮件申请** + +请将SIG章程（charter.md）通过Issue发送给技术委员会审查（网址为tc@openEuler.org），并在正文中包含主题“【*新SIG提案】*”和PR的链接 + +**8、TC评审并反馈意见** 8.技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改 -9.技术委员会将通过合并Pull Request的方式来批准您的申请 +**9.TC评审通过并合入** + +技术委员会将通过合并Pull Request的方式来批准您的申请 -## 更新现有SIG/项目章程的步骤 -+ 对于重大变更或可能影响其他SIG/项目组的任何变更（例如范围变更），请填写PR申请，并将该申请发送给技术委员会，发送主题请标注成“*SIG/项目章程更新：*YOUR SIG/RPROJECT” -+ 对于影响范围小的变更，比如只影响本SIG/项目范围内的问题或领域，SIG/项目的Mainatiner可以自行协助进行变更 +## SIG变更批准流程 +如果您要修改SIG章程（charter.md）、团队成员(OWNERS)、增删Repository(Repository)。 -## SIG/项目章程批准流程 +**1、对于影响范围小的变更**，比如只影响本SIG范围内的问题或领域（比如变更团队成员），PR申请填写完成以后，SIG的Mainatiner可以自行审批协助完成变更 -引入新SIG/项目或对老SIG/项目的章程进行修改时，过程如下： +**2、对于以上的重大变更或可能影响其他SIG组的任何变更**（例如项目范围变更、增删Repository） -+ 从SIG/项目组中确定推动变更的负责人，最常见的就是SIG/项目的Mainatiner作为负责人 -+ 变更所有者组织SIG/项目组成员一起制定变更内容，并与技术委员会讨论（为便于信息同步，可以在与指导委员会的沟通中键入SIG/项目组的邮件列表）。 -+ 获取到技术委员会的批准意见后，提交PR并将邮件发送到tc@openeuler.org。对更改细节的讨论交流建议在申请PR之前在社区上进行。 -+ 对于较大的变更，确认变更范围后请通知openEuler社区内受到影响的其他SIG/项目组，并将邮件发送到tc@openeuler.org，或者在社区门户上宣布。 ++ 从SIG组中确定推动变更的负责人，最常见的就是SIG的Mainatiner作为负责人 ++ 变更所有者组织SIG组成员一起制定变更内容，并与技术委员会讨论（为便于信息同步，可以在与指导委员会的沟通中键入SIG组的邮件列表） ++ 获取到技术委员会的批准意见后，提交PR，并将该申请发送给[技术委员会](tc@openeuler.org)，发送主题请标注成“【*SIG章程更新：*YOUR SIG/RPROJECT】” ++ 对于较大的变更，确认变更范围后请通知openEuler社区内受到影响的其他SIG组，并将邮件发送到tc@openeuler.org，或者在社区门户上宣布。 -如果这一过程中有任何疑问，请联系技术委员会：tc@openEuler.org +如果这一过程中有任何疑问，请联系技术委员会：tc@openeuler.org -## SIG/项目申请社区发行提案步骤 +## SIG申请社区发行提案步骤 -如果SIG/项目希望自己的交付件可以进入**社区发行范围**，请向技术委员会提出申请 +如果SIG希望自己的交付件可以进入**社区发行范围**，请向技术委员会提出申请 -1.将[模板](template-release.md)复制到community/*YOUR SIG/PROJECT*/release.md +1.将[模板](template-release.md)复制到community/*YOURSIG*/release.md -2.按照模板要求填写SIG/项目毕业申请 +2.按照模板要求填写SIG毕业申请 3.用修改好的release.md和openeuler.yaml ，创建一个Pull Request -4.请将社区发行申请（release.md）发送给技术委员会审查（网址为tc@openeuler.org），并在正文中包含主题“SIG/项目社区发行提案”和PR的链接 +4.请将社区发行申请（release.md）发送给技术委员会审查（网址为tc@openeuler.org），并在正文中包含主题“SIG社区发行提案”和PR的链接 5.技术委员会通常会在发送申请后的一周内反馈。如果遇到假期或重要会议等因素，可能会需要更长时间。在此期间，您可以进行任何有需要的更改 -6.技术委员会将通过合并Pull Request的方式来批准您的SIG/项目的社区发行申请 +6.技术委员会将通过合并Pull Request的方式来批准您的SIG的社区发行申请 **请注意，申请社区发行有三种类型**： diff --git a/zh/technical-committee/governance/SIG&project-governance-requirements.md b/zh/technical-committee/governance/SIG-governance-requirements.md similarity index 63% rename from zh/technical-committee/governance/SIG&project-governance-requirements.md rename to zh/technical-committee/governance/SIG-governance-requirements.md index 866fa53f8..eea04692e 100644 --- a/zh/technical-committee/governance/SIG&project-governance-requirements.md +++ b/zh/technical-committee/governance/SIG-governance-requirements.md @@ -1,24 +1,24 @@ -# SIG/项目治理要求 +# SIG治理要求 ## 目标 -本文简要描述了对SIG/项目的治理要求和建议。本文档使用[rfc2119](https://www.ietf.org/rfc/rfc2119.txt)表示关键字要求级别。 +本文简要描述了对SIG的治理要求和建议。本文档使用[rfc2119](https://www.ietf.org/rfc/rfc2119.txt)表示关键字要求级别。 ## 检查清单 -以下是在定义openEuler SIG/项目治理规则时需要考虑的清单 +以下是在定义openEuler SIG治理规则时需要考虑的清单 ### 角色 -+ *必须*枚举SIG/项目中的任何角色以及每一个角色的职责 ++ *必须*枚举SIG中的任何角色以及每一个角色的职责 + *必须*定义更改角色的过程 + 何时以及如何向每一个角色添加新成员 + 现有成员何时以及如何从各个角色退休 @@ -29,18 +29,18 @@ ### 组织管理 -+ *必须*定义何时以及如何组织SIG/项目组成员之间的协作 ++ *必须*定义何时以及如何组织SIG组成员之间的协作 + *应该*定义定期会议的安排和运作方式 + *应该*定义如何安排会议 + *可以*定义大家都比较闲暇的定期办公时间 -+ *可以*定义新的社区成员为该SIG/项目做出贡献的过程，例如阅读贡献指南，参加SIG/项目组会议等 ++ *可以*定义新的社区成员为该SIG做出贡献的过程，例如阅读贡献指南，参加SIG组会议等 + *必须*定义子项目的管理方式 + 何时以及如何创建新的子项目 + *必须*在子项目中定义角色（和成员资格） -### SIG/项目管理 +### SIG管理 + *必须*定义里程碑/版本的设置方式，包括 + 如何建议和接受里程碑/发布的目标日期 @@ -54,19 +54,19 @@ ### 技术流程 -社区上没有代码的SIG/项目可以简化甚至忽略 +社区上没有代码的SIG可以简化甚至忽略 -+ *必须*定义如何在SIG/项目组内传递和制定技术决策 ++ *必须*定义如何在SIG组内传递和制定技术决策 + 提案流程，在何处已经核实发布和讨论，何时以及如何做成决定 + 谁是提案的决策者 - + 如何解决SIG/项目内的分歧（例如：讨论后投票） + + 如何解决SIG内的分歧（例如：讨论后投票） + 分歧如何以及及时上升 + *应该*为提案流程定义期望和建议（例如：如果在两周内无法解决问题，则逐级上升） + *应该*为通过正式流程的决策定义后期跟踪处理方式（例如：何时重新审视或撤销决策） -+ *必须*定义SIG/项目的技术资产的健康标准和发布标准 ++ *必须*定义SIG的技术资产的健康标准和发布标准 + 发布用于确定代码是否健康且可以发布的明确公开的标准 + *仅*在标准满足时，才能发布 - + 确保技术资产处于可发布状态，以实现跨多个SIG/项目的里程碑/发布（如openEuler的LTS版本） + + 确保技术资产处于可发布状态，以实现跨多个SIG的里程碑/发布（如openEuler的LTS版本） + *应该*为健康的标准定义明确的目标和指标（例如：在N提案修复破坏构建的bug） + *应该*定义满足目标和指标的过程（例如：所有测试启动前的预验证等） \ No newline at end of file diff --git a/zh/technical-committee/governance/SIG&project-governance.md b/zh/technical-committee/governance/SIG-governance.md similarity index 44% rename from zh/technical-committee/governance/SIG&project-governance.md rename to zh/technical-committee/governance/SIG-governance.md index 57bc28f08..30beb4f73 100644 --- a/zh/technical-committee/governance/SIG&project-governance.md +++ b/zh/technical-committee/governance/SIG-governance.md @@ -1,15 +1,15 @@ -# SIG/项目角色和组织治理 +# SIG角色和组织治理 -​ 该Charter内容遵循openEuler宪章 [README](README.md)中描述的约定，本文会根据需要进行更新，以满足openEuler SIG/项目的需求。 +​ 该Charter内容遵循openEuler宪章 [README](README.md)中描述的约定，本文会根据需要进行更新，以满足openEuler SIG的需求。 -​ 为了使SIG/项目的工作标准化，提高社区透明度，并将贡献者合理的到入到对应的SIG/项目组内，SIG/项目应该遵循以下准则： +​ 为了使SIG的工作标准化，提高社区透明度，并将贡献者合理的到入到对应的SIG组内，SIG应该遵循以下准则： - 创建章程并根据[README](README.md)进行申请 - 定期开会，建议每周至少30分钟 - 持续保存最新的会议备忘录，并保存在对应的文件夹 -- 每季度至少在社区每周一次的会议中报告一次SIG/项目的活动，集成类SIG/项目可以调整成一年。 +- 每季度至少在社区每周一次的会议中报告一次SIG的活动，集成类SIG可以调整成一年。 - 根据需要参与发行计划会议、回顾会议和燃尽会议等 -- 确保在SIG/项目拥有的Gitee组织和存储库内开展相关工作，以支撑社区内的编码和测试，包括问题分类、PR审核、问题响应、错误修复等。 +- 确保在SIG拥有的Gitee组织和存储库内开展相关工作，以支撑社区内的编码和测试，包括问题分类、PR审核、问题响应、错误修复等。 - 采用[社区提供的邮件列表、IRC等主要方式](/../../communication)用于社区工作、沟通和合作,而不是私人邮件和会议。 @@ -21,14 +21,14 @@ 本节中的“成员”是指 -- 初始成员是在SIG/项目或子项目成立时定义的，是接受该SIG/项目或其子项目的一部分 +- 初始成员是在SIG或子项目成立时定义的，是接受该SIG或其子项目的一部分 - 成员*应*保持活跃并积极响应自己的角色职责 -- 成员*必须*是社区成员，才有资格在SIG/项目组中担任领导角色 +- 成员*必须*是社区成员，才有资格在SIG组中担任领导角色 - 休假超过1个月或更长时间的*成员*应该协调其他成员，以确保在休假期间为该角色配备足够的人员 - 休假1-3个月的会议*可以*与其他会员合作，以确定临时的替补成员 -- 成员*应*删除未告知休假但超过一个月无法联系或超过一个月未履行其职责的任何其他成员。删除过程可以通过[超级多数](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote)投票来完成；如果没有足够的*活跃*成员来获得超级多数的投票，则可以通过Maintainer，Committer和子SIG/项目所有者之间的超级多数来投票罢免。 -- 如果对于成员有资格分歧，可以上升到Maintainer。如果对于SIG/项目的Maintainer的资格的分歧可以上升到技术委员会。 -- 成员*可以*决定随时退出并提议候选人，候选人应得到大多数SIG/项目组成员的支持。 +- 成员*应*删除未告知休假但超过一个月无法联系或超过一个月未履行其职责的任何其他成员。删除过程可以通过[超级多数](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote)投票来完成；如果没有足够的*活跃*成员来获得超级多数的投票，则可以通过Maintainer，Committer和SIG所有者之间的超级多数来投票罢免。 +- 如果对于成员有资格分歧，可以上升到Maintainer。如果对于SIG的Maintainer的资格的分歧可以上升到技术委员会。 +- 成员*可以*决定随时退出并提议候选人，候选人应得到大多数SIG组成员的支持。 - 成员*可以*通过成员之间的[多数](https://en.wikipedia.org/wiki/Supermajority#Two-thirds_vote)投票选择其他成员。 @@ -36,12 +36,12 @@ ### Maintainer： > 人数：1~3人 -> 工作职责：SIG/项目组的管理者，软件包的维护者。直接参与和技术委员会以及上游或周边的协调，但无汇报关系。初始由SIG/项目创建时指定，后继人选从Committer中选出。如SIG/项目组内暂无Committer或人数较少，Committer的职责可以由Maintainer兼任。 +> 工作职责：SIG组的管理者，软件包的维护者。直接参与和技术委员会以及上游或周边的协调，但无汇报关系。初始由SIG创建时指定，后继人选从Committer中选出。如SIG组内暂无Committer或人数较少，Committer的职责可以由Maintainer兼任。 > -> - **确定SIG/项目的技术路线**：包括规划和决策SIG/项目技术方向、路标规划、架构演进。 -> - **制定SIG/项目的发布计划**：确定SIG/项目的关键需求和发布计划；参与社区的PM活动，并协调SIG/项目计划和社区版本的里程碑时间表匹配 -> - **参与社区协调活动**：作为SIG/项目的代表参与openEuler技术委员会或理事会组织的活动和特定会议等 -> - **召集SIG/项目组会议**：定期召集SIG/项目组会议，决策SIG/项目组内上升的争议 +> - **确定SIG的技术路线**：包括规划和决策SIG技术方向、路标规划、架构演进。 +> - **制定SIG的项目发布计划**：确定SIG的关键需求和发布计划；参与社区的PM活动，并协调SIG计划和社区版本的里程碑时间表匹配 +> - **参与社区协调活动**：作为SIG的代表参与openEuler技术委员会或理事会组织的活动和特定会议等 +> - **召集SIG组会议**：定期召集SIG组会议，决策SIG组内上升的争议 > > 角色配置：openeuler.yaml内的*developer*标签 @@ -55,8 +55,8 @@ > >+ **评审PR**：对Contributor提交的PR完成评审，评审可以参考社区的[编程建议]()和[安全编程规范]()。 >+ **分发处理问题**，请参考“[问题处理流程]()“。 ->+ **跟踪依赖性问题**：在开发分支中，其他SIG/项目组的软件包的更新可能会到导致破坏本SIG/项目内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。 ->+ **如有接口变更，通知可能会影响到的SIG/项目**：其他SIG/项目或团队会依赖本SIG/项目，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG/项目。具体请参考[接口变更通知流程]()。 +>+ **跟踪依赖性问题**：在开发分支中，其他SIG组的软件包的更新可能会到导致破坏本SIG内软件包的依赖关系。此时Committer会受到告警公告，Committer应尽力重建软件包。依赖关系出错可能会使最终用户无法更新系统，打包团队也会介入并重建存在依赖性问题的软件包，但Maintainer 不应依赖这些重建。 +>+ **如有接口变更，通知可能会影响到的SIG**：其他SIG或团队会依赖本SIG，对软件包接口的变更可能会对他们造成影响。Maintainer应了解并评审&决策变更造成的依赖影响，并公告和发送API或ABI变更的告警邮件。这类公告应在变更发生至少一周前完成，并应通知到所有可能受影响的SIG。具体请参考[接口变更通知流程]()。 > + **更新和维护软件包版本**：遵守社区的[软件包更新质量控制策略](/group-pm/)完成软件包的更新。 > + **和上游社区合作**，包括： > + 将所有变更推送到上游社区 @@ -79,9 +79,9 @@ >人数：1人 >工作职责： > ->+ 成为产品安全团队的对口SIG/项目组联络人，对本SIG/项目内的安全问题进行分类和处理。 +>+ 成为产品安全团队的对口SIG组联络人，对本SIG内的安全问题进行分类和处理。 >+ 参与安全团队的安全问题 ->+ 维护SIG/项目组内的安全规范和要求 +>+ 维护SIG组内的安全规范和要求 @@ -90,49 +90,49 @@ ### 会议管理 -- SIG/项目组应每一周召集一次会议，会议由Maintainer主持（除非委托给特定成员），固定议程可以由SIG/项目组内成员讨论确定 -- 深入讨论技术委员会指定给本SIG/项目组的——建议的技术和需求等，应由Maintainer组织（除非委托给特定成员） +- SIG组应至少每个月召集一次会议，会议由Maintainer主持（除非委托给特定成员），固定议程可以由SIG组内成员讨论确定 +- 深入讨论技术委员会指定给本SIG组的——建议的技术和需求等，应由Maintainer组织（除非委托给特定成员） - 定期更新社区会议 -### SIG/项目组管理 +### SIG组管理 -+ 确定本SIG/项目组内的年度技术路线图和路标，并向社区PM发布 -+ 提供SIG/项目组内版本的功能或需求清单 -+ 根据要求参加社区内的版本会议，提供和执行SIG/项目计划 ++ 确定本SIG组内的年度技术路线图和路标，并向社区PM发布 ++ 提供SIG组内版本的功能或需求清单 ++ 根据要求参加社区内的版本会议，提供和执行SIG计划 ### 子项目管理 -子项目可以由SIG/项目的Maintainer或Committer提案创建，子项目可以通过SIG/项目组内的Maintainer和Committer通过“懒惰的共识”（沉默即同意）评审接受，结果*应*得到大多数SIG/项目组成员的支持。 +子项目可以由SIG的Maintainer或Committer提案创建，子项目可以通过SIG组内的Maintainer和Committer通过“懒惰的共识”（沉默即同意）评审接受，结果*应*得到大多数SIG组成员的支持。 + 提案创建者*必须*是子项目所有者 -+ openeuler.yaml*必须*更新为包含子SIG/项目所有者的子项目信息和相关*OWNER*文件 -+ 所有子项目的治理和流程原则上与SIG/项目相同，如有不同，*必须*在提案时说明。 -+ 如子项目发布的执行方式和里程碑的设置与SIG/项目有差异，*必须*明确说明 -+ 子项目的组织管理可以和SIG/项目合并，也可以单独运作。 ++ openeuler.yaml*必须*更新为包含子SIG所有者的子项目信息和相关*OWNER*文件 ++ 所有子项目的治理和流程原则上与SIG相同，如有不同，*必须*在提案时说明。 ++ 如子项目发布的执行方式和里程碑的设置与SIG有差异，*必须*明确说明 ++ 子项目的组织管理可以和SIG合并，也可以单独运作。 ### 技术流程 - 提出方案和决策请遵循决策流程 -- 保证SIG/项目组持续健康的测试 - - 规范代码发布要求，如果可能可以合入到SIG/项目组的构建中检查 +- 保证SIG组持续健康的测试 + - 规范代码发布要求，如果可能可以合入到SIG组的构建中检查 - 通过构建保证引入的问题会通过测试自动检测并发送告警 - - SIG/项目组成员负责响应测试告警。如未能在24小时内修复，应该将破坏测试的PR回退 - - 每次的SIG/项目组会议应检查测试结果，成员应处理发现的错误，并在下次会议上反馈进展、 + - SIG组成员负责响应测试告警。如未能在24小时内修复，应该将破坏测试的PR回退 + - 每次的SIG组会议应检查测试结果，成员应处理发现的错误，并在下次会议上反馈进展、 - 影响多个子项目的问题建议通过以下任意一种方式解决： - - 方式一：SIG/项目的Maintainer指定SIG/项目的技术Leader仲裁或决策 + - 方式一：SIG的Maintainer指定SIG的技术Leader仲裁或决策 - 方式二：组织子项目的Maintainer联合会议 -### SIG/项目退出 +### SIG退出 -- 如果SIG/项目无法定期组织一定的人数或无法履行组织管理职责 +- 如果SIG无法定期组织一定的人数或无法履行组织管理职责 - 6个月以上的，*应*启动退出 - 12个月或更长时间的，*必须*退出 diff --git a/zh/technical-committee/governance/template-charter/OWNERS.yaml b/zh/technical-committee/governance/template-charter/OWNERS.yaml new file mode 100644 index 000000000..e69de29bb diff --git a/zh/technical-committee/governance/template-SIG&project-charter.md b/zh/technical-committee/governance/template-charter/template-charter.md similarity index 33% rename from zh/technical-committee/governance/template-SIG&project-charter.md rename to zh/technical-committee/governance/template-charter/template-charter.md index 1e73da059..4ec9e7111 100644 --- a/zh/technical-committee/governance/template-SIG&project-charter.md +++ b/zh/technical-committee/governance/template-charter/template-charter.md @@ -1,7 +1,7 @@ -# SIG/项目 Charter申请 +# SIG Charter申请 -说明：本SIG/项目的Charter内容遵循openEuler章程 [README]()中描述的约定，使用[SIG&project-governance](SIG&project-gover)中概述的角色和组织管理。 +说明：本SIG的Charter内容遵循openEuler章程 [README]()中描述的约定，使用[SIG-governance](SIG-governance.md)中概述的角色和组织管理。 @@ -11,34 +11,34 @@ 用几句话简要描述新申请SIG或项目的范围。包括： - - 为什么需要在openEuler里创建一个这样的新SIG或项目（注意，二选一） + - 为什么需要在openEuler里创建一个这样的新SIG - - 新SIG或项目的目标和范围 + - 新SIG的目标和范围 - - 新SIG或项目将为谁服务 + - 新SIG将为谁服务 - - 新SIG或项目需要得到openEuler内哪些SIG或项目的支撑 + - 新SIG需要得到openEuler内哪些SIG或项目的支撑 ### 代码、二进制和服务 - - 该SIG/项目内维护的成果件是那种形式，源码还是tar包或兼而有之？ - - 属于此SIG/项目的范围是什么？包括不限于：子SIG/项目清单、维护的软件包清单 + - 该SIG内维护的成果件是那种形式，源码还是tar包或兼而有之？ + - 属于此SIG的范围是什么？包括不限于：子项目清单、维护的软件包清单 - 希望设置几个repository及其对应关系？ ### 跨领域和面向外部的流程 - 由该SIG/项目定义和执行的，且跨领域和面向外部的流程和行动： + 由该SIG定义和执行的，且跨领域和面向外部的流程和行动： - 非内部流程清单 - - 该SIG/项目拥有的面向整个openEulerSIG/项目的组织指导计划等 + - 该SIG拥有的面向整个openEulerSIG的组织指导计划等 -### 不在本SIG/项目范围内的说明 +### 不在本SIG范围内的说明 其他特殊说明 @@ -49,7 +49,7 @@ ## 角色和组织管理方式 -说明：本SIG/项目遵循[SIG&project-governance](SIG&project-gover)中定义的角色和组织管理方式，并对其进行如下修改。 +说明：本SIG遵循[SIG&project-governance](SIG&project-gover)中定义的角色和组织管理方式，并对其进行如下修改。 ### Maintainer的其他职责 @@ -66,14 +66,14 @@ ### 与[SIG&project-governance](SIG&project-gover)的差异 -- 本SIG/项目的角色和治理方式与定义不同的地方 +- 本SIG的角色和治理方式与定义不同的地方 -- 如果SIG/项目没有Maintainer或Committer，请在此处指定 +- 如果SIG没有Maintainer或Committer，请在此处指定 ### 子项目创建说明 - 子项目名称 -- 子SIG/项目范围说明 +- 子SIG范围说明 diff --git a/zh/technical-committee/governance/template-release.md b/zh/technical-committee/governance/template-release.md index 7d5dc13c8..19f30ece9 100644 --- a/zh/technical-committee/governance/template-release.md +++ b/zh/technical-committee/governance/template-release.md @@ -1,4 +1,4 @@ -# SIG/项目 交付件进入社区发行申请模板 +# SIG 交付件进入社区发行申请模板 (还待补充或细化） -- Gitee