Update process #1
Conversation
README.md
Outdated
| @@ -38,16 +38,18 @@ In short, to get a major feature added, one usually first gets the RFC merged in | |||
| 1. Submit a pull request. As a pull request the RFC will receive design feedback from the larger community, and the author should be prepared to revise it in response. | |||
| 1. Build consensus and integrate feedback. RFCs that have broad support are much more likely to make progress than those that don't receive any comments. | |||
| 1. Eventually, the team will decide whether the RFC is a candidate for inclusion. | |||
| 1. RFCs that are candidates for inclusion will enter a "final comment period" lasting 3 calendar days. The beginning of this period will be signaled with a comment and tag on the RFCs pull request. | |||
| 1. RFCs that are candidates for inclusion will enter a "final comment period" lasting one week. The beginning of this period will be signaled with a comment and tag on the RFCs pull request. Upon request of a Babel core team member, this period can be extended by one additional week. | |||
There was a problem hiding this comment.
This 3 days period was copied from React's RFC process. However, React's community is more active than ours, so it makes sense for us to have a longer period.
Upon request of a Babel core team member, this period can be extended by one additional week.
This is in case someone makes a point against the RFC during this final period that initially doesn't convince us enough to discard our approvals, but that is still worth investigating.
| We try to make sure that any RFC that we accept is accepted at a team meeting. Every accepted feature should have a core team champion, who will represent the feature and its progress. | ||
| We try to make sure that any RFC that we accept is discussed at a team meeting. Every accepted feature should have a core team champion, who will represent the feature and its progress. | ||
|
|
||
| An RFC is considered as accepted if it receives at least 4 approving reviews, and no rejection from core team members. If the RFC is proposed by a core team member, this number is lowered to 3. |
There was a problem hiding this comment.
Currently, we have a 2-:heavy_check_mark: rule for PRs regardless of who opens the PR.
I think that we should have a higher number here since RFCs are bigger and have more impact. I chose 4 because we are more than 4 in the team, and thus it will make it possible for someone us to "abstain" in case we don't fully agree with the RFC but we don't feel like blocking it.
If the number of active team members decreases, we might need to change this
threshold.
Co-Authored-By: Brian Ng <bng412@gmail.com>
I will leave inline comments explaining the changes.