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).
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!
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.
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).
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:
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.)
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.)
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:
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.
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.
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 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:
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.
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:
I didn't know that existed... I don't think it did when I first read the readme...
@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.
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.
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
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).
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.