Limit on number of concurrent FCPs

[retep998]

Most people have lives outside of Rust and only have a limited amount of time each week to dedicate to reading RFCs and commenting. Even when someone does have plenty of time, they can still get burnt out focusing on just a few really lively RFCs. When a whole truckload of RFCs are shoved through FCP at the same time, people end up only being able to pay attention to some of them, while other RFCs slip by unnoticed. The current situation is borderline ridiculous:

Rust is not currently lacking in things to implement or stabilize (we have 277 open tracking issues!), so perhaps it might be wise to limit the number of RFCs that can be in FCP at a given time. We should instead strive to have a slow continuous stream of RFCs so there is always something to comment on, but not so much that people are inundated.

And no, having an "impl period" where you don't merge RFCs and instead focus on implementation is not a valid excuse for cramming as many RFCs into FCP in preparation for that "impl period".

[est31]

I'm not sure whether I agree or not.

At one hand, its the whole point of the RFC process to expose proposals to public scrutiny and to get feedback and feelings about proposals. Merging a large bunch of RFCs at once like done now is harming that purpose. I'm not sure as back then I wasn't around, but I could guess there was a similarly high number of RFC mergers ahead of the 1.0 release. This was sort of justified because it was an one-time thing, but I don't think its a good habit to repeat that in the future.

At the other hand, some proposals got a lot of public scrutiny well before the RFC was opened, like the modules proposal. Many were certainly well managed (want to thank @aturon in particular for listening to every single critic!), and very transparent. And about many RFCs there isn't too much to discuss...
Lastly, I have the impression that most RFCs got a ton of comments despite of so many proposals in parallel. I guess many people in the Rust community shifted from writing crates and other stuff to discussing the language (not sure whether that's a good thing or not).

[SimonSapin]

I agree this is a problem. There are multiple proposals at the moment that I care a lot about one way or another, but that I’ve burnt out of following closely.

As discussed in https://internals.rust-lang.org/t/announcing-the-impl-period-sep-18-dec-17/5676/8, I think this is a direct and natural consequence of announcing the "impl period". When you tell people that any proposal needs to "make it" by a certain date (or be subject to several months of delay), they feel a pressure to rush everything in at the same time.

This is exactly the problem that the rapid release schedule is designed to solve, except higher up in the "pipeline" (in design discussions rather than in landing code).

This effect is amplified by the Ergonomics Initiative ramping up around the same time, and producing RFCs that are not only numerous but also high-impact, and so naturally generating many comments. (These are good discussions to have, but the timing isn’t great.)

[pythoneer]

I highly resonate with the things previous comments are targeting. Coincidentally i read a hole lot more RFC's in the past few weeks than i usually did, just because i have plenty of time currently. So i am pretty much aware of the things that are happening and because of that i am not to worried about the current incident of the RFC/FCP "pileup" because they all look quite healthy for what i can tell. But this is really an exception because i don't know how i would feel about it if i had not so much time and would inevitably loos track of whats happening.

In my opinion this is a problem by itself and not because the current "pileup" turns out to be unhealthy for the development of the current RFCs – but it "could" in the future. Maybe its just me but this has the potential to turn out bad in the future – not that there is evidence currently its just a gut feeling that we can loose plenty of people in this process. And as SimonSapin already mentioned the "release often" and not heading towards a release date (beginning of impl period) felt really good in the past two years.

Not that i am against impl period or the current amount of FCPs its just something that i would like to discuss and having in mind for the future.

[nikomatsakis]

My personal take is that we need to make some "reforms" to the RFC system, but capping the number of concurrent RFCs is not where I would start. I see it as a symptom. Many of the problems that @aturon identified in this blog post are still relevant, for one thing. For another, I think there's been an increasing recognition of the fact that the RFC process as we have it now strongly encourages a "waterfall" or "design-first" style of development -- no surprise, since this was a goal when we first started it! (In particular, we were often doing too little design then.)

I would prefer to move towards a more "incremental" path, where we have a pool of ideas we may want to elaborate into final designs, and when we "accept an RFC" that is more like "beginning investigation". The RFC would then develop concurrently with the implementation and with live experimentation, with various "checkins" and "approval points" along the way. I think that would help to keep discussions on point -- and there is no substitute, when trying to evaluate a design, for having a working prototype.

In principle, this is not far off from the current system. That is, it's worth keeping in mind that accepting an RFC is only the first step towards stabilization: at that point, the implementation work begins, and discussion can continue on the tracking issue or elsewhere. Stabilization is the point where Things Get Real. (This is also a reason not to panic if you see a lot of ongoing FCP discussions -- still plenty of time to raise concerns.)

In practice, though, we tend to treat the RFC as far more final (for better and worse). In any case, maybe I'm just advocating for more extensive use of the eRFC-style approach, though I think we can do better than that. Done right, I think we can also use a revised process as a good springboard for helping people figure out how to get involved. Have to think on the details here some more.

[mark-i-m]

@nikomatsakis I agree with what you said, but I think it misses a bigger issue: fatigue. While I would like to follow and contribute to RFCs, I simply can't read dozens of comments a day from a multiple high-velocity FCP-ed RFCs (there are currently 7 RFCs in FCP with >140 comments each!), and still have meaningful input to give back. At some point I simply skim the github emails or ignore...

[Ixrec]

I apologize in advance for the wall of text, but I think any response shorter than this wouldn't do all of the issues justice.

On Fatigue

I'm not fatigued by the number of RFCs. A lot of the RFCs currently in FCP are very small, uncontroversial changes that take a matter of minutes to digest. While I do think there are "too many" in FCP right now, I agree that the number is a symptom and by itself not a serious problem.

What I am personally fatigued by are a handful of specific RFCs. Namely, the paths and visibility RFC, the in-band lifetimes RFC, and the rand crate revision RFC. And it's not because of the length of the discussion. I think it's because the total complexity of all the points that are still "up in the air" is so high that I just can't keep it all in my head without spending more time than I'm personally willing to invest in being a part of those discussions. In particular, I was following the last few modules RFCs pretty closely despite their length, because those discussions were clearly and obviously making progress. I generally had a handle on what the major remaining controversies were, so when each one got closed and replaced by a new proposal, the content of that new proposal was completely unsurprising and obviously the right direction to go in.

For whatever reason, with these three RFCs it feels like the point of controversy is still "every word in the RFC" despite the weeks of discussion so far, and that's just too much disagreement for me to intellectually follow or stay invested in. I feel like to participate in any of those discussions I'd have to reread the entire thread and summarize all of it just to decide which points I want to comment on, because otherwise I'd probably accidentally ignore a half dozen sub-controversies that make my whole comment irrelevant or unpersuasive. For most of the other RFCs "in flight", I can just read the current version of the RFC itself and the last several comments, and I'll immediately be in a position to start writing if I have anything to say (like I did over here) without feeling like I'm about to waste everyone's time including my own.

Note that I keep saying "feels" because I strongly suspect these feelings are not actually true, and those discussions are going somewhere despite my inability to follow them, and if I did make a conscious effort to properly reevaluate those discussions I'd end up with a totally different feeling (it certainly wouldn't be the first time). But I completely lack the desire to do that right now, and I suspect many other people do as well because most of the recent discussion on those three RFCs seem to be dominated by the same handful of users (which is probably fine for the rand crate RFC, but for the other two I find that somewhat worrying).

So I suspect the fatigue problem is not just about having this many RFCs at the same time, but about having this many RFCs and multiple highly controversial RFCs at the same time. If it was just 10-15 "easy" RFCs in the FCP list, I doubt we'd be having this conversation.

So, why do we have this many FCPs?

Similar to the last section, I think the popular suggestion that "it's the impl period's fault" is part of the answer, but not the whole answer.

First, I want to emphasize that I believe the epochs debate is a major contributing factor to all of this, and it's almost certainly a one-off controversy that we aren't likely to have an analogue for next year or the year after. That subject required at least the epochs RFC, the dyn Trait RFC, and the various modules RFCs to be happening at the same time, because those discussions overlap far too much to reach the optimal consensus on any of them in isolation. None of those were easy discussions, but they had to happen, and they had to happen this year, and we do appear to have more or less reached a conclusion on how epochs should work and what the guidelines for epochal changes should be, so I don't think we're going to get anything quite like that again for a long while. For that reason, I think it's unlikely we'll get an FCP pileup quite this bad ever again even if we don't take any corrective action.

But it definitely didn't require this many RFCs to happen in tandem. My suspicion ever since this issue got opened is that a lot of the RFCs currently in FCP simply could and should have happened much earlier in the year. Let me try and substantiate that by breaking the FCP list into groups:

RFCs currently in FCP that probably needed to happen concurrently with the Great Epochs Debate of 2017:

• Evolving Rust through Epochs (proposed Jul 3)
• Clarify and streamline paths and visibility (proposed Aug 25)
• In-band lifetime bindings (proposed Aug 28; the current draft doesn't use epochs, but I believe earlier drafts did)
• Add impl Trait type alias and variable declarations (proposed Jul 20; while not directly relevant to epochs, the impl Trait and dyn Trait syntax disussions had a lot of overlap, and rightly so)

"Large" RFCs (>50 comments) currently in FCP that theoretically could have been proposed earlier in the year:

• Ok wrapping: Improved support for writing code from an error handling mindset (proposed Aug 14)
• Add the () → Result<(), _> coercion rule, for removing Ok(()) everywhere (proposd Aug 21)
• Autoreferencing Copy Types (proposed Aug 16)

"Large" RFCs (>50 comments) currently in FCP that were proposed earlier in this year, and theoretically could have been FCP'd earlier:

• Const generics (propoed May 11, discussion stopped Jun 28, no further comments until a friendly ping on Aug 8)
• Const/static type annotation elision (proposed May 29, discussion stopped Jul 13, remained dormant for a month until schuster's Aug 13 data gathering comment)

"Large" RFCs (>50 comments) currently in FCP that were proposed earlier in the year, but the discussion took long enough that they probably couldn't have been FCP'd earlier:

• Add align_offset intrinsic and [T]::align_to function. (proposed Jun 26, discussion stopped on Aug 3, but restarted on Aug 20)
• Add external doc attribute to rustc (proposed May 4, discussion stopped Jul 25, FCP proposed Aug 9, FCP entered Aug 15)

"Small" RFCs (<50 comments) currently in FCP that theoretically could have been proposed and/or FCP'd earlier:

• Nested groups in imports (proposed Aug 25)
• Attributes for tools, 2.0 (proposed Aug 11)
• Infer T: 'x outlives requirements on structs (proposed Aug 2)
• Implied bounds (proposed Jul 28)
• Allow Irrefutable Patterns in if-let and while-let statements (proposed Jul 27)
• stable mechanism to specify the behavior of panic! in no-std applications (proposed Jul 20)
• Allow crates to specify the version of Rust in which they are written (proposed Aug 9)
• Copy/Clone Closures (proposed Aug 28)
• compiler-generated Clone impls for Arrays and Tuples (proposed Aug 28)

After looking up all of these dates, the only clear trend I see is that too many RFCs were proposed in August and late July, and the number of FCPs we have right now is an inevitable consequence of that. To some extent this is random chance and not something a process improvement can ever prevent, but a large portion of the "late" proposals were part of the ergonomics initiative and came directly from the lang team, and I don't really recall any "official ergonomics RFCs" getting posted prior to July.

So I believe the reason we ended up in this situation is a combination of the impl period announcement and the ergonomics initiative posting most of its "official" RFCs concurrently. If it wasn't for the impl period, we could naturally correct for this ergonomics RFCs spike by simply putting off some RFCs or some FCPs for a few weeks. But I don't think the impl period by itself explains why so few of these RFCs were proposed earlier in the year. I can't really speculate on why that happened since I'm not part of the lang team, but I think that's something that needs to improve if we want to keep doing impl periods in future years (which I do, see next section).

On eRFCs, "waterfalls" and "limbo"

Recently, there have been a number of comments that our RFC process has become "too waterfall". eRFCs are typically suggested as part of the solution. I definitely agree with this sentiment and for certain specific RFCs I think it's an accurate diagnosis. In particular, this comment by woboats is the biggest truth bomb I've seen in a while.

But, as you may have already guessed, I don't think that's the whole problem. I think waterfall-ness is only a problem with some of our most complex and controversial RFCs. I don't think it's a systematic problem with the RFC process as a whole.

Something I've never really gotten around to expressing before is that, in my opinion, the systematic problem we actually have is that there are too many ideas and features stuck "in limbo". That's an extremely high-level claim that goes way beyond the RFC process, so bear with me for a minute while I unpack what I mean by that.

We have a lot of nightly-only features that are not yet stabilized. A lot of them have no clear path to stabilization. A lot of RFCs have been accepted and never implemented. Some accepted RFCs can't be fully implemented and a lot of nightly-only features can't be stabilized because of other seemingly tangential features (typically what I like to call the "core megafeatures") that have not been RFC'd, implemented and/or stabilized yet, or because of major compiler refactors that can't be easily tracked. There doesn't appear to be any attempt to tag or categorize these unshipped features by what if anything they're blocked on, so in general it's hard to tell why a feature hasn't shipped yet or what you can do to get it closer to shipping. There are also ideas (like CTFE) that, if I understand correctly, can't even be RFC'd until some major compiler refactors (like miri) land and get some time to settle.

This problem is very hard to quantify, and it'll never completely go away unless the language stagnates, although this problem quickly becomes its own kind of stagnation if it grows unchecked. I personally believe we've been designing new features faster than we've been shipping them, and the backlog is getting big enough and interdependent enough that we need to consciously spend less time proposing and designing new features and more time "breaking the logjam" to let us ship more of those features we've already designed, proposed, and mostly-but-not-quite-completely implemented. This is why I find the idea of an impl period exciting, refreshing and something I want to see every year if it goes well; it sounds like a clear acknowledgment of this problem and a serious commitment to both fixing it and keeping it more or less fixed long-term.

This is why the idea that eRFCs are part of the solution to "the RFC process" as a whole, rather than a handful of specific RFCs, strikes me as deeply worrying. Just as there's a limit to how many FCPs we can expect a "casual" Rust user to process, there's a limit to how many experimental nightly-only features we can have going on at once and still expect to get enough quality feedback to keep them all moving towards stabilization. If eRFCs become too commonplace, I fear that's merely going to increase the number of features stuck in limbo.

To be clear, that doesn't mean I think we should stop proposing major new features entirely, or stop using eRFCs (or "experimental acceptance" or whatever we turn it into) entirely. Part of the reason the roadmap was such a great idea is that it gave us a clear list of things that we've more or less agreed are important enough to the Rust project that they do justify major new features, and some of those major new features (like procedural macros and async/await) really need experimentation on nightly. But we should avoid major new features that don't strongly contribute to the roadmap, and we absolutely need to avoid the roadmap-motivated features getting stuck in limbo themselves. That's why I think next year we need to focus less on new RFCs and more on pushing the existing RFCs the rest of the way to stabilization.

Conclusion?

So in the grand scheme of things, I think this FCP pileup is not only a symptom of too many RFCs, but that too many RFCs is itself partially a symptom of the real problem that we're designing more features than we're shipping, and we need to shift that focus more than we need to come up with process improvements to avoid future pileups. We should try to improve whatever process led to the ergonomics initiative happening all at once, but I have no way of knowing what that was much less how to solve it.

One small but concrete idea I had while writing this out: I think part of the reason people see RFCs as "the end" of a feature's design and eRFCs feel like a partial solution to that is that RFC FCPs are far more widely advertized than stabilization FCPs. Maybe This Week In Rust should have a section for stabilization FCPs, not just the stabilization PRs that get merged after the decision has already been made?

[aturon]

Just a quick note on this: a big chunk of the RFCs reached the end of FCP. I have merged/closed (as appropriate) all of the non-controversial cases, but plan to leave others open for further discussion.

[Centril]

Triage: @retep998 any plans on taking this to the RFC stage?