From fe0ee2db6dc2a9fa9e88531bc4ab6344cf0a6a1a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=BA=BB=E5=BC=80=E6=9C=97?= Date: Sun, 12 Mar 2023 03:19:14 +0000 Subject: [PATCH 1/4] =?UTF-8?q?add=20en/Community-Policies-and-Rules/Issue?= =?UTF-8?q?=5FReporting=5FSpecifications.md=20=E7=BF=BB=E8=AF=91=E6=B7=BB?= =?UTF-8?q?=E5=8A=A0=E7=A4=BE=E5=8C=BA=E6=94=BF=E7=AD=96=E4=B8=8E=E8=A7=84?= =?UTF-8?q?=E5=88=99=E7=9B=AE=E5=BD=95=E4=B8=8B=E7=9A=84issue=E6=8A=A5?= =?UTF-8?q?=E5=91=8A=E8=A7=84=E8=8C=83.md=E6=96=87=E6=A1=A3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: 麻开朗 --- .../Issue_Reporting_Specifications.md | 142 ++++++++++++++++++ 1 file changed, 142 insertions(+) create mode 100644 en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md 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 0000000..ff9375f --- /dev/null +++ b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md @@ -0,0 +1,142 @@ +--- +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 +In order to better manage issues, we divide participants into the following roles: + +| Role | Function | +| :---: | :---: | +| Testers | Test projects under the openKylin community | +| Developer | The actual developer and maintainer of various projects under the openKylin community | +| Community Participants | Community Enthusiasts, Participants | + +
+ +## Issue Category Tags +In medium and large-scale projects, different participants have different degrees of participation in the project. In order for each participant to find and solve issues, we need to classify issues. Each project under the openKylin community has 9 conventional classification labels by default. + +| Tag Name | Description | +| :---: | :---: | +| kind/bug | This issue is an unknown bug proposed by a participant | +| kind/documentation | Issue related to documentation | +| kind/duplicate | This issue is a known bug raised by a contributor | +| kind/enhancement | This issue requests to add new features or optimize existing features | +| kind/good-first-issue | This issue is helpful for developers or testers who are new to the project | +| kind/help-wanted | This issue needs help from other people, or help questions raised by new project participants | +| kind/invalid | The issue is wrong or unavailable | +| kind/question | This issue is doubtful or needs more information| +| kind/wontfix | The issue is a functional requirement or fix that is not planned to be implemented within the visible project schedule | + +
+ +
+ +## Issue Status Tags +In fact, different issues have very different impacts on the project or the urgency to solve them. In order to track the priority and current status of issues, the openKylin community has agreed on many useful tags. + +
+ +### Priority Tags +| Tag Name | Description | +| :---: | :---: | +| priority/high | High-priority, important and urgent issue that needs to be dealt with as soon as possible | +| priority/medium | Medium priority, important but not urgent issue | +| priority/low | Low priority, not important and not urgent, generally used for minor issues, or issues that need to confirm the scheduling 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/resloved | The project maintainer has dealt with the problem described in the issue, close the issue after the review is correct | +| status/reopen | The issue marked reslove has a problem again | +| status/need-assign | The issue needs to assign a participant to be responsible for | + +
+ +### 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, the new tag should not be ambiguous with the existing tags, and the usage and specifications of the tag should be explained, and updated to this document to ensure a unified understanding of project participants. + +
+ +## Issue Workflow + +### Issue Workflow for Testers +1. For the bugs found in the internal test, after submission, mark the kind/bug label and indicate the priority ( priority/high / priority/medium / priority/low ) +2. For the issues submitted by others, mark kind/bug / kind/enhancement / kind/invalid / kind/documentation according to the submitted content, and verify the bug. If the verification passes, evaluate its priority, add or modify the priority label ; +3. If the person in charge can be clearly assigned to the person in the issue, otherwise wait for the developer to collect it himself or the project leader to assign it; +4. For the issue marked with the status/resolved label, perform a regression test. If the acceptance is passed, the issue will be closed. If it fails, the status/resolved label will be replaced with status/reopen; +5. For the reappearance of the issue that passed the acceptance, it is necessary to reopen the issue and label it with status/reopen; + +### Issue Workflow for Developers +1. Self-verify the issue marked as kind/bug, pass the verification, and label it with status/confirmed; +2. Claim status/confirmed bugs (assign to yourself); +3. For the issue assigned to your own name, if you cannot reproduce it or have any doubts, please mark the kind/question label to ask the issue submitter to provide more information; +4. If the assigned bug has been fixed, change to the status/resolved label and let the tester return to the test. If you have a status/reopen issue under your own name, please deal with it in time. +5. Label kind/help-wanted for issues that do not have time to deal with and need help from others. +6. For the functional requirements or repair problems that will not be implemented within the visible project schedule, mark kind/wontfix. + +### Issue Workflow for Community Participants +1. Anyone who finds a problem or needs can submit an issue; +2. Can help confirm the bug (reply under issue); +3. Issues that have not been assigned to people can be claimed (people who are not in various projects under the Ubuntu Kylin community can reply under issue), priority is given to claiming kind/help-wanted issues. + +### Bug Issue +In the process of testing or using openKylin, there are existing functional problems, and the proposed Issue belongs to this type. The Issue template is as follows: + +> ISO Version: The version number of the ISO +> +> Test environment: describe the basic environment of the test, cpu architecture, model, etc. +> +> Test steps: steps to reproduce the problem +> +> 1. xxx +> 2. xxx +> 3. xxxx +> +> Expected result: The expected result of the test step. +> +> Actual results: describe what went wrong during the test +> +> Probability of recurrence: inevitable or occasional +> +> Screenshot: Screenshot of auxiliary problem description +> +> Supplementary explanation: The content that needs to be supplemented. + + +### Feature Issue + The new functional requirements proposed during the continuous development of various projects under the openKylin community, or users wish to add functions during the use of various projects under the openKylin community, the proposed Issue belongs to this type. The Issue template is as follows: +> Functional requirements: Describe the required function points. +> +> Design solution: Describe the design solution for this requirement. +> +> Supplementary Notes: The content that needs to be supplemented. + +The above are the submission specifications for BUG and Issue. You are welcome to contribute to the openKylin community. This specification is also being continuously updated... \ No newline at end of file -- Gitee From a4dd89b44fc49576d763ab2eecf0e7da71fb8007 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=BA=BB=E5=BC=80=E6=9C=97?= Date: Mon, 13 Mar 2023 10:08:09 +0000 Subject: [PATCH 2/4] update en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: 麻开朗 --- .../Issue_Reporting_Specifications.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md index ff9375f..61bfb66 100644 --- a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md +++ b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md @@ -12,24 +12,24 @@ dateCreated: 2022-03-11T03:17:41.558Z ## Role Definitions -In order to better manage issues, we divide participants into the following roles: +For better issues management, we divided the participants into the following roles: | Role | Function | | :---: | :---: | -| Testers | Test projects under the openKylin community | -| Developer | The actual developer and maintainer of various projects under the openKylin community | -| Community Participants | Community Enthusiasts, Participants | +| Tester | Testing of various projects in the openKylin community | +| Developer | The actual developer and maintainer of various projects in the openKylin community | +| Community Participant | Community Enthusiasts, Participants |
-## Issue Category Tags -In medium and large-scale projects, different participants have different degrees of participation in the project. In order for each participant to find and solve issues, we need to classify issues. Each project under the openKylin community has 9 conventional classification labels by default. +## 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 | Issue related to documentation | -| kind/duplicate | This issue is a known bug raised by a contributor | +| kind/duplicate | This issue is a known bug raised by a participant | | kind/enhancement | This issue requests to add new features or optimize existing features | | kind/good-first-issue | This issue is helpful for developers or testers who are new to the project | | kind/help-wanted | This issue needs help from other people, or help questions raised by new project participants | -- Gitee From 9a778a702a8e892fc201a3f58365954fd4723f13 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=BA=BB=E5=BC=80=E6=9C=97?= Date: Tue, 14 Mar 2023 13:29:21 +0000 Subject: [PATCH 3/4] =?UTF-8?q?update=20en/Community-Policies-and-Rules/Is?= =?UTF-8?q?sue=5FReporting=5FSpecifications.md.=20=E8=AE=A2=E6=AD=A3?= =?UTF-8?q?=E5=AE=8C=E5=96=84=E4=BA=86issue=E6=8A=A5=E5=91=8A=E8=A7=84?= =?UTF-8?q?=E8=8C=83=E6=96=87=E6=A1=A3=E7=9A=84=E8=AF=91=E6=96=87?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: 麻开朗 --- .../Issue_Reporting_Specifications.md | 83 ++++++++++--------- 1 file changed, 42 insertions(+), 41 deletions(-) diff --git a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md index 61bfb66..2518c56 100644 --- a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md +++ b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md @@ -17,8 +17,8 @@ For better issues management, we divided the participants into the following rol | Role | Function | | :---: | :---: | | Tester | Testing of various projects in the openKylin community | -| Developer | The actual developer and maintainer of various projects in the openKylin community | -| Community Participant | Community Enthusiasts, Participants | +| Developer | The actual developers and maintainers of various projects in the openKylin community | +| Community Participant | Community enthusiasts or participants |
@@ -28,37 +28,37 @@ In medium to large projects, different participants have different levels of inv | Tag Name | Description | | :---: | :---: | | kind/bug | This issue is an unknown bug proposed by a participant | -| kind/documentation | Issue related to documentation | -| kind/duplicate | This issue is a known bug raised by a participant | -| kind/enhancement | This issue requests to add new features or optimize existing features | -| kind/good-first-issue | This issue is helpful for developers or testers who are new to the project | -| kind/help-wanted | This issue needs help from other people, or help questions raised by new project participants | -| kind/invalid | The issue is wrong or unavailable | -| kind/question | This issue is doubtful or needs more information| -| kind/wontfix | The issue is a functional requirement or fix that is not planned to be implemented within the visible project schedule | +| 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 very different impacts on the project or the urgency to solve them. In order to track the priority and current status of issues, the openKylin community has agreed on many useful 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 dealt with as soon as possible | +| 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 and not urgent, generally used for minor issues, or issues that need to confirm the scheduling plan | +| 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 +- priority/high: #ff0000 +- priority/medium: #ff3366 +- priority/low: #aa8899
@@ -66,9 +66,9 @@ In fact, different issues have very different impacts on the project or the urge | Tag Name | Description | | :---: | :---: | | status/confirmed | The project maintainer has confirmed that the problem described in the issue exists | -| status/resloved | The project maintainer has dealt with the problem described in the issue, close the issue after the review is correct | -| status/reopen | The issue marked reslove has a problem again | -| status/need-assign | The issue needs to assign a participant to be responsible for | +| 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 |
@@ -81,62 +81,63 @@ In fact, different issues have very different impacts on the project or the urge
## Tag Extensions -If a new tag is added due to project needs, the new tag should not be ambiguous with the existing tags, and the usage and specifications of the tag should be explained, and updated to this document to ensure a unified understanding of project participants. +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 the bugs found in the internal test, after submission, mark the kind/bug label and indicate the priority ( priority/high / priority/medium / priority/low ) -2. For the issues submitted by others, mark kind/bug / kind/enhancement / kind/invalid / kind/documentation according to the submitted content, and verify the bug. If the verification passes, evaluate its priority, add or modify the priority label ; +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 the person in charge can be clearly assigned to the person in the issue, otherwise wait for the developer to collect it himself or the project leader to assign it; 4. For the issue marked with the status/resolved label, perform a regression test. If the acceptance is passed, the issue will be closed. If it fails, the status/resolved label will be replaced with status/reopen; 5. For the reappearance of the issue that passed the acceptance, it is necessary to reopen the issue and label it with status/reopen; ### Issue Workflow for Developers -1. Self-verify the issue marked as kind/bug, pass the verification, and label it with status/confirmed; +1. Self-verify the issue marked as kind/bug, if the verification, and label it with status/confirmed; 2. Claim status/confirmed bugs (assign to yourself); 3. For the issue assigned to your own name, if you cannot reproduce it or have any doubts, please mark the kind/question label to ask the issue submitter to provide more information; 4. If the assigned bug has been fixed, change to the status/resolved label and let the tester return to the test. If you have a status/reopen issue under your own name, please deal with it in time. -5. Label kind/help-wanted for issues that do not have time to deal with and need help from others. +5. Mark the issues that do not have time to deal with and need help from others as 'kind/help-wanted'. 6. For the functional requirements or repair problems that will not be implemented within the visible project schedule, mark kind/wontfix. ### Issue Workflow for Community Participants -1. Anyone who finds a problem or needs can submit an issue; -2. Can help confirm the bug (reply under issue); -3. Issues that have not been assigned to people can be claimed (people who are not in various projects under the Ubuntu Kylin community can reply under issue), priority is given to claiming kind/help-wanted issues. +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 -In the process of testing or using openKylin, there are existing functional problems, and the proposed Issue belongs to this type. The Issue template is as follows: +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 +> ISO Version: The version number of the ISO. > -> Test environment: describe the basic environment of the test, cpu architecture, model, etc. +> Test environment: Description of the basic testing environment, including CPU architecture, device model, etc. > -> Test steps: steps to reproduce the problem +> Test steps: Steps to reproduce the issue. > > 1. xxx > 2. xxx > 3. xxxx > -> Expected result: The expected result of the test step. +> Expected result: The expected result of the test steps. > -> Actual results: describe what went wrong during the test +> Actual results: Description of the problems that occur during testing. > -> Probability of recurrence: inevitable or occasional +> Reproduction Probability: The bug issue is inevitable or occasional. > -> Screenshot: Screenshot of auxiliary problem description +> Screenshot: Screenshots to help explain the issue. > -> Supplementary explanation: The content that needs to be supplemented. +> Supplementary Note: Any additional content that needs to be supplemented. ### Feature Issue - The new functional requirements proposed during the continuous development of various projects under the openKylin community, or users wish to add functions during the use of various projects under the openKylin community, the proposed Issue belongs to this type. The Issue template is as follows: -> Functional requirements: Describe the required function points. +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: Describe the design solution for this requirement. +> Design solution: Description of the design solution for this requirement. > -> Supplementary Notes: The content that needs to be supplemented. +> Supplementary Notes: Contents that needs to be supplemented. -The above are the submission specifications for BUG and Issue. You are welcome to contribute to the openKylin community. This specification is also being continuously updated... \ No newline at end of file +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 -- Gitee From 53f1f04dcb6181da4cc58558744b600ae951c4ad Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=BA=BB=E5=BC=80=E6=9C=97?= Date: Tue, 14 Mar 2023 16:10:55 +0000 Subject: [PATCH 4/4] update en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Signed-off-by: 麻开朗 --- .../Issue_Reporting_Specifications.md | 20 +++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md index 2518c56..038ceb0 100644 --- a/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md +++ b/en/Community-Policies-and-Rules/Issue_Reporting_Specifications.md @@ -88,19 +88,19 @@ If a new tag is added due to project needs, it should not create ambiguity with ## 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'); +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 the person in charge can be clearly assigned to the person in the issue, otherwise wait for the developer to collect it himself or the project leader to assign it; -4. For the issue marked with the status/resolved label, perform a regression test. If the acceptance is passed, the issue will be closed. If it fails, the status/resolved label will be replaced with status/reopen; -5. For the reappearance of the issue that passed the acceptance, it is necessary to reopen the issue and label it with status/reopen; +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 the issue marked as kind/bug, if the verification, and label it with status/confirmed; -2. Claim status/confirmed bugs (assign to yourself); -3. For the issue assigned to your own name, if you cannot reproduce it or have any doubts, please mark the kind/question label to ask the issue submitter to provide more information; -4. If the assigned bug has been fixed, change to the status/resolved label and let the tester return to the test. If you have a status/reopen issue under your own name, please deal with it in time. -5. Mark the issues that do not have time to deal with and need help from others as 'kind/help-wanted'. -6. For the functional requirements or repair problems that will not be implemented within the visible project schedule, mark kind/wontfix. +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; -- Gitee