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.

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

RFC Process Update #300

Merged
merged 3 commits into from Nov 30, 2018

Conversation

Projects
None yet
@locks
Contributor

locks commented Feb 4, 2018

Rendered

@locks locks force-pushed the rfc-process-update branch from d2a5039 to 9df3b23 Feb 4, 2018

Show resolved Hide resolved text/0000-rfc-process-update.md Outdated
@Gaurav0

This comment has been minimized.

Contributor

Gaurav0 commented Feb 5, 2018

Thanks for this. I have one additional suggestion: a standard time period after which an FCP to close should be expected. Perhaps 6 months. The idea should be that RFCs should not be perceived to be treated differently based on author and all RFCs should have sufficient time for comment, no matter how unpopular.

@Gaurav0

This comment has been minimized.

Contributor

Gaurav0 commented Feb 5, 2018

One other concern: there should not be a rash of FCP to close immediately after this is accepted.

@joukevandermaas

This comment has been minimized.

joukevandermaas commented Feb 9, 2018

The part about assigning champions is not entirely clear to me. Does the RFC author seek out a champion? Or do they just submit the RFC and wait for one to assign themselves?

If the former, it may help to have some semi-standardized way of contacting core team members for this purpose (perhaps a slack channel). This should be mentioned somewhere in the repo so people know where to start.

If the latter, it may be a good idea to have some time-frame in which a decision is made and communicated (even if the decision is that no one has time to champion that RFC for now). My ballpark suggestion would be about 6 weeks after opening the RFC (so about one release cycle). I know time-frames are difficult to commit to, so maybe this is impossible.

@rwjblue

This comment has been minimized.

Member

rwjblue commented Jun 19, 2018

The part about assigning champions is not entirely clear to me. Does the RFC author seek out a champion? Or do they just submit the RFC and wait for one to assign themselves?

I think that in practice, interested team members are falling over themselves to champion ideas that they like and/or want to advance. I know that I do... But I think the answer here is actually "both". Advocating for the RFC both in its own comments, in #dev-rfcs in slack, on the forum, etc is likely the best way...

If the latter, it may be a good idea to have some time-frame in which a decision is made and communicated (even if the decision is that no one has time to champion that RFC for now). My ballpark suggestion would be about 6 weeks after opening the RFC (so about one release cycle). I know time-frames are difficult to commit to, so maybe this is impossible.

I'm not sure this is would work out well. I don't think we need more process just for process sake, all these rules are just one more thing that we have to maintain/adhere to/etc. However, I do agree that a nice default timeframe to FCP to close after not successfully engaging a champion is warranted (I believe that @Gaurav0 also suggested this).

@rwjblue

This comment has been minimized.

Member

rwjblue commented Oct 7, 2018

I'd love to see this move forward, @locks are you still planning on pushing this?

@mehulkar

This comment has been minimized.

mehulkar commented Oct 7, 2018

Is it possible to move ember-cli into the emberjs org as well? It's a core part of the Ember experience now and IMO if RFCs are merged, it should be located closer to the library also. IMO, many of the other repos on ember-cli could also be moved into github.com/emberjs or maybe github.com/emberjs-core-addons` or something similar.

@locks locks force-pushed the rfc-process-update branch 2 times, most recently from f5961c1 to 43eac1b Oct 25, 2018

@rwjblue

This comment has been minimized.

Member

rwjblue commented Oct 26, 2018

Is it possible to move ember-cli into the emberjs org as well?

Everything is possible 😈 but I don't personally think this would add much value. It is quite nice to have a grouping of packages that relate to "the CLI tool"...

@kategengler kategengler force-pushed the rfc-process-update branch from 70edc95 to ca7b6c5 Nov 4, 2018

@tylerturdenpants tylerturdenpants referenced this pull request Nov 7, 2018

Merged

The Ember Times - Issue No. 72 #3671

6 of 12 tasks complete
@ctcpip

This comment has been minimized.

ctcpip commented Nov 16, 2018

Each RFC will require a champion from the primary core team to which the RFC has been marked relevant. The champion must be found by the opener of the RFC or other community member.

So basically if a core member can't be convinced to champion, the RFC is dead in the water? This does not seem community-driven to me. It sounds like an oligarchy. I understand the motivation behind it, but it seems like it's taken a step too far.

@kategengler

This comment has been minimized.

Member

kategengler commented Nov 16, 2018

The Final Comment Period has now begun.

@MelSumner

This comment has been minimized.

Contributor

MelSumner commented Nov 16, 2018

Each RFC will require a champion from the primary core team to which the RFC has been marked relevant. The champion must be found by the opener of the RFC or other community member.

So basically if a core member can't be convinced to champion, the RFC is dead in the water? This does not seem community-driven to me. It sounds like an oligarchy. I understand the motivation behind it, but it seems like it's taken a step too far.

Maybe a few ways I can help with some perspective (@ctcpip):

  • core team members are community members
  • maybe try to figure out some data- has any initiative ever been "killed" because there wasn't a core team champion?
  • core team members as champions is more of a process thing-core team members are dedicated to helping Ember move forward.

Assume the best :)

@ctcpip

This comment has been minimized.

ctcpip commented Nov 16, 2018

@MelSumner -- I don't mean to be pedantic, but that section could use some work in terms of elaborating on how exactly the required champion manifests. Yes the core team is community, but is there any concern that as their numbers are limited, they may be reluctant to champion otherwise-worthy RFCs because they are already very busy? I may be interpreting the intent too strictly, but if so, I think that section could be given a bit more detail.

"A section on 'Finding a champion' will be added to the instructions on proposing an RFC."

Maybe that would have more specifics? The language just seems to be a bit discouraging to me and implies that without a champion, you may as well not submit an RFC. For example, in some projects, if you miss some teeny little instruction when submitting an issue, the maintainer will close it outright, even though it's a valid issue. I'm not saying that's analogous to what's happening here, but from an outsider looking in, it may look similar. As I understand it, this comes at a time when increasing community involvement has been a priority, so some sensitivity around something like this I think is warranted.

To put it another way, I'm not cynical about the intent of the RFC or of the folks proposing it. I'm concerned about the language (and maybe part of the process itself?) possibly discouraging contribution by implying (or seeming to imply) that this additional requirement be met before being heard.

@kategengler

This comment has been minimized.

Member

kategengler commented Nov 17, 2018

The Champion requirement has been in place on ember-cli/rfcs since early 2017. It was implemented to attempt to prevent RFCs from stagnating. It has served ember-cli well.

The current reality is that if an RFC does not have a core team member advocating for it -- making sure the core team(s) read it, ensuring all RFC comments are addressed, gathering consensus for FCP, for merging -- is that the RFC stays open and stagnates. That's not to say the core team doesn't pay attention to new RFCs (we certainly do), but that if an RFC doesn't entice someone on the team to push it forward, members may read it and forget it. The champion requirement makes this an explicit requirement and provides a guide for fulfilling it. It reflects that RFCs that are most likely to be accepted are ones for which the author "lobbies" -- by sharing ideas in discord, chatting on the forums, giving talks, writing, etc.

Mel is correct when she says "assume the best". While the numbers of core team members are limited, it is certainly not small: https://emberjs.com/team/ and in practice, team members will be excited to champion any RFC they think improves Ember. Getting a core team member on board to champion would be a reasonable metric to decide whether it is worth spending the time writing an RFC.

@Gaurav0

This comment has been minimized.

Contributor

Gaurav0 commented Nov 17, 2018

So basically if a core member can't be convinced to champion, the RFC is dead in the water? This does not seem community-driven to me. It sounds like an oligarchy. I understand the motivation behind it, but it seems like it's taken a step too far.

The final decision is in the hands of the core team anyway. The RFC Process is about soliciting community input, not creating some sort of democracy. At least Ember's core team is relatively large and comprises many different points of view, and they have proven that they generally don't ignore community needs.

@amyrlam amyrlam referenced this pull request Nov 26, 2018

Merged

The Ember Times - Issue No. 75 #3704

7 of 11 tasks complete

@kategengler kategengler merged commit 2df2eb4 into master Nov 30, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@kategengler kategengler deleted the rfc-process-update branch Nov 30, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment