工作组治理

过程概述和动机

工作组为不同群体提供了一个正式的途径，以便围绕共同问题进行协作，平衡各方的需求，并在完成后解散。 由于它们代表多个群体的利益，因此它们是建立共识的工具。如果作为工作组内协作的一部分开发了代码， 那么该代码将存放在一个适当的仓库中。最终，将此代码合并到仓库中将由提交代码到该仓库的标准政策 （例如，在 SIGs 拥有的一个或多个子项目中开发）管理。

因为工作组是DragonOS项目的官方组成部分，所以其成立和解散受到项目管理委员会(PMC)的监督。

创建和/或已撤销的工作组清单可以在 SIG和WG的生命周期 文档中找到。

此流程的目标

  • 为那些希望成立并最终解散新的工作组的人提供一个易于导航的过程
  • 在工作组有意义的地方提供简单指导和区分，以及无意义的地方
  • 清晰理解工作组不授予任何权力
  • 确保所有未来的工作组符合此过程

不是此流程的目标

  • 记录其他治理机构，如子项目或 SIGs
  • 更改现有工作组/ SIGs /子项目的状态

工作组与 SIGs 的关系

DragonOS项目拥有的资产（例如代码、文档、博客、流程等）由SIG拥有和管理。例外的是，工作组可能拥有的特定资产，如下所述。

工作组为治理和沟通渠道提供结构，因此可能拥有以下类型的资产：

  • 日历事件
  • 论坛版块
  • 微信/QQ群组

工作组与 SIGs 的不同之处在于，它们旨在：

  • 促进 SIGs 之间的协作
  • 通过一个具有最小管理开销的团体来探索问题及其对应的解决方案

工作组通常会有利益相关方，其参与是在一个或多个 SIGs 的背景下。这些 SIGs 应作为工作组的利益相关方记录在 这个工作组的README文件中（见创建过程）。

信息同步

工作组组织者需要向各自的代表的 SIG 的主席同步相关的信息。组织者负责向项目管理委员会提交年度报告。

它是一个工作组吗？是的，如果...

  • 它不拥有任何代码
  • 它有一个通过特定可交付成果或多个可交付成果衡量的明确目标
  • 它的性质是临时的，并在达到其声明目标后解散

创建过程描述

工作组成立的过程比 SIG 成立的过程控制得更松，因为它们：

  • 不拥有代码
  • 有明确的进入和退出标准
  • 没有任何组织权力，只有影响力

因此，工作组成立的过程从组织者问自己一些重要问题开始，这些问题最终应反映在 community仓库 的一个PR中：

  1. 这个团体试图解决的确切问题是什么？
  2. 这个团体将交付什么工件，以及交付给谁？
  3. 该团体如何知道问题解决过程已完成，是时候解散工作组了？
  4. 所有参与解决这个问题的利益相关 SIG 是哪些？
  5. 会议机制是什么（频率、持续时间、角色）？
  6. 工作组的目标是否代表整个项目的需求，还是仅聚焦于一小部分贡献者或公司的利益？
  7. 谁将主持该团体，并确保它继续满足这些要求？
  8. 工作组中是否很好地代表了多样性？

请注意，所有工作组组织者和其他领导角色的持有者必须是 社区成员。

回答上述问题后，完成 SIG和WG的生命周期 文档中的其余清单。 PR合并后，工作组正式成立，直到它完成声明的目标，或自愿解散（例如，由于新事实、成员流失、方向改变等）。工作组应努力向利益相关 SIG 定期报告，以确保使命仍与当前状态保持一致。 工作组的可交付成果（文档、图表）应存放在为工作组创建的目录中。

解散过程描述

如果以下任一情况为真，工作组将被解散：

  • 不再有一个主席
    • （有 4 周的宽限期）
  • 工作组成立时，提交到community仓库的任何公开沟通渠道都没有使用
    • （有 3 个月的宽限期）
    • bbs上的板块
    • 会议链接