RFC Process Update

[locks]

Rendered

[Gaurav0]

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]

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

[joukevandermaas]

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]

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]

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

[mehulkar]

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.

[rwjblue]

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"...

[ctcpip]

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]

The Final Comment Period has now begun.

[MelSumner]

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]

@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]

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]

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.

[mehulkar]

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"...

Some counter points:

• Considering that it’s basically impossible to use Ember without CLI (no mention in guides), I think the value add is that users don’t need to hunt down another org.
• The website is merged, the RFCs are merged, it seems weird for the code not to live in the same place.
• GH org’s repo search and tags are a pretty decent way to organize / find repos, IMO.
• in the (very) long term, I expect that much of ember tooling will converge with non-ember tooling, so the need for supporting CLI packages will go down.

But that said, I haven’t vetted all the repos in ember-CLI yet so it’s possible I’m missing something.