diff --git a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md new file mode 100644 index 0000000000000000000000000000000000000000..038ceb01a30e1627a130b64159af91d733543690 --- /dev/null +++ b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md @@ -0,0 +1,143 @@ +--- +title: Issue Reporting Specifications +description: +published: true +date: 2022-05-17T07:16:52.060Z +tags: +editor: markdown +dateCreated: 2022-03-11T03:17:41.558Z +--- + +# Issue Reporting Specifications + + +## Role Definitions +For better issues management, we divided the participants into the following roles: + +| Role | Function | +| :---: | :---: | +| Tester | Testing of various projects in the openKylin community | +| Developer | The actual developers and maintainers of various projects in the openKylin community | +| Community Participant | Community enthusiasts or participants | + +
+ +## Issue Kind Tags +In medium to large projects, different participants have different levels of involvement in the project. To make it easier for each participant to find and resolve issues, we need to categorize issues. By default, projects in the openKylin community have 9 agreed-upon kind tags. + +| Tag Name | Description | +| :---: | :---: | +| kind/bug | This issue is an unknown bug proposed by a participant | +| kind/documentation | This issue is related to the document | +| kind/duplicate | This issue is a known bug proposed by a participant | +| kind/enhancement | This issue is proposed to request the addition of new features or optimization of existing ones | +| kind/good-first-issue | This issue is helpful for developers or testers who are fresh to the project | +| kind/help-wanted | This issue requires seeking help from other personnel to resolve or is a help request proposed by a new project participant | +| kind/invalid | The issue is incorrect or unavailable | +| kind/question | This issue is in doubt or requires further information to be provided | +| kind/wontfix | The issue is a feature request or fix that is not planned to be implemented within the visible project schedule | + +
+ +
+ +## Issue Status Tags +In fact, different issues have a varying degree of impact on the project or urgency to be addressed. To track the priority and current status of issues, the openKylin community has established many useful tags. + +
+ +### Priority Tags +| Tag Name | Description | +| :---: | :---: | +| priority/high | High-priority, important and urgent issue that needs to be addressed as soon as possible | +| priority/medium | Medium priority, important but not urgent issue | +| priority/low | Low priority, not important or urgent, typically used for minor issues or issues that require confirmation of the schedule plan | + +
+ +### Color Values for Various Priority Tags: +- priority/high: #ff0000 +- priority/medium: #ff3366 +- priority/low: #aa8899 + +
+ +### Issue Status Tags +| Tag Name | Description | +| :---: | :---: | +| status/confirmed | The project maintainer has confirmed that the problem described in the issue exists | +| status/resolved | The project maintainer has resolved the problem described in the issue and closed the issue after review | +| status/reopen | The issue marked "resolve" has come up with a new problem | +| status/need-assign | This issue needs to be assigned to a specific participant for responsibility | + +
+ +### Color Values for Various Issue Status Tags： +- status/need-assign: #ffff00 +- status/confirmed: #00ffff +- status/resolved: #00ff00 +- status/reopen: #ff6666 + +
+ +## Tag Extensions +If a new tag is added due to project needs, it should not create ambiguity with existing ones. The usage and specifications of the tag should be clearly described and updated in this document to ensure a unified understanding among project participants. + +
+ +## Issue Workflow + +### Issue Workflow for Testers +1. For bugs discovered during internal testing, add the tag 'kind/bug' after the submission, along with the priority level ('priority/high', 'priority/medium', or 'priority/low'); +2. For issues proposed by others, mark 'kind/bug', 'kind/enhancement', 'kind/invalid' or 'kind/documentation' according to the content and verify the bug. If the verification passes, evaluate its priority, add or modify the priority tag; +3. If there is a clear person responsible for the issue, assign it directly to him/her. Otherwise wait for the developer to claim it himself or the project manager to assign it; +4. For issues marked as 'status/resolved', perform regression testing. If the testing passes, then close the issues, otherwise replace the tag 'status/resolved' with 'status/reopen'; +5. For issues that passed acceptance testing but the problem reoccurs, reopen the issue and marked them as 'status/reopen'; + +### Issue Workflow for Developers +1. Self-verify issues marked as 'kind/bug', and upon successful verification, add a tag 'status/confirmed'; +2. Claim bugs marked as 'status/confirmed' (assign it to oneself); +3. For issues assigned to oneself, if unable to reproduce or having questions, add a 'kind/question' tag to request more information from the issue submitter; +4. Change the tag of the assigned bug that has been fixed to 'status/resolved' and assign it to the testing team for regression testing. Besides, handle issues marked as 'status/reopen' promptly. +5. For issues that require assistance from others but one does not have time to handle at the moment, mark them as 'kind/help-wanted'. +6. For feature requests or issues that will not be implemented within the visible project timeline, mark them as 'kind/wontfix'. + +### Issue Workflow for Community Participants +1. Anyone who finds a problem or has a request can submit an issue; +2. Help confirm a bug by replying to the corresponding issue; +3. Claim issues that are not yet assigned to anyone (reply to the issue for those who have not participated in any projects of the openKylin community), and prioritize claiming issues marked as 'kind/help-wanted". + +### Bug Issue +If one runs into an existing feature problem while testing or using OpenKylin, the proposed issue belongs to this type. Here is a template for the issue: + +> ISO Version: The version number of the ISO. +> +> Test environment: Description of the basic testing environment, including CPU architecture, device model, etc. +> +> Test steps: Steps to reproduce the issue. +> +> 1. xxx +> 2. xxx +> 3. xxxx +> +> Expected result: The expected result of the test steps. +> +> Actual results: Description of the problems that occur during testing. +> +> Reproduction Probability: The bug issue is inevitable or occasional. +> +> Screenshot: Screenshots to help explain the issue. +> +> Supplementary Note: Any additional content that needs to be supplemented. + + +### Feature Issue +If the issue is related to requests for new features during the continuous development of various projects or users' desire to add features while using the various projects in the openKylin community, it belongs to this type. The Issue template is as follows: + +> Feature requirements: Description of the required feature points. +> +> Design solution: Description of the design solution for this requirement. +> +> Supplementary Notes: Contents that needs to be supplemented. + +The above are the submission specifications for BUG and Issue. We welcome everyone to contribute to the openKylin community. This specification is also continuously updated...... \ No newline at end of file