Fortifying the process against feature bloat

[Centril]

To expand upon @sfackler’s answer, rfcbot applies the label disposition-merge to PFCPs which are newer than those filed after 1st of May 2018. Thus, you can see all to-merge FCPs in the rust repo with: https://github.com/rust-lang/rust/issues?utf8=✓&q=is%3Aopen+label%3Adisposition-merge+-label%3Afinished-final-comment-period (is:open label:disposition-merge -label:finished-final-comment-period).

I’ve retroactively applied disposition-merge to all relevant RFCs and cleaned up final-comment-period so applying finished-final-comment-period retroactively as well.

[vorner]

This was talked about in another thread and my feel is it was thought to be a good idea in general (adding a section for „close to stabilization“ features). This is the RFC I’m trying to write, but I have to find some time to actually do it ‒ probably over the weekend. And I plan to propose something as lightweight as possible (I guess the „changing the process regarding stabilization“ sounds much bigger than what I have actually in mind).

Idea: mandate N independent uses before stabilizing a feature

You should write an RFC changing the process regarding stabilization. Depending on how broadly it applies, it would then be under the purview of the language team, the libs team, or maybe the core team. See the team structure for more info on the teams. See the README on the RFC repo for details on the process. @scottmcm is on the language team, so you’ve essentially already contacted the language team by writing here

To that end, it’d be helpful if you could enumerate what you think were the most eye-opening lessons here, and we can figure out where to document those.

For me, it wasn’t outright eye-opening, just pieces to the puzzle, but I’ll go through it and find what exactly it was, also over the weekend.

[glaebhoerl]

It would be kind of nice to have a list of current FCPs published somewhere. I find the “Current RFCs” section of TwiR really useful. Something similar for stabilizations would be great.

Everything else aside this is an excellent and in-hindsight-obvious idea and I’m honestly surprised that they aren’t already published in the same place, and that I hadn’t even consciously realized that they aren’t.

[Ixrec]

I’ve seen this suggested at least half a dozen times by now (I suggested it myself several months ago), and so far it seems like everyone has exactly the same purely positive reaction.

Does anyone know who we need to talk to to make TwiR actually implement this?

[vorner]

As mentioned 2 comments above here, I’m writing an RFC in that regard (as suggested in another thread) and I hope to submit it soon. I hope that will make it moving :-). In other words, I don’t know who to talk to yet, but I decided to find out and push it through (unless there appears some reason why it shouldn’t be done).

[djc]

This is really helpful feedback! It’s a perpetual difficulty with a project the size of Rust to “get the word out” about things (because there’s always so much happening), but I would love for the outcome of this thread to be a set of some concrete things we could communicate better.

To that end, it’d be helpful if you could enumerate what you think were the most eye-opening lessons here, and we can figure out where to document those.

I’ve really been feeling the lack of communication from teams to their audiences, in particular the “older” teams. From my point of view with a long history working in open source projects, it’s been surprising to me that teams mostly operate out of sight and while notes are sometimes available if you go look, these aren’t always very accessible.

In contrast, in many open source projects that I worked with over the past two decades, there was a policy that everything substantial has to find it’s way to asynchronous communication so that it’s more accessible and everyone has a chance to weigh in. From the start, the Rust project has been oriented towards somewhat-closed-by-default teams (mostly invite-only membership) with a lot of the core discussion happening in synchronous communication, which makes it that much harder to keep up with what’s going on.

(I hypothesize that this is part of the culture of the research group at Mozilla that Rust sprung from, and that maybe there aren’t a lot of more old-school open source types involved in the core Rust leadership group.)

It sounds fine if someone consistently takes back the key decision points from a meeting back to a thread on a more personal note, but that should really happen way more consistently. In my opinion, this is a significant factor holding back the larger Rust community (and makes it harder, to reference your Rust 2018 post, to elicit technical leadership).

Personally I would like to see if every team or working group post a bi-weekly or maybe monthly announcement of what’s going on, and for the team/wg leads to be accountable for that process. It doesn’t have to be a long and it can be liberal in just linking to whatever asynchronous material is already available, but it should be published and advertised (for example in TWiR).

[aturon]

there was a policy that everything substantial has to find it’s way to asynchronous communication so that it’s more accessible and everyone has a chance to weigh in.

FWIW, this has long been the policy in Rust. No RFC decisions are made in meetings, and all rationale must be discussed on thread, and given an opportunity for response, before a decisions is reached. The rfcbot tooling also formalizes this, since proposals to reach a decision must be made on thread, and each team member must mark their consent on thread.

a lot of the core discussion happening in synchronous communication

Personally I would like to see if every team or working group post a bi-weekly or maybe monthly announcement of what’s going on

Could you say more about what gives you this impression? Most meetings are “triage” oriented, getting a quick temperature from the team and taking some immediate action items back on the thread. Deeper dives receive detailed writeups on irlo (here’s one example).

We’ve done various newsletters in the past – and the domain WGs are doing a great job with that currently! – but for the “core” teams the idea is that TWiR should cover everything that’s “going on”. So again, I’d love to get more examples/insights into what you feel is missing!

[aturon]

In part inspired by this thread, I’ve just kicked off a new blog series focused on people/process issues from my personal vantage point.

[vorner]

I believe this deserves bigger thanks than just the symbol. I’m afraid I can’t really express it enough in words. As for myself, I’m afraid I was one of the more vocal people out there and I apologise for being such a pain at times. I know the full meaning of the famous „herding cats“ comparison of programmers, that you have a hard job ‒ especially when busy times come. I hope to be a better community member in the future and not let myself get carried away so often.

[djc]

FWIW, this has long been the policy in Rust. No RFC decisions are made in meetings, and all rationale must be discussed on thread, and given an opportunity for response, before a decisions is reached. The rfcbot tooling also formalizes this, since proposals to reach a decision must be made on thread, and each team member must mark their consent on thread.

I’ve found this pretty unsatisfying in practice. There is still a sense (as somewhat of an outsider) that there is some process happening inside those meetings that is inaccessible without being part of that meeting (which in turn is often only possible/appreciated/encouraged when you’re invited).

Could you say more about what gives you this impression? Most meetings are “triage” oriented, getting a quick temperature from the team and taking some immediate action items back on the thread. Deeper dives receive detailed writeups on irlo (here’s one example ).

We’ve done various newsletters in the past – and the domain WGs are doing a great job with that currently! – but for the “core” teams the idea is that TWiR should cover everything that’s “going on”. So again, I’d love to get more examples/insights into what you feel is missing!

What is missing is I think more thinking in public and transparency about what’s going on. While it seems that outcomes are often documented very well, a lot of the process used to get there seems to get stuck behind closed doors, meaning (a) it’s harder to follow along with the reasoning (even if you get to read the outcome of the reasoning), (b) it’s harder to participate because you don’t really get to understand the process that’s being followed.

There was an interested thread on mozilla’s governance mailing list this week about the concept of meritocracy:

https://groups.google.com/forum/#!topic/mozilla.governance/OQlS6-gUBLQ

The inimitable mhoye had a very strong response there: “A core function of a “meritocratic” system is to obscure the locus and nature of authority - to hide who makes the real decisions about what constitutes merit behind the idea of merit as an abstract idea.”

I think this describes very well how I feel about the Rust community today. It notionally functions as a meritocratic system, and that indeed (in my perception) has the effect of hiding the locus and nature of authority, which makes me distrust the process and worry about the future of the community. (Obviously lots of things are going well, too, especially on the more technical side.)

As for myself, I’m afraid I was one of the more vocal people out there and I apologise for being such a pain at times. I know the full meaning of the famous „herding cats“ comparison of programmers, that you have a hard job ‒ especially when busy times come. I hope to be a better community member in the future and not let myself get carried away so often.

FWIW, I’ve held back thoughts similar to the ones I have been expressing here because I did not feel that the community process was conducive to having this discussion, which has also made me feel like “one of the more vocal people out there” and actively trying to not “being such a pain”. Thank you for doing the better thing and being a pain.

(Also I want to mention that the way the appoint of Ashley to, I think it was community team lead, was handled for me was a pivotal point for feeling that constructive discussions about people topics were really hard to have in this community – just to be clear, this doesn’t have anything to do with Ashley or that role, but merely with the way the moderators/“authorities” handled that topic.)

[rvolgers]

I think a big part of the problem is visibility of information that already exists.

Regarding the RFC process, the RFCbot on github already collects a lot of information. There’s even a very bare bones dashboard showing the RFC’s in the Final Comment Period:

https://rfcbot.rs/

I think it’s keeping track of official “team member” responses such as https://github.com/rust-lang/rust/issues/47115#issuecomment-377608340 as well, if mostly by accident (such comments often contain an rfcbot command already). Such comments are present on many RFC’s, and I think that’s usually where the reasoning for the team taking certain steps is (or should be) explained.

Perhaps the dashboard could be extended to give a list of such “checkpoint” comments for each RFC. If team members ensure that “official” team responses are seen by rfcbot this could give a nice compact overview of the lifecycle of each RFC.

[aturon]

There is still a sense (as somewhat of an outsider) that there is some process happening inside those meetings that is inaccessible without being part of that meeting (which in turn is often only possible/appreciated/encouraged when you’re invited).

I see that sense, but I’m still left wondering: where does it come from? Everything goes through the RFC process, whether proposed by the team or not. You can see active arguments happening between lang team members on RFCs proposed by… lang team members!

What would be really helpful is to lay out specific, concrete examples.

What is missing is I think more thinking in public and transparency about what’s going on. While it seems that outcomes are often documented very well, a lot of the process used to get there seems to get stuck behind closed doors, meaning (a) it’s harder to follow along with the reasoning (even if you get to read the outcome of the reasoning), (b) it’s harder to participate because you don’t really get to understand the process that’s being followed.

Can you give some examples? It should be the case that everything is fully laid out on-thread before an FCP action is proposed – and those proposals either include, or link to, summary comments. Just to pick a random example, you can see the process at work here, where I voiced personal comfort with bringing the RFC up for review with the whole team, which then led to quite a bit of subsequent discussion.

I think this describes very well how I feel about the Rust community today. It notionally functions as a meritocratic system, and that indeed (in my perception) has the effect of hiding the locus and nature of authority, which makes me distrust the process and worry about the future of the community.

I don’t really understand what you mean by this. We’ve never described it as a “meritocratic” system, and in particular, we’ve worked hard to document:

• The decision-making process
• The decision-makers

What do you feel is hidden?

[aturon]

Perhaps the dashboard could be extended to give a list of such “checkpoint” comments for each RFC. If team members ensure that “official” team responses are seen by rfcbot this could give a nice compact overview of the lifecycle of each RFC.

Note that the dashboard at the moment is intended to help team members keep up with their review duties. But there are at least two visibility improvements in the works:

• Making sure that stabilization FCPs show up in “This Week in Rust”, making it the single place you need to look to keep up with process milestones

• Making rfcbot post a first comment on each RFC PR, then update that as the discussion goes through various milestones – making it easy to tell at a glance where things are.

[Centril]

• Making rfcbot post a first comment on each RFC PR, then update that as the discussion goes through various milestones – making it easy to tell at a glance where things are.

Just to let everyone know, I intend to implement this, just haven’t had the time yet

[vorner]

OK, getting to the specific „revelations“ asked for, as going through the thread:

• The FAQ can work as an effective place for very prominent „no-features“. In hindsight, that seems obvious, but it didn’t cross my mind.
• Predicting the future direction of Rust based on immature ideas posted on this forum may lead to depressions, not truth.
• Rejected/closed proposals work as a lightweight implicit version of negative RFC. I didn’t assume someone would copy-paste some closed proposal vanilla, but I assumed a very similar one would still go through FCP/closed process at least. The readme speaks about „rejected quickly“, but doesn’t go into much details about what it is.
• While it makes sense to have some notion of „feature smaller than RFC“, the docs say that pretty much every change goes through RFC. The fact that the grammar may change without one and that there’s actually a policy for that is a bit of a surprise.

The later two points seem to hint at having some amount of unwritten rules or folklore team knowledge. I know it’s hard to fight this, it happens everywhere. But while in a corporation, there’s usually few of newcomers so the knowledge is easy to transfer in a verbal way, doing that from a team of few members to many-hundred headed community hydra just doesn’t scale (it might have scaled in the past, but the community is too large a crowd now). I guess it’s inevitable something becomes a folklore without anybody noticing. But it would be great if you tried to look for these things once in a while. I’d really like to read through it ‒ not only because of Rust, but there are just bound to be some clever things that might be generally useful ‒ be it policy guidelines, criteria by which you consider if an RFC is a good one or not and what you look for in it…

As for policies of what doesn’t need an RFC: I think this one is easy to watch for, whenever you decide „Oh, this doesn’t need an RFC“ and it is a new precedent, that is a good time to put it somewhere (like a special place for it). The lang_changes document could link to these, so it can be found. As an anecdotal prior-art: when starting the project I work on (unfortunately, in C++), we spent a long time of arguing about coding style ‒ if tabs or spaces, etc, the kind of stuff everyone feels they have something to say (btw, I believe rustfmt + official style is about as much time saver as cargo). The result was a document of the style. Whenever we discover something in review that we don’t agree on the style and find out it’s not covered, we make a decision and immediately add to the document.

I’m not sure if some of this could be outsourced to the community, so the teams can do more of the technical stuff than the social.

But I guess this one explains better the one example/area than I did:

One seems to be policies for specific types of changes.

[mark-i-m]

Some of these are documented in the various parts of https://github.com/rust-lang/rfcs#sub-team-specific-guidelines;

I didn’t know that existed… I don’t think it did when I first read the readme…

Does anyone know who we need to talk to to make TwiR actually implement this?

@nasa42 or @llogiq I think. I feel kind of bad just asking them to do more work though. They already do a lot of work. If I get time this week I’ll try to write something up for next week.

[PieterPenninckx]

No RFC decisions are made in meetings, and all rationale must be discussed on thread, and given an opportunity for response, before a decisions is reached.

Maybe the wording used in the meetings is more convincing than the wording used in the thread (despite the efforts of the person commenting in the thread), leaving the people who were in the meeting with a different sentiment. This may seem a minor thing, but I remember that when I was teaching, certain words would make it “click” for the students, while other attempts to explain did not work at all.

I don’t know how this can be solved, though. Posting a verbatim transcription of the meeting on the thread comes to my mind quickly, but is probably unpractical or noisy. (Also, the convincing part may be in the noise, so …)

Thanks for working on this. I hope my input helps.

[pickfire]

It is not possible to remove some features with the editions mechanism. With the others, while not tried yet, I have a feeling removing a feature once in the language would prove much harder than getting it in. So in general, most features are going to stay in once they get there. But even if we took only the features that are not possible to remove, it would still be a limitation.

Maybe it might be useful if there is a section for “rolling back” in positive RFCs. Just in case that there is a RFC to revert the feature. The possible target are the RFC that introduces syntatic sugar.

• Pros: A backdoor to remove the RFC, this could greatly reduce the cluttered featured but some ideas is needed to port the changes to crates (rustfix?)
• Cons: Made people pessimistic on implementing the RFC and might change some parts of the RFC where the ability to remove the feature is a constraint

[djc]

So I’ve been thinking very long about this, and I think the main point of difference is that I wasn’t really talking about the RFC process as much (which might make this discussion off-topic for this thread), but more about the community process: how teams and working groups are set up, who is appointed to be a leader or member of them, who are on the core team, what do they contribute to the core team and how visible are they in the community, how much authority do you have as a core team lead and how is your authority legitimized, how much happens in one-on-ones that you have for management reasons rather than community reasons (I think withoutboats wrote somewhere about what kind of things he discussed with you).

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.