Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Clarify when an RFC can be merged #8

Merged
merged 7 commits into from
Jan 29, 2019
Merged

Docs: Clarify when an RFC can be merged #8

Changes from 3 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
4e983a9
Docs: Clarify when an RFC can be merged
nzakas Jan 7, 2019
afcb628
Updated proposal
nzakas Jan 14, 2019
82525c2
Add clarifications about commenting periods
nzakas Jan 15, 2019
5610da5
Fix typo
nzakas Jan 16, 2019
5ab5b44
Update initial commenting period
nzakas Jan 20, 2019
aaef578
More edits
nzakas Jan 25, 2019
043282b
Fix typo
nzakas Jan 28, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 10 additions & 4 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -41,12 +41,18 @@ To submit a new RFC, follow these steps:
1. Copy the appropriate template file from the `templates` directory into the appropriate `designs` subdirectory (such as `designs/2018-typescript-support/README.md`). Be sure to name your file `README.md` so it is easily viewable in the GitHub interface.
1. If you want to include images in your RFC, place them in the same directory as the `README.md`.
1. Fill in the RFC. Please fill in every section in the template with as much detail as possible.
1. Submit a pull request to this repo with all of your files.
1. You will receive feedback both from the ESLint community and from the ESLint team. You should be prepared to update your RFC based on this feedback. The goal is to build consensus on the best way to implement the suggested change.
1. When all feedback has been incorporated, the ESLint TSC will determine whether or not to accept the RFC.
1. Submit a pull request to this repo with all of your files. This begins the approval process (detailed below).
1. RFCs that are accepted will be merged directly into this repo; RFCs that are not accepted will have their pull requests closed without merging.

## The RFC life-cycle
## The RFC Approval Process

When an RFC is submitted, it goes throw the following process:
nzakas marked this conversation as resolved.
Show resolved Hide resolved

1. **Initial commenting period (21 days)** - the community and ESLint team are invited to provide feedback on the proposal. During this period, you should expect to update your RFC based on the feedback provided. Very few RFCs are ready for approval without edits, so this period is important for fine-tuning ideas and build consensus. (A PR in the initial commenting period has the **Initial Commenting** label applied.) The initial commenting period may be extended with a TSC vote if the RFC has been unable to reach consensus but the team believes it worthwhile to continue developing the RFC. The TSC may also decide to abandon an RFC that has failed to reach consensus after 21 days.
nzakas marked this conversation as resolved.
Show resolved Hide resolved
1. **Final commenting period (7 days)** - when all feedback has been addressed, the pull request enters the final commenting period where ESLint TSC members provide their final feedback and either approve of the pull request or state their disagreement. (A PR in the final commenting period has the **Final Commenting** label applied.) ESLint TSC members are notified through GitHub when an RFC has passed into the final commenting period.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Who decides when a PR should enter final commenting period? Is it up to the PR author? (It's good that we're providing general criteria like "when all feedback has been addressed", but presumably someone would need to judge whether those criteria have been met for a particular RFC.)

I think leaving it up to the PR author would work reasonably well. Although an author could prematurely try to move their RFC to the final commenting period before feedback has been adequately addressed, this would likely result in objections during the final comment period. As a downside, RFC authors who are not on the TSC would probably need to notify a TSC member or trigger a bot to move into final commenting period, and they might not realize they need to take this additional step.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree. I think allowing the PR author to request the final commenting period makes sense. My thoughts:

  1. I think we can trust TSC members to apply the "Final Commenting" label when they believe it's time.
  2. For non-TSC members, it seems like it should be good enough to have one TSC member review the RFC to ensure it's ready and apply the label.

(Trying to avoid a vote for every part of the process.)

1. **Approval and Merge** - if consensus has been reached on approving the RFC, the pull request will be merged. If consensus is not reached on the pull request then the RFC will be discussed at the next TSC meeting to determine whether or not to move forward.
nzakas marked this conversation as resolved.
Show resolved Hide resolved

## The RFC Lifecycle

Once an RFC is merged into this repo, then the authors may implement it and submit a pull request to the appropriate ESLint repo without opening an issue. Note that the implementation still needs to be reviewed separate from the RFC, so you should expect more feedback and iteration.

Expand Down