commited all the changes
parent
1cf3b648f6
commit
bc77cff2f8
|
@ -6,19 +6,17 @@ weight: 20
|
|||
|
||||
<!-- overview -->
|
||||
|
||||
Alongside the [PR Wrangler](/docs/contribute/participate/pr-wranglers),and formal approvers, and reviewers, members of SIG Docs take week long shifts [triaging and categorising issues](/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues) for the repository.
|
||||
Alongside the [PR Wrangler](/docs/contribute/participate/pr-wranglers),formal approvers, and reviewers, members of SIG Docs take week long shifts [triaging and categorising issues](/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues) for the repository.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## Duties
|
||||
|
||||
Each day in a week-long shift as Issue Wrangler:
|
||||
Each day in a week-long shift the Issue Wrangler will be responsible for:
|
||||
|
||||
- Triage and tag incoming issues daily. See [Triage and categorize issues](https://github.com/kubernetes/website/blob/main/content/en/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
|
||||
- Identifying whether the issue falls under the support category and assigning a "triage/accepted" status.
|
||||
- Ensuring the issue is tagged with the appropriate sig/area/kind labels.
|
||||
- Triage and tagging incoming issues daily. See [Triage and categorize issues](https://github.com/kubernetes/website/blob/main/content/en/docs/contribute/review/for-approvers.md/#triage-and-categorize-issues) for guidelines on how SIG Docs uses metadata.
|
||||
- Keeping an eye on stale & rotten issues within the kubernetes/website repository.
|
||||
- Maintenance of [Issues board](https://github.com/orgs/kubernetes/projects/72/views/1) would be nice
|
||||
- Maintenance of the [Issues board](https://github.com/orgs/kubernetes/projects/72/views/1) would be nice.
|
||||
|
||||
### Requirements
|
||||
|
||||
|
@ -69,12 +67,12 @@ For an open source project to succeed, good issue management is crucial. But it
|
|||
|
||||
Close issues when:
|
||||
|
||||
- When a similar issue is reported more than once, you'll first tag it as /triage duplicate; link it to the main issue & then close it. It is also advisable to direct the users to the original issue.
|
||||
- A similar issue is reported more than once.You will first need to tag it as /triage duplicate; link it to the main issue & then close it. It is also advisable to direct the users to the original issue.
|
||||
- It is very difficult to understand and address the issue presented by the author with the information provided.
|
||||
However, encourage the user to provide more details or reopen the issue if they can reproduce it later.
|
||||
- Having implemented the same functionality elsewhere. One can close this issue and direct user to the appropriate place.
|
||||
- Feature requests that are not currently planned or aligned with the project's goals.
|
||||
- In cases where an issue appears to be spam and is clearly unrelated.
|
||||
- The same functionality is implemented elsewhere. One can close this issue and direct user to the appropriate place.
|
||||
- The reported issue is not currently planned or aligned with the project's goals.
|
||||
- If the issue appears to be spam and is clearly unrelated.
|
||||
- If the issue is related to an external limitation or dependency and is beyond the control of the project.
|
||||
|
||||
To close an issue, leave a `/close` comment on the issue.
|
||||
|
|
Loading…
Reference in New Issue