HackMDLang / Compiler: Understanding and improving collaboration
Notes are deliberately high-level and quotes unattributed to encourage more comfortable discussion.
- Want to get a common understanding of how people are feeling and what the symptoms and root causes might be.
- Listening to experiences, experiences are presumptively valid.
- Trying to focus on experiences and listening, rather than jumping into solution space. OK to bring up potential solutions, just don't over-rotate on them.
Cargo namespaces RFC 3243, lots of data in the github thread, would be nice if we could figure out issues on the implementation/compiler side of it during the RFC process. Know it isn't always possible but it'd be nice if we could do more of it.
Compiler team cannot cover all the RFCs, and start implementation and evaluate, would need to speculatively work on all the things.
Lang might speculatively accept RFCs, and compiler would have feedback later on implementation/feasibility.
Some challenges in name resolution.
Certainly possible to implement, but it's new logic in the resolver that doesn't already exist. It's complicated. "Not sure if the complication is justified by the motivation."
Can be frustrating to people who work on an RFC and put a lot of work in it and think they're mostly done when it's accepted.
Difference between RFC and implementation exists in the heads of implementers and people in the project.
Default field values
Did a lot of implementation before writing the RFC; this helped a lot with its specificity.
Sometimes people who write RFCs but aren't proficient in compiler engineering, or who are proficient but don't have huge bandwidth, feel frustrated by implementation work that ends up being made irrelevant or needing overhaul due to later language discussions
Sometimes we work in a waterfall mode: Either implementation or RFC first, instead of having a more interleaved process. For larger features interleaving seems needed, but that introduces a lot of coordination points.
Github threads suck for conversations.
Don't like when conversations are spread across a dozen different places, though.
Github threads often have several places too (RFC, tracking, impl, etc).
Zulip good for conversation but it takes serious investment to read.
Github needs curation. When you get a lot of comments, having to expand it repeatedly is painful.
Lack of process to summarize the conversation so far.
Not a scoped conversation; we might want to have a conversation with 20 people, but it invites messages from a much broader set than that.
Summary is probably near the end but not at the very end.
Should link summaries from the top post.
@rustbot note, can give title, will append link to your comment in the top description. Everyone can use it even without edit rights.
Meta: Various features of bots/labels/processes are not easily discoverable, many people don't know about things. (e.g. many people in the room didn't know about rustbot notes.)
"I'm a contributor, where do I read everything I need to know?"
rustc-dev-guide?
Maybe something in the README documenting processes and common tools? – come to @davidtwco's "Team Processes and Policies" session tomorrow for more on this!
rfcbot is a github user but could and should have links to documentation. Use the user README for the rfcbot user (and the triagebot user)!
Could have a triagebot summary command that runs the thread through an LLM.
field defaults
"What else would be needed for stabilization"
To make it usable within the compiler, also had to modify serde to support something, and some of the derives. Blocked two thirds of the places in the compiler where we could have used the syntax.
RFCs can have ecosystem-wide implications, can be a significant holdup.
More clear stage when things are ready and go enable all the tools, rustfmt, etc.
Stage between unstable and stable?
Ties into discussion about spec integration.
Started doing some lint uplifting a few years ago, from clippy to the compiler.
Do a bunch of work, need lang to approve it.
Two years ago, lang meetings were straightforward, last items to arrive would generally get processed sooner. Now there's prioritization, which makes the process feels more opaque; an item will be at the top one week and near the bottom another. Someone has items that have been nominated for years.
Have tried to get lang involved sooner.
Maybe have every lang-nominated item have a dedicated stream? (similar to t-compiler mcps or backports)
Bandwidth mismatch between the two teams. A lot of "hurry up and wait".
Lang has talked about needing to invest more bandwidth to keep up with the queue. Need to talk about that more.
Something compiler can do to help with that?
What are useful and relevant things to highlight?
Regarding lints: as a compiler dev, no idea what lint policy is, would like some guidelines.
e.g. "very few false positives", "ecosystem-wide impact"
More generally speaking, any policy that just lives in people's heads should get written down.
Should have lang members provide more simple vibe checks more often. Check with a lang member, see if it makes sense. Provide guidance on when a "fast path" decision could be made or when it definitely can't.
Policies may make it possible to delegate more.
Less scrutiny when updating a lint than when adding one. But it can have a high impact.
We've created some perverse incentives. If the lang team takes a very long time to respond to things, there's every incentive to find ways to not need lang approval, and that's extremely understandable!
Can we make it so the lang team doesn't have to do all the small decisions?
Very serial bottleneck on the lang team.
"Lower / upper court system", delegation
For the issues that take less time, subsets also tend to work well.
Vibe checks group? Subset of lang and lang advisors who are
How fast can we scale?
Lang ops team, should we grow this, and extend its power?
Observation from recent lang meeting: got X amount done with 4 people, >X done with 3 people, >>>X done with 2 people, and that might be indicative that subsets can do more triage. FCPs will ensure people have a chance to review and object.
Some people in the project have specifically said they don't want lang to delegate.
One person's comment: "Mostly good with a few very visible exceptions"
Bit of an inherent conflict: language team is focused on the user, users want higher level ("natural language"), compiler focused on what's implementable.
We actually have the same goals. If we can make it feel less like "pushing back against features" this would be good.
Right now the feedback between the teams might feel "boolean". Lang: We want something or we don't. Compiler: We can accept something or we can't. And that leads people on lang to guess at how hard it seems to us and compiler to guess at how good the rationale seems to them.
Not trying to propose some exact quantitative thing (cough "story points" cough ugh), but it might help if compiler could give an idea of how hard, and language could give an idea of how important (e.g. story we're trying to tell for class of users), and then we can feel like we're jointly evaluating tradeoffs.
When is implementation feedback important to the design of a language feature?
Example: const Traits.
When introducing things like the experiment process, a sync point is needed to ensure there's understanding of where that process affects both teams
Experiments: may not always be obvious that both lang and compiler are on board.
Sometimes a compiler experiment may not have lang buy-in.
Sometimes lang-supported experiment may have originated with someone other than compiler (or someone on compiler but compiler is large) but it isn't clear if compiler is on board with the experiment.
Would it help to have a compiler person (generalist or specialist) attending lang meetings to help give vibe checks
Doesn't have to be sync, could ping on Zulip.
Would like to know what is being talked about ahead of the meeting. It would be better if meeting notes were generated ahead of the meeting so that relevant people can attend.
As a band-aid, if someone is present to talk about a specific item, we normally prioritize that item to make sure that we talk about it while they're there. That's not perfect and can sidestep prioritization, but it's good for not wasting people's time, and making sure we have the right experts present.
Prioritization isn't inherently bad but opaque prioritization is. Could we make that transparent? Could it be clear from a website? Could the agenda be visible in advance?
Still fine if high-priority items pop up last-minute.
Please flag process gaps or documentation gaps if you encounter them. If you feel like there could/should be written policy/documentation/etc, but instead you're having to get a vibe check from a lang member and they don't have a policy either, flag that, please! Write a lang-team repo issue, tell the person you're talking to, get it written somewhere.
Should we have a regular lang/compiler sync?
Should we have a regular all-leads sync?
