From 4845442b8ef2da3dde0deb11e492a438794a1463 Mon Sep 17 00:00:00 2001 From: bohan Date: Wed, 8 Mar 2023 17:00:58 +0800 Subject: [PATCH 1/4] =?UTF-8?q?=E7=BF=BB=E8=AF=91=20openKylin=E9=9C=80?= =?UTF-8?q?=E6=B1=82=E7=AE=A1=E7=90=86=E8=A7=84=E8=8C=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- en/openKylinDemandManagementSpecifications.md | 50 +++++++++++++++++++ 1 file changed, 50 insertions(+) create mode 100644 en/openKylinDemandManagementSpecifications.md diff --git a/en/openKylinDemandManagementSpecifications.md b/en/openKylinDemandManagementSpecifications.md new file mode 100644 index 0000000..9f85425 --- /dev/null +++ b/en/openKylinDemandManagementSpecifications.md @@ -0,0 +1,50 @@ +--- +title: OpenKylin Demand Management Specifications +description: +published: true +date: 2023-03-08T08:22:46.338Z +tags: +editor: markdown +dateCreated: 2023-08-08T08:22:46.338Z +--- + +## 1.1 Requirement Collection +After the release plan is clear, the product manager releases relevant emails and collects requirements through the following two channels. The specifications for the proposers of these two types of requirements and submission of issues on Gitee are as follows: +- Community version's technical planning requirements are proposed by the community technical committee and the product manager records the demand issue under the Release-Management repository, selecting the issue type as "requirement," filling in the demand title and details, marking release SIG and feature tags, and marking the version milestone. +- The planning requirements for this version by the various SIG projects are proposed by their respective SIG groups, and the SIG Maintainer records the demands under the corresponding SIG project repository. The issue type is "requirement," filled in with the demand title and details, marked - with the corresponding SIG and feature tags, and marked with 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 issue library of the community. + +Explanation: +- Mark all demand issues with SIG ownership tags to associate them with SIG groups. +- The demand details must be clearly filled in according to the template: demand background, demand 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 issue type, and mark the feature tag to facilitate filtering on the Gitee web pages. + +## 1.2 Requirement Review +After the product manager summarizes the requirements, the technical committee completes the review. After the review is approved, the review conclusion will be notified to all subscribers via the email list, and the following actions will be taken on the Gitee issue: +- For demand issues to be completed in this version, verify the correct association with a milestone. +- For demand issues planned to be completed in future versions, verify the correct association with a milestone. +- For demand 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 Requirement Refinement +After the demand review is completed, demands to be completed in this version must output a "Requirement Document" within one week. This can be submitted in the following ways: +- Requirement document: create a PR, select the target branch, fill in the title as: "[Requirement Issue Title] Requirement Document," describe the PR details in the first line: This document is a detailed description of the requirement (issue number and link), and tag it with PRD, selecting the version milestone. +- After submitting the PR, when the reviewer approves it, merge it. +- Requirement issue: After the requirement document PR is merged, comment on the requirement issue stating the requirement document PR link. + +## 1.4 Requirement Scheduling +After the Release SIG team confirms the release plan, the product manager can notify all subscribers via email and inform the various SIG groups to schedule the demand issues. The specific operations are as follows: +- The SIG Maintainer for each SIG group confirms the demand issue completion plan for the respective SIG group, marks the "start date" and "end date" on Gitee, and can set the "priority." +- After the demand issue scheduling is completed, the Release SIG team publishing manager checks the demand issue 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 Requirement Changes +In the version plan, if there are any changes in the demand 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 demand issue, mark the reason for the change and the review conclusion of this demand. +- For the demand issue with changes in the milestone, confirm the association with the milestone plan after the change and set the correct scheduling. For demand issues without plans, do not associate them with a milestone, and change the status to "rejected." +- For demand issues with changes in scope, the demand leader needs to output the modified demand 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 -- Gitee From 33a6e5887c8b00d68c7bed0fb588e800e4457837 Mon Sep 17 00:00:00 2001 From: bohan Date: Tue, 14 Mar 2023 17:31:21 +0800 Subject: [PATCH 2/4] =?UTF-8?q?=E6=94=B9=E8=BF=9B=E7=BF=BB=E8=AF=91?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .DS_Store | Bin 0 -> 8196 bytes en/aboutUs.md | 48 +++++++++++++++++ en/openKylinDemandManagementSpecifications.md | 50 ------------------ ...linRequirementsManagementSpecifications.md | 50 ++++++++++++++++++ 4 files changed, 98 insertions(+), 50 deletions(-) create mode 100644 .DS_Store create mode 100644 en/aboutUs.md delete mode 100644 en/openKylinDemandManagementSpecifications.md create mode 100644 en/openKylinRequirementsManagementSpecifications.md diff --git a/.DS_Store b/.DS_Store new file mode 100644 index 0000000000000000000000000000000000000000..3ca694f30cf16488f544fff1c1e544a02fea5f88 GIT binary patch literal 8196 zcmeHM&1(}u6o1>qd{AtAuuwtDiU>UvP3uREqNX3>$DxW_?7`YLX+j!Ivmx0uXo$vd zMGqo)uP4ES-UN@8f+C2m2Tuwr2tD>MP~YtAZr*IN-m0QAW#?_?y*IyKezV!xw*>%Y zsFdsj=mLNc9?W*MV%MZGKRX&)i#4(rt%CWGP4{Ut`dq#tQVvK3qyka_sen{KD)6@` zfO|G;A&-5Zdu1;bkP7^l3b6ZwiU+eX%htFxZynf~B>-AK4x0_nJJ<6tvoUUGeK=!K!j7BjS&>P`?~X;UGq>D-cbS{xX<|bC)($$cfVh3 z6`71KQXl2;HML^v?&MPRW_}U3#&E+^psi?cPF^ncOztc7q;Ad5hzwXzvna}CFynA( zG9P92>qwEGi5w^#OZT!>y0di6Co*f(F+%WDPAf%+lPiW?mmV=94|5muUpS=gAALNw zC~!EO|A8DFAH{!Wym!{e&ZSB;^9#6#7nlG6maDxSZF66xO6B!ix1Zui`##zD!W@)? zR}AH$RM#9HlSOUK%>y=uZrD6*KjraxP2^FJsjq`q4CMiBbsp@RWjqq)V&1wBzDVS= znW7Pid{A0^{tba(FdS?Rp3`RavS!4MQgJ9=ILkhb>3TL{pT`qtGO6-Z$EIODXT&qP zRKZNhBvTkNF`mgK_41Hj$|Z|tuErhVa40<0vAI&|i}Xi&)m;O7s=aC@%FcI3`>WM( zsB_!S1E;6XXXkSIU8WvB16j{Xu#tau`g?e0E|C4D=mn-6G`_g~RNQFKs<6oR9Ks@d z#87dS;blfh;4!Zia#=l>#&O2o^j%uI^eX*4eVuXyX#eK+Q;xR>M2_|xl%rP+&4K z{t<0t2pQP>g_{hkwN*T(@nDU`)wnfNurteXv}QSu*7=7ao~szja$=UPaf>6^e*236 ZtA>&LKR)EydpF%%<^EqURR7`q|0nP(`XK-S literal 0 HcmV?d00001 diff --git a/en/aboutUs.md b/en/aboutUs.md new file mode 100644 index 0000000..a08de18 --- /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/en/openKylinDemandManagementSpecifications.md b/en/openKylinDemandManagementSpecifications.md deleted file mode 100644 index 9f85425..0000000 --- a/en/openKylinDemandManagementSpecifications.md +++ /dev/null @@ -1,50 +0,0 @@ ---- -title: OpenKylin Demand Management Specifications -description: -published: true -date: 2023-03-08T08:22:46.338Z -tags: -editor: markdown -dateCreated: 2023-08-08T08:22:46.338Z ---- - -## 1.1 Requirement Collection -After the release plan is clear, the product manager releases relevant emails and collects requirements through the following two channels. The specifications for the proposers of these two types of requirements and submission of issues on Gitee are as follows: -- Community version's technical planning requirements are proposed by the community technical committee and the product manager records the demand issue under the Release-Management repository, selecting the issue type as "requirement," filling in the demand title and details, marking release SIG and feature tags, and marking the version milestone. -- The planning requirements for this version by the various SIG projects are proposed by their respective SIG groups, and the SIG Maintainer records the demands under the corresponding SIG project repository. The issue type is "requirement," filled in with the demand title and details, marked - with the corresponding SIG and feature tags, and marked with 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 issue library of the community. - -Explanation: -- Mark all demand issues with SIG ownership tags to associate them with SIG groups. -- The demand details must be clearly filled in according to the template: demand background, demand 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 issue type, and mark the feature tag to facilitate filtering on the Gitee web pages. - -## 1.2 Requirement Review -After the product manager summarizes the requirements, the technical committee completes the review. After the review is approved, the review conclusion will be notified to all subscribers via the email list, and the following actions will be taken on the Gitee issue: -- For demand issues to be completed in this version, verify the correct association with a milestone. -- For demand issues planned to be completed in future versions, verify the correct association with a milestone. -- For demand 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 Requirement Refinement -After the demand review is completed, demands to be completed in this version must output a "Requirement Document" within one week. This can be submitted in the following ways: -- Requirement document: create a PR, select the target branch, fill in the title as: "[Requirement Issue Title] Requirement Document," describe the PR details in the first line: This document is a detailed description of the requirement (issue number and link), and tag it with PRD, selecting the version milestone. -- After submitting the PR, when the reviewer approves it, merge it. -- Requirement issue: After the requirement document PR is merged, comment on the requirement issue stating the requirement document PR link. - -## 1.4 Requirement Scheduling -After the Release SIG team confirms the release plan, the product manager can notify all subscribers via email and inform the various SIG groups to schedule the demand issues. The specific operations are as follows: -- The SIG Maintainer for each SIG group confirms the demand issue completion plan for the respective SIG group, marks the "start date" and "end date" on Gitee, and can set the "priority." -- After the demand issue scheduling is completed, the Release SIG team publishing manager checks the demand issue 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 Requirement Changes -In the version plan, if there are any changes in the demand 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 demand issue, mark the reason for the change and the review conclusion of this demand. -- For the demand issue with changes in the milestone, confirm the association with the milestone plan after the change and set the correct scheduling. For demand issues without plans, do not associate them with a milestone, and change the status to "rejected." -- For demand issues with changes in scope, the demand leader needs to output the modified demand 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/openKylinRequirementsManagementSpecifications.md b/en/openKylinRequirementsManagementSpecifications.md new file mode 100644 index 0000000..4bbcdf4 --- /dev/null +++ b/en/openKylinRequirementsManagementSpecifications.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 -- Gitee From 049601ea30589ef893e20efae2bbdda81de8595c Mon Sep 17 00:00:00 2001 From: bohan Date: Tue, 14 Mar 2023 17:45:28 +0800 Subject: [PATCH 3/4] =?UTF-8?q?=E7=BB=9F=E4=B8=80=E6=A0=87=E7=82=B9?= =?UTF-8?q?=E7=AC=A6=E5=8F=B7?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...6\241\347\220\206\350\247\204\350\214\203.md" | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) 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 959098c..025488b 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。 说明： -- 评审结论可通过邮件列表通知所有订阅人 +- 评审结论可通过邮件列表通知所有订阅人。 -- Gitee From 63afe5824b3fa865c559645c12a031b6a57f3c92 Mon Sep 17 00:00:00 2001 From: bohan Date: Wed, 15 Mar 2023 15:33:08 +0800 Subject: [PATCH 4/4] =?UTF-8?q?=E4=BF=AE=E6=94=B9=E7=9B=AE=E5=BD=95?= =?UTF-8?q?=E5=92=8C=E6=96=87=E4=BB=B6=E5=90=8D?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .../OpenKylin_Requirements_Management_Specifications.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename en/{openKylinRequirementsManagementSpecifications.md => Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md} (100%) diff --git a/en/openKylinRequirementsManagementSpecifications.md b/en/Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md similarity index 100% rename from en/openKylinRequirementsManagementSpecifications.md rename to en/Version-Management-Specifications/OpenKylin_Requirements_Management_Specifications.md -- Gitee