diff --git "a/SIG\344\275\277\347\224\250\346\211\213\345\206\214/SIG\347\273\204\347\232\204\347\224\263\350\257\267\344\270\216\346\222\244\351\224\200\346\265\201\347\250\213.md" "b/SIG\344\275\277\347\224\250\346\211\213\345\206\214/SIG\347\273\204\347\232\204\347\224\263\350\257\267\344\270\216\346\222\244\351\224\200\346\265\201\347\250\213.md" index ec12127f6241df54b341d3c40b8ab5ef42160fbf..9df4e6a4e33cfabf9f759d235b2f06a18c9fa05d 100644 --- "a/SIG\344\275\277\347\224\250\346\211\213\345\206\214/SIG\347\273\204\347\232\204\347\224\263\350\257\267\344\270\216\346\222\244\351\224\200\346\265\201\347\250\213.md" +++ "b/SIG\344\275\277\347\224\250\346\211\213\345\206\214/SIG\347\273\204\347\232\204\347\224\263\350\257\267\344\270\216\346\222\244\351\224\200\346\265\201\347\250\213.md" @@ -52,31 +52,19 @@ SIG 所有成员 [签署个人cla](https://cla.openkylin.top) 后，请按照以 **运作**：SIG 正式运作，组内成员通过邮件列表、组内会议等进行沟通交流。新的 SIG 组运行初期，可以由技术委员会指定一个委员作为该 SIG 组的导师为 SIG 组进行指导，以确保该 SIG 组快速步入正轨。 -## SIG 组的撤销 - -以下情形发生时可以由 SIG 组成员或者技术委员会提出撤销 SIG 组申请： - -* SIG 组的工作因为无法满足社区版本的要求而阻碍了共创麒麟社区版本的发布。 -* SIG 组无法正常运转，包括无固定例会，无法及时响应社区 Issue，所负责的软件没有及时更新等。 - +## SIG 组的撤销规范 +### 撤销原则 +以下情形发生时可以由该SIG 组Owner或者技术委员会委员提出撤销 SIG 组申请： + +* SIG 组长时间活跃度很低，无法维持日常运转。包括但不限于存在：长时间（超过6个月）没有召开过例会、从未参与过社区SIG组相关活动（包括版本发行）、一直没有负责的软件仓库或者所负责的软件仓库长时间没有代码更新、不能及时响应社区反馈的issues等等不活跃现象； +* SIG 组负责openKylin版本中重要的模块或技术方向，但是目前的工作无法满足openKylin版本对该模块或技术方向的要求，阻碍了openKylin版本的发布和技术发展； +* SIG组的目标规划、技术路线等与另外的SIG组有重合； +* 其他技术委员会认为需要撤销SIG组的情形。 ### 撤销流程 - -#### 由 SIG 组 Owner 提出撤销申请 - -* 由 SIG 组 Owner 提出 SIG 组撤销申请，请按照以下步骤执行申请： -1. 由相关提议人 Fork 项目 [openKylin / community](https://gitee.com/openkylin/community) 到您的 Gitee 下。并删除在您的 Gitee 项目下的 sig 目录下的相关 SIG 组目录; -2. 完成以上步骤后，将以上改动提交到 Gitee 上，并向[openKylin / community](https://gitee.com/openkylin/community) 项目提交 PR 申请撤销 SIG 组，填写好相关信息后，技术委员会将提前审核相关信息，并在下一次例会上进行进一步沟通。 - -* 该申请在技术委员会例会上进行讨论并投票决策。投票原则按照简单多数票原则。 - -#### 由技术委员会提出撤销申请 - -* 由技术委员会中的一个委员提出 SIG 组撤销申请，请按照以下步骤执行申请： -1. 由相关提议人 Fork 项目 [openKylin / community](https://gitee.com/openkylin/community) 到你的 Gitee 下。并删除在您的 Gitee 项目下的 sig 目录下的相关 SIG 组目录; -2. 完成以上步骤后，将以上改动提交到 Gitee 上，并向[openKylin / community](https://gitee.com/openkylin/community) 项目提交 PR 申请撤销 SIG 组，填写好相关信息后，技术委员会将提前审核相关信息，并在下一次例会上进行进一步沟通。 - -* 该申请在技术委员会例会上进行讨论并投票决策。投票原则按照简单多数票原则，SIG 组 Owner 请参与到会。 - -* 会议结束后请 SIG 组 Owner 组织内部会议并回复该 Issue，超过一周时间将默认执行会议结果。 - -当 SIG 组被撤销后，该 SIG 组名下的软件包将划分至 release 组，并公示，这些软件包可以由其他 SIG 组认领。 +#### 提交撤销申请 +SIG组撤销申请应由该SIG组Owner或者技术委员会委员提交，提交方式如下： +1. Fork 项目 [openKylin / community](https://gitee.com/openkylin/community) 到您的 Gitee 下。并删除 [community/sig](https://gitee.com/openkylin/community/sig)目录下该SIG组对应的目录； +2. 完成以上步骤后，将改动提交到 Gitee 上，并向[openKylin / community](https://gitee.com/openkylin/community) 项目提交 PR 申请撤销 SIG 组，填写好相关信息（撤销SIG组的详细原因）后，技术委员会将提前审核相关信息，并在下一次例会上针对该议题进行讨论和投票。 +#### 讨论并投票表决 +SIG组撤销申请应在技术委员会例会上进行讨论并通过投票决策。技术委员会全体委员需参与投票表决，投票分为赞同票、反对票和弃权票，可以在例会上直接表决或会后回复邮件表决。需要三分之二或以上委员投赞同票时，撤销申请才能通过。投票结果通过邮件列表公示。 +当 SIG 组被撤销后，该 SIG 组名下需要继续维护的软件包将暂时划分到 Packaging SIG组，并通过邮件列表公示，这些软件包可以由其他 SIG 组或者其他成立新的SIG组来认领维护。 \ No newline at end of file diff --git "a/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" "b/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" new file mode 100644 index 0000000000000000000000000000000000000000..959098c0d2644f3527989182c6b17f78c67d10c1 --- /dev/null +++ "b/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" @@ -0,0 +1,45 @@ +# openKylin需求管理规范 + + +## 1.1 需求收集 +当版本发布计划明确后，产品经理发布相关邮件，通过以下两个途径收集需求，这两类需求的提出者以及在码云提交issue的规范如下： +- 社区版本的技术规划需求，由社区技术委员会提出，由产品经理将需求issue录入Release-Management仓库下，选择issue类型为“需求”，填写需求标题、详情，标记release SIG和feature标签，并标记版本里程碑。 +- 各SIG项目对本版本的规划需求，由各SIG组提出，由各SIG组Maintainer将需求录入本SIG项目仓库下，选择issue类型为“需求”，填写需求标题、详情，标记本SIG和feature标签，并标记版本里程碑。 +- 当所有需求都录入码云后，产品经理可以通过社区的全量issue筛选汇总版本全部需求。 + +说明： +- 通过标记SIG归属标签，将所有需求issue与SIG组对应起来。 +- 需求详情须按模板填写清楚：需求背景、需求描述、实现方案、验收标准。 +- 对于需要保护的需求可以选中内容风险标识复选框，以防仓库外成员访问。 +- 数据统计时，以issue类型来统计需求，标签feature以便于码云前台页面筛选。 + +## 1.2 需求审核 +产品经理汇总需求后，组织技术委员会完成评审，评审通过后将审核结论通过邮件列表通知所有订阅人，并对码云issue进行以下操作： +- 本版本计划完成的需求issue，确认关联正确的里程碑 +- 未来版本计划完成的需求issue，确认关联正确的里程碑 +- 审核确认暂无规划的需求issue，不关联里程碑，更改状态为“已拒绝”，待后续有新的规划，可以修改状态为“已确认”，并关联正确里程碑。 + +## 1.3 需求细化 +需求评审完成后，本版本计划完成的需求issue均须一周内输出《需求说明文档》，并可以通过以下方式提交文档： +- 需求说明文档：创建PR，选择目标分支，填写标题为：“【需求issue标题】需求说明书”，PR详情描述第一行写明：本文档是对需求（issue编号和链接）的详细说明，同时标记标签为PRD，选择版本里程碑 +- 提交PR后，审核人员通过后，合并PR +- 需求issue：需求说明PR合并后，在需求issue的评论框写明：需求说明PR链接 + +## 1.4 需求排期 +Release SIG组明确发布计划后，产品经理可将版本计划通过邮件列表通知所有订阅人，并通知各SIG组对需求issue进行排期，具体操作如下： +- 各SIG组Maintainer明确本SIG组需求issue完成计划，在码云标注issue的“开始日期”、“结束日期”，并可设置“优先级” +- 待需求issue排期完成后，Release SIG组发布经理核对需求issue排期情况，对于有争议的需求可以组织评审。 + +说明： +- 评审结论可通过邮件列表通知所有订阅人 + +## 1.5 需求变更 +在版本计划内，若需求范围和计划等出现变化，产品经理要组织技术委员会/Release SIG组进行变更评审，评审完成后产品经理将结论通过邮件列表通知所有订阅人，并进行以下操作： +- 在变更需求issue的评论框内，标注本需求变更原因和评审结论。 +- 对于里程碑有变更的需求issue，要确认关联变更后的里程碑计划，并设置正确的排期，对于暂无规划的需求issue，不关联里程碑，更改状态为“已拒绝”。 +- 对于需求范围有变更的需求issue，需求负责人要输出变更后的需求文档，并按1.3章节方式提交需求文档PR。 + +说明： +- 评审结论可通过邮件列表通知所有订阅人 + +