honeymoose
/
angular-cn
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

docs: reword a few phrases in the GITHUB_PROCESS.md doc (#41977) 

Reword a few things in the explanation around our `Feature request process` to make
the process a little clearer.

PR Close #41977
This commit is contained in:
Joey Perrott 2021-05-06 17:24:03 -07:00 committed by Andrew Scott
parent 1be5d659a5
commit e29eb8abfb
1 changed files with 11 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
docs/GITHUB_PROCESS.md
View File

@ -1,6 +1,6 @@
<a name="conversation-locking"></a> <a name="conversation-locking"></a>
# Automatic conversation locking # Automatic conversation locking
Closed issues and pull requests are locked automatically after 30 days of inactivity. Closed issues and pull requests are locked automatically after 30 days of inactivity.
## I want to comment on a locked conversation, what should I do? ## I want to comment on a locked conversation, what should I do?
When an issue has been closed and inactive for over 30 days, the original context is likely outdated. When an issue has been closed and inactive for over 30 days, the original context is likely outdated.
@ -17,26 +17,27 @@ providing any of the additional information the team needs to investigate.
# Feature request process # Feature request process
To manage the requests we receive at scale, we introduced automation in our feature request To manage the requests we receive at scale, we introduced automation in our feature request
management process. After we triage a ticket and we identify it as a feature request, it goes management process. After we triage an issue and we identify it as a feature request, it goes
through several steps. through several steps.
## Manual review ## Manual review
First, we manually review to verify if it aligns with any of the existing roadmap efforts. If it First, we manually review the issue to see if it aligns with any of the existing roadmap efforts. If
does, we prioritize it. Alternatively, we keep it open and our feature request bot initiates a it does, we prioritize it accordingly. Alternatively, we keep it open and our feature request bot
voting process. initiates a voting process.
## Voting phase ## Voting phase
To include the community in the feature request process, we open voting for 60 days. Anyone can cast To include the community in the feature request process, we open voting for 60 days. Anyone can cast
a vote for the request with a thump-up (👍) reaction. If the feature request reaches 20 or more a vote for the request with a thumbs-up (👍) reaction. When a feature request reaches 20 or more
upvotes, we review it again manually. Alternatively, the bot closes the request. upvotes, we formally consider the feature request. Alternatively, the bot closes the request.
## Consideration phase ## Consideration phase
If the feature request receives 20 or more votes, we verify if we can afford to maintain it and If the feature request receives 20 or more votes, we verify the Angular team can afford to maintain
whether it aligns with the long-term vision of Angular. If the answers of both questions are yes, the feature and whether it aligns with the long-term vision of Angular. If the answers to both of
we prioritize the request, alternatively we close it. these questions are yes, we prioritize the request, alternatively we close it with an explanation of
our decision.
## Diagram ## Diagram