p62978453
/
docs
forked from openkylin/docs
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

改进翻译

This commit is contained in:
bohan 2023-03-14 17:31:21 +08:00
parent 4845442b8e
commit 33a6e5887c
4 changed files with 98 additions and 50 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
.DS_Store vendored Normal file
View File

Binary file not shown.

48
en/aboutUs.md Normal file
View File

@ -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 -->
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.

50
en/openKylinDemandManagementSpecifications.md
View File

@ -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.

50
en/openKylinRequirementsManagementSpecifications.md Normal file
View File

@ -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.