Update the RFC process with sub-teams, amongst other things.

[nrc]

The libs section was authored by @Gankro, see #1213 and this discuss thread for previous discussion.

We're currently missing guideline for the tools sub-team. I just didn't have anything to hand, hopefully we can remedy that in a followup PR.

[eddyb]

Aww.

[nikomatsakis]

lgtm

[aturon]

by the end of the FCP, the decision on whether or not to accept the RFC should be obvious from the RFC discussion thread.

That seems a bit strong -- there have been and will be cases where there isn't an on-thread consensus, but the arguments on both sides have been exhausted and we just need to make a decision.

[aturon]

On the libs team at least, we haven't been great at re-iterating the rationale in a separate comment, usually because we have been good about commenting on thread. Not sure if we want to keep this requirement.

[aturon]

The implementation of new language features where there is significant change or addition to the compiler

This seems pretty broad -- is the intent that most language features will require two RFCs (lang and compiler)?

[aturon]

(I guess the question is: what is a "significant change or addition"?)

[nrc]

Yes, the intention is that most significant language features have two RFCs. Not sure how that will play out in practice, but it seemed popular amongst the compiler team when we were forming the teams up. I'll add some examples to the text.

[aturon]

This is one of the motivations for RFCs, but not the only one: actually spelling out and motivating a significant design and its implications is really useful, as is the broad discussion RFCs tend to produce. In short: RFCs often make for better designs.

[aturon]

I like the idea of an FCP that lasts for a whole cycle (after all, stabilization doesn't matter until the cycle ends, anyway), but am unclear on the logistics here.

One plausible, slightly less conservative approach:

• Every time a release cycle ends, the libs teams assesses the current unstable APIs and selects some number of them for potential stabilization during the next cycle. These are announced for FCP at the beginning of the cycle, and (possibly) stabilized just before the beta is cut.

The main change here is eliminating the full cycle prior to FCP, which in practice is going to be hard to track at the feature granularity. Whereas holding a big meeting at the start and end of each cycle to determine Which APIs Will Live Be Promoted seems pretty doable.

(In principle the core team is supposed to r+ stabilizations, but in practice it's been driven by subteams and the FCP is a good enough venue for core team member visibility and potential veto.)

@rust-lang/libs Thoughts on this?

[Gankro]

Sounds good to me -- though meeting deadlines is not our forte, historically speaking.

[alexcrichton]

This sounds pretty ok, I'd only worry about what this means for our large number of existing unstable APIs in terms of timing. If we had to select a small set every 6 weeks we might never actually get through the whole backlog!

At least for the first few releases we're going to have to make sure that the rate at which we process unstable APIs is higher than the rate they're coming in.

[aturon]

@Gankro

Sounds good to me -- though meeting deadlines is not our forte, historically speaking.

I'm not sure what you have in mind here, but in any case I think the change I'm proposing will make it a lot easier to track/manage these details:

• Week before release: Go/no-go meeting for items under FCP
• Week of release: 🎊
• Week after release: Triage for next cycle's stabilization FCP

@alexcrichton Note that I said "some number" not a "small number" ;-)

It's true that we have a backlog at the moment, and I think it's probably fair to grandfather in our existing unstable APIs which have been shipping since 1.0. Still, the main point here is that there's no reason for a stabilization FCP to be a single-week thing; it may as well last until the end of the cycle.

(On a separate note: I'd like to make progress this week moving forward on our remaining unstable APIs, and as part of that perhaps we can propose a bulk stabilization for this cycle.)

[aturon]

@nrc Looks good! I left a few, mostly minor, questions/nits.

[steveklabnik]

random whitespace

[steveklabnik]

extra \n here

[steveklabnik]

extra \n.

[nrc]

2 line breaks between sections == easier reading

[nrc]

Comments addressed.

Not sure which team this falls under. In any case, @nikomatsakis or @aturon can we FCP this?

[nikomatsakis]

Hear ye, hear ye. This RFC is entering final comment period.

[alexcrichton]

This libs team discussed this during triage today and the conclusion was 👍, yay!

[nikomatsakis]

Let's merge this thing!

[nikomatsakis]

To make that clearer, language design team is also on board, though it's not clear whose "jurisdiction" this falls under, precisely.