diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..3ca694f30cf16488f544fff1c1e544a02fea5f88 Binary files /dev/null and b/.DS_Store differ diff --git a/en/Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md b/en/Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md new file mode 100644 index 0000000000000000000000000000000000000000..4bbcdf419174045665fbace23d3f68e84cfad758 --- /dev/null +++ b/en/Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md @@ -0,0 +1,50 @@ +--- +title: OpenKylin Requirements Management Specifications +description: +published: true +date: 2023-03-08T08:22:46.338Z +tags: +editor: markdown +dateCreated: 2023-08-08T08:22:46.338Z +--- + +## 1.1 Requirements Collection +When the release planning is clear, the product manager sends out relevant emails to collect requirements through the following two ways, the proposers of these two types of requirements and the specifications for submitting issues about requirements in Gitee are as follows: +- The technical planning requirements for the community release are proposed by the community technical committee, and the product manager enters the requirements issues into the Release-Management repository, selects the issues type as "Requirements", fills in the requirements title and details, marks the release SIG and feature tags, and marks the release milestone. +- The planning requirements of each SIG project for this version are proposed by each SIG group, and the Maintainer of each SIG group will enter the requirements into the repository of this SIG project, select the issues type as "Requirements", fill in the requirements title and details, mark this SIG and feature tag, and mark the version milestone. +- After all requirements are recorded on Gitee, the product manager can filter and summarize all requirements for the entire version via the full issues library of the community. + +Explanation: +- Mark all requirements issues with SIG ownership tags to associate them with SIG groups. +- The requirements details must be clearly filled in according to the template: requirements background, requirements description, implementation plan, and acceptance criteria. +- For requirements that need to be protected, check the Content Risk Identification checkbox to prevent external members from accessing the repository. +- When performing data statistics, count requirements according to the issues type, and mark the feature tag to facilitate filtering on the Gitee web pages. + +## 1.2 Requirements Review +When the product manager summarizes the requirements, the technical committee is organized to complete the review, and after the review is passed, the review conclusion is notified to all subscribers through the mailing list, and the following operations are performed on the code cloud issues: +- For requirements issues to be completed in this version, verify the correct association with a milestone. +- For requirements issues planned to be completed in future versions, verify the correct association with a milestone. +- For requirements issues with no plans for the time being, do not associate them with a milestone, change the status to "rejected," and wait for new plans to modify the status to "confirmed" and correctly associate them with the milestone. + +## 1.3 Requirements Refinement +When the review of requirements is completed, all the requirements issues planned to be completed in this version shall output the Requirements Statement Document within one week, and the document can be submitted through the following ways: +- Requirements document: create a PR, select the target branch, fill in the title as: "[Requirements Issues Title] Requirements Document," describe the PR details in the first line: This document is a detailed description of the requirements (issues number and link), and tag it with PRD, selecting the version milestone. +- After submitting the PR, when the reviewer approves it, merge it. +- Requirements issues: After the requirements document PR is merged, comment on the requirements issues stating the requirements document PR link. + +## 1.4 Requirements Scheduling +When Release SIG group specifies the release plan, the product manager can notify all subscribers of the release plan through the mailing list and notify each SIG group to schedule the requirements issues as follows: +- The SIG Maintainer for each SIG group confirms the requirements issues completion plan for the respective SIG group, marks the "start date" and "end date" on Gitee, and can set the "priority." +- After the requirements issues scheduling is completed, the Release SIG team publishing manager checks the requirements issues scheduling situation, and if there are any disputes about the requirements, an evaluation can be organized. + +Explanation: +- The evaluation conclusion can be notified to all subscribers via the email list. + +## 1.5 Requirements Changes +In the version plan, if there are any changes in the requirements scope and plan, the product manager must organize a technical committee/Release SIG group change review. After the review is completed, the product manager will notify all subscribers of the conclusion via the email list and take the following actions: +- In the comment box of the changed requirements issues, mark the reason for the change and the review conclusion of this requirements. +- For the requirements issues with changes in the milestone, confirm the association with the milestone plan after the change and set the correct scheduling. For requirements issues without plans, do not associate them with a milestone, and change the status to "rejected." +- For requirements issues with changes in scope, the requirements leader needs to output the modified requirements document, and submit it in accordance with section 1.3. + +Explanation: +- The evaluation conclusion can be notified to all subscribers via the email list. \ No newline at end of file diff --git a/en/aboutUs.md b/en/aboutUs.md new file mode 100644 index 0000000000000000000000000000000000000000..a08de181653dda3694aad7455aa8e0ce3d4286a4 --- /dev/null +++ b/en/aboutUs.md @@ -0,0 +1,48 @@ +--- +title: About Us +description: about us +published: true +date: 2023-03-08T07:30:23.959Z +tags: +editor: markdown +dateCreated: 2023-03-08T07:30:23.959Z +--- + +OpenKylin is an open organization and there are many ways to contact us. This webpage will provide some common methods, but not all. Other contact methods can be found on other parts of our website. + +## General Information + +Most of the information about OpenKylin can be found on our website: https://openkylin.top/. Therefore, please browse and search our website before contacting us. + +Our [FAQ](https://docs.qq.com/doc/DWFRHUVVCS01zeUFj?u=70a0637feb964f6bb9cceeb732675673) can answer many questions you may have about OpenKylin. + +Many questions related to OpenKylin can also be addressed through our mailing list: + +https://mailweb.openkylin.top/postorius/lists/ + +If you are certain that our website and documentation cannot solve your problem, we have a community where users and developers can join together to discuss and possibly answer your questions. + +All community-related questions can be subscribed to our mailing list: + +https://www.openkylin.top/community/index-cn.html , or join the community for submission. + +## Promotion + +If you want to request our articles or put news on our news webpage, please contact our official email at contact@openkylin.top. + +## Events + +Please submit invitations for seminars, exhibitions, or other events to: + +https://www.openkylin.top/community/community-cn.html + +## Assisting OpenKylin + + +If you are willing to assist OpenKylin, please refer to the [Contribution Guidelines](/zh/开始贡献/openKylin贡献攻略) first. +If you are interested in maintaining an OpenKylin mirror, please refer to the [OpenKylin Mirror](https://www.openKylin.top/downloads/index-cn.html). Any issues with existing mirrors can be reported to contact@openkylin.top + +## Harassment Issues + +OpenKylin is a community that values etiquette and speech. If you are a victim of any behavior or feel harassed, whether it be in a seminar, project-organized collective development, or general project interactions, please contact the community team at the following email address: contact@openkylin.top. diff --git "a/\347\211\210\346\234\254\347\256\241\347\220\206\350\247\204\350\214\203/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" "b/\347\211\210\346\234\254\347\256\241\347\220\206\350\247\204\350\214\203/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" index 959098c0d2644f3527989182c6b17f78c67d10c1..025488bbe01698ad8e5f212e7538695f8959a98a 100644 --- "a/\347\211\210\346\234\254\347\256\241\347\220\206\350\247\204\350\214\203/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" +++ "b/\347\211\210\346\234\254\347\256\241\347\220\206\350\247\204\350\214\203/openKylin\351\234\200\346\261\202\347\256\241\347\220\206\350\247\204\350\214\203.md" @@ -15,23 +15,23 @@ ## 1.2 需求审核 产品经理汇总需求后，组织技术委员会完成评审，评审通过后将审核结论通过邮件列表通知所有订阅人，并对码云issue进行以下操作： -- 本版本计划完成的需求issue，确认关联正确的里程碑 -- 未来版本计划完成的需求issue，确认关联正确的里程碑 +- 本版本计划完成的需求issue，确认关联正确的里程碑。 +- 未来版本计划完成的需求issue，确认关联正确的里程碑。 - 审核确认暂无规划的需求issue，不关联里程碑，更改状态为“已拒绝”，待后续有新的规划，可以修改状态为“已确认”，并关联正确里程碑。 ## 1.3 需求细化 需求评审完成后，本版本计划完成的需求issue均须一周内输出《需求说明文档》，并可以通过以下方式提交文档： -- 需求说明文档：创建PR，选择目标分支，填写标题为：“【需求issue标题】需求说明书”，PR详情描述第一行写明：本文档是对需求（issue编号和链接）的详细说明，同时标记标签为PRD，选择版本里程碑 -- 提交PR后，审核人员通过后，合并PR -- 需求issue：需求说明PR合并后，在需求issue的评论框写明：需求说明PR链接 +- 需求说明文档：创建PR，选择目标分支，填写标题为：“【需求issue标题】需求说明书”，PR详情描述第一行写明：本文档是对需求（issue编号和链接）的详细说明，同时标记标签为PRD，选择版本里程碑。 +- 提交PR后，审核人员通过后，合并PR。 +- 需求issue：需求说明PR合并后，在需求issue的评论框写明：需求说明PR链接。 ## 1.4 需求排期 Release SIG组明确发布计划后，产品经理可将版本计划通过邮件列表通知所有订阅人，并通知各SIG组对需求issue进行排期，具体操作如下： -- 各SIG组Maintainer明确本SIG组需求issue完成计划，在码云标注issue的“开始日期”、“结束日期”，并可设置“优先级” +- 各SIG组Maintainer明确本SIG组需求issue完成计划，在码云标注issue的“开始日期”、“结束日期”，并可设置“优先级”。 - 待需求issue排期完成后，Release SIG组发布经理核对需求issue排期情况，对于有争议的需求可以组织评审。 说明： -- 评审结论可通过邮件列表通知所有订阅人 +- 评审结论可通过邮件列表通知所有订阅人。 ## 1.5 需求变更 在版本计划内，若需求范围和计划等出现变化，产品经理要组织技术委员会/Release SIG组进行变更评审，评审完成后产品经理将结论通过邮件列表通知所有订阅人，并进行以下操作： @@ -40,6 +40,6 @@ Release SIG组明确发布计划后，产品经理可将版本计划通过邮件 - 对于需求范围有变更的需求issue，需求负责人要输出变更后的需求文档，并按1.3章节方式提交需求文档PR。 说明： -- 评审结论可通过邮件列表通知所有订阅人 +- 评审结论可通过邮件列表通知所有订阅人。