From f365b4076058b1eb47e21e6230c7c290aaa011db Mon Sep 17 00:00:00 2001 From: Tianxu Han Date: Wed, 8 Mar 2023 09:51:11 +0000 Subject: [PATCH] =?UTF-8?q?add=20en/Version=20Management=20Specification/o?= =?UTF-8?q?penKylin=20Requirement=20Management=20Specification.md.=20?= =?UTF-8?q?=E7=BF=BB=E8=AF=91=E4=BA=86openKylin=E9=9C=80=E6=B1=82=E7=AE=A1?= =?UTF-8?q?=E7=90=86=E8=A7=84=E8=8C=83?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: Tianxu Han --- ...in Requirement Management Specification.md | 49 +++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 en/Version Management Specification/openKylin Requirement Management Specification.md diff --git a/en/Version Management Specification/openKylin Requirement Management Specification.md b/en/Version Management Specification/openKylin Requirement Management Specification.md new file mode 100644 index 00000000..ec78361e --- /dev/null +++ b/en/Version Management Specification/openKylin Requirement Management Specification.md @@ -0,0 +1,49 @@ +#openKylin Requirement Management Specification + +##1.1 Requirement Collection +After the release plan is determined, the product manager sends a relevant email and collects requirements through the following two channels. The following are the guidelines for the submitters of these two types of requirements and how to submit issues on Gitee: + +> +For technical planning requirements of the community version, they are proposed by the Community Technical Committee and the product manager enters the requirement issue into the Release-Management repository. The issue type should be marked as "requirement", and the requirement title, details, release SIG and feature tags, and version milestones should be filled in. +> +For the planning requirements of each SIG project in this version, they are proposed by each SIG group, and the SIG group Maintainer enters the requirements into the SIG project repository. The issue type should be marked as "requirement", and the requirement title, details, SIG and feature tags, and version milestones should be filled in. +> +After all the requirements are entered into Gitee, the product manager can filter and summarize all the requirements for the version through the community's full-issue selection. + +Note: + +> +Mark the SIG attribution tag to associate all requirement issues with the corresponding SIG group. +> +The requirement details should be filled in according to the template: requirement background, requirement description, implementation plan, and acceptance criteria. +> +For requirements that need to be protected, select the content risk identification checkbox to prevent external members from accessing the repository. +> +When statistics are performed, requirements are counted based on the issue type, and the feature tag is used for filtering on the Gitee frontend page. + +##1.2 Requirement Review +After the product manager summarizes the requirements, the Technical Committee completes the review, and after the review is passed, the review conclusion is notified to all subscribers through the email list. The following operations are performed on Gitee issues: + +> +For requirement issues to be completed in this version, confirm the correct milestone association. +> +For requirement issues to be completed in future versions, confirm the correct milestone association. +> +For requirement issues that are not planned for the time being, do not associate them with milestones, change the status to "rejected", and change the status to "confirmed" and associate the correct milestone when new plans are made in the future. + +##1.3 Requirement Refinement +After the requirement review is completed, the requirements that are planned to be completed in this version should output a "Requirement Specification Document" within one week and can be submitted through the following methods: + +> +Requirement Specification Document: Create a pull request, select the target branch, and fill in the title as "[Requirement Issue Title] Requirement Specification Document". In the first line of the PR details description, state that "This document is a detailed description of the requirement (issue number and link)", and mark the tag as PRD and select the version milestone. +> +After submitting the PR, the reviewer approves it and merges the PR. +> +Requirement issue: After the requirement specification PR is merged, write in the comment box of the requirement issue: Requirement Specification PR link. + +##1.4 Requirement Scheduling +After the Release SIG group determines the release plan, the product manager can notify all subscribers of the version plan through the email list and notify each SIG group to schedule the requirement issues. The specific operations are as follows: + +> +The SIG group Maintainer determines the completion plan for the SIG group requirement issue, marks the "start date" and "end date" of the issue in Gitee, and can set the "priority". +> +After the requirement issue scheduling is completed, the Release SIG group publishing manager checks the requirement issue scheduling. For requirements with disputes, a review can be organized. +Note: + +> +The review conclusion can be notified to all subscribers through the email list. + +##1.5 Requirement Changes +If there are changes in the requirement scope and plan within the version plan, the product manager should organize the Technical Committee/Release SIG group to conduct a change review. After the review is completed, the product manager will notify all subscribers of the conclusion through the email list and perform the following operations: + +> +In the comment box of the changed requirement issue, mark the reason for the requirement change and the review conclusion. +> +For requirement issues with changes in the milestone, confirm the association with the updated milestone plan and set the correct scheduling. For requirement issues with no plans, do not associate them with the milestone, change the status to "rejected". +> +For requirement issues with changes in the scope, the requirement owner should output the updated requirement document and submit it as a PR in accordance with section 1.3. + +Note: + +> +The review conclusion can be notified to all subscribers through the email list. \ No newline at end of file -- Gitee