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

Introduce "final comment period" into process description #149

Merged
merged 1 commit into from
Jun 29, 2016
Merged

Introduce "final comment period" into process description #149

Changes from all commits
Commits
Show all changes
1 commit
Select commit
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
18 changes: 15 additions & 3 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -67,9 +67,21 @@ to revise it in response.
* 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.
* Eventually, somebody on the [core team] will either accept the RFC by
merging the pull request and assigning the RFC a number, at which point
the RFC is 'active', or reject it by closing the pull request.
* Eventually, the [core team] will decide whether the RFC is a candidate
Copy link
Member

Choose a reason for hiding this comment

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

@dgeb I thought this was supposed to be the subteam that puts an RFC into FCP, then the core team have seven days to respond. The intent is that the subteams can iterate on RFCs and FCP is when core should look up and be aware of what is happening.

Copy link
Member

Choose a reason for hiding this comment

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

We discussed at the core team meeting that the details of how subteams work hasn't yet been through the RFC process, and therefore we can't yet make them a formal part of the process. That's coming soon, though.

for inclusion in Ember.
* RFCs that are candidates for inclusion in Ember will enter a "final comment
period" lasting 7 days. The beginning of this period will be signaled with a
comment and tag on the RFC's pull request. Furthermore,
[Ember's official Twitter account](https://twitter.com/emberjs) will post a
tweet about the RFC to attract the community's attention.
* An RFC can be modified based upon feedback from the [core team] and community.
Significant modifications may trigger a new final comment period.
* An RFC may be rejected by the [core team] after public discussion has settled
and comments have been made summarizing the rationale for rejection. A member of
the [core team] should then close the RFC's associated pull request.
* An RFC may be accepted at the close of its final comment period. A [core team]
member will merge the RFC's associated pull request, at which point the RFC will
become 'active'.

## The RFC life-cycle

Expand Down