I think part of the disconnect is a perception of what’s “in progress” from “inside” versus “outside”.
Just as a minimal example, the impression of the atmosphere of interest is definitely different if you primarily consider internals, the RFC repo, the bug tracker, or just TWIR. Then there’s the slightly more closed (feeling) team processes: obviously not everyone’s present for steering/triage meetings so what’s covered there, while potentially guiding what that team considers “active”, has little to no effect on “outside” atmosphere.
It’s similar to the “pre-RFC flood” that can be felt here on irlo. A lot of medium-baked (or less) ideas get thrown around here but never make it to the RFCs repo, due in part to both a gating of thought provided here and a lack of interest in putting forth the effort to push it forward. RFC (issues) that don’t see team interaction are similar in that if they’re open and “community effort” goes into them, the “atmosphere” is that they’re “open” and taking some “cost” to host (even if that’s just real-estate on a digital issue tracker) even if the team isn’t going to look at it for a year due to other priorities.
This isn’t the entire reason for this “flooded” atmosphere, definitely. But I think at the very least it is a part of the disconnect leading one party to say “the system is working” and the other that it isn’t in respect to managing the flood of opinions that public consensus-driven design is.
(off-topic EDIT: I had no idea irlo had cake day icons, this is the first time I’ve seen them (on me).)
Things appear to have settled. I wanted to summarize the discussion a bit, since it would be ironic if I didn’t.
Meta-note: I tried to be “complete” and “concise”, erring on the side of “complete”. It’s kind of hard. Let me know what you think…
OP
In the OP, I proposed a number of ideas. These don’t seem to have generated much controversy. My impression is that many people agree with them. Some also seem like incremental enough changes to be done without an RFC.
Centril points out closed/postponed RFCs are already easy to find; it’s just a matter of expending the effort to read them.
skade argues that adding automation without other changes will cause problems to get worse.
Thread summaries
cartesiancat Posted some thoughts on how to implement good thread summaries for long discussions. Here are the high-level points (please point out if I missed anything):
Summaries should be “complete, clear, concise, and non-redundant”; “optimize for reading”
There was some discussion about what “complete” and “concise” means. scottmcm suggests framing it similarly to the Agile Manifesto, so I proposed “While we value concise and complete summaries, in situations where they conflict, I think we should completeness.”
cartesiancat suggests that if a summary comment would be too long, a sentence with a link to the original comment would be acceptable.
rfcbot used to update the top post or make a new post, ensuring everyone gets emailed. rfcbot collapses comments between summaries.
pietroalbini says there is not GitHub API for collapsing comments at the moment.
Frequency of summaries: we should define and enforce how frequent they should be.
I originally proposed every 30 comments, but there are other metrics, e.g. once per unit of time or once per unit in time in which there are at least N comments.
Another problem (pointed out elsewhere) is that initially there are usually a bunch of typo comments.
Who writes summaries
In a previous thread, I proposed that it should be a lang team member. cartesiancat proposes it should be the RFC author.
“Rules about comments should be strict and enforced”. The idea is to reduce noise and redundant commenting.
varkor points out that it might be cleaner to have rfcbot make the first post to each issue and update that as the summary comment.
CAD97 points out that summarizing a bikeshed is hard, especially when going for completeness.
Unintentional Bias
There were a few discussions that arose around how to reduce bias.
cartesiancat proposed a “proponent/opponent” model, in which each summary should be written by two people: one in favor of the RFC (presumably the author), and one against the RFC, playing devil’s advocate.
josh points out that proposing an FCP with a given disposition at the beginning gives that disposition “inevitable momentum”. Instead, they suggest that each team member should list their disposition and let discussion come to a consensus from there.
Deciding on Problems
matthieum suggests that we should amend the RFC process to first formally acknowledge a problem using a “Request for Proposals” process. The intent is to reduce discussion of problems that may not be widely felt to be a problem.
Ixrec responds that “in practice it’s often impossible to decide “this problem isn’t serious enough to warrant a language change” without knowing what the language change to solve it would actually look like”, but agrees that avoiding debates that don’t need to be had would be good.
fintelia worries that such an RFP process would identify difficult or impossible problems and devolve into discussions about the existence of some unlikely solution.
I raise the question of how eRFCs and roadmaps tie into this problem. In a sense, they are about defining problems that the community finds important.
Negative Space, Exhaustion, and Resources
There were much discussion on exhaustion and negative space. skade first brings up the topic with regards to heated discussions. I later turned more towards prioritization and the use of community resources and effort.
skade brings up the topic of “negative space”. (To my knowledge, this was first brought up by Graydon in their Rust2019 blog post).
(@skade: I tried to distill the main points, please feel free to correct me if I missed anything)
They point to the recent “Turbofish” and “await syntax” RFC discussions to illustrate some points.
They suggest “more roadmapping and sticking to it”. They also suggest creating mini-roadmaps to elaborate more on specific areas.
They suggest some ways of managing discussion threads: “call project members out more harshly if they aggressively discuss”, “actively pulling in people from relevant groups early”, “Frequent rechecking if we don’t go off track by absolutely wanting to solve a hard problem just for the sake of it”
In the case of heated syntax bikesheds, like the await one, the design space has become enormous and the discussion is exhausting.
Debate includes ideas that would need their own RFCs.
Pressure is high as the feature is in high demand.
The implementors often feel unappreciated because of the high rate of new ideas.
skade suggests listing the available options up front and limiting debate to those options. They also suggest raising effort the bar for commenting and prohibiting proposals that would require their own RFCs. They suggest that arbitrage and credit assignments should be made up front.
how to evaluate if a proposal falls into the negative space and should thus be closed?
how to prevent a flood of negative RFCs and thus waste time anyway?
how to prevent stagnation?
Centril points to this useful discussion about negative space between Graydon, Centril, and others.
Centril and I discuss temporary negative space and focusing of community resources in these comments: 12345678. A few interesting realizations came out of this discussion for me. Perhaps @Centril can point out if I missed anything or mischaracterized their views.
I feel that I spend above-average time on rust stuff, but still feel that the pace of change is overwhelming and that much technical debt has accumulated.
Centril (as a member of the Language team) finds that technical debt related to that team is triaged and handled regularly and not a source for concern. Moreover, much of the technical debt is blocked on items that are actively receiving attention.
I expressed that work on T-Lang items still consumes community time and attention away from other items and that refocusing community attention on a smaller set of things would improve productivity.
Centril disagrees that work could proceed much faster and that refocusing attention would have little effect because of difference in skill sets.
Centril argues that negative RFCs would just create more work for the language team.
Centril argues that much of the design work happening is technical debt and simplifies the language overall.
davidtwco suggests that the pace of change is not the problem. Rather, the ability of the community to keep up is the problem.
They suggest that this is due to “large, sprawling, and unproductive” discussions and that " the discussions on RFCs quickly become unprofessional (definitely not everyone), propose often impractical solutions (eg. things would need RFCs themselves) or attempt to relitigate already settled discussions." and that “There’s just too much noise right now”.
They suggest that the solution is to raise the bar because “there’s a really high cost to commenting” and that “a handful of productive and professional individuals could discuss a topic as thoroughly in thirty comments as we currently do in hundreds”
fintelia suggests that a negative RFC would not be well received and would generate even more contentious debates.
Postitive roadmapping and sticking closer to the roadmap or some for of “guard rails” to prevent discussion from straying to far seem to be suggested often as an alternative to negative RFCs: 123
Regarding refocusing effort, I suggested something like the impl Period of 2017.
petrochenkov recalls that this led to a pre-deadline flood of RFCs which was hard to handle. I claimed that this is a reflection on setting hard deadlines more than the impl Period itself.
samsieber suggests that negative RFCs might mitigate the pre-deadline flood.
Team and Community Perspectives
Another (unexpected, to me) theme was the difference in perspectives from the language team and the rest of the community. In particular, these seem to indicate to me some communication disconnect.
Centril’s comments in the discussion above seem to focus largely on the view of the Language team (understandably). My impression is that team is pretty organized and does not feel an excess of tech debt. (TBH, I wasn’t really sure if this was the view of the whole team or just Centril as a member of the team?)
samsieber suggests that “The organic attention of the “community” often does not line up with the attention of the “teams”.” and that negative RFCs might help with that but aren’t the only way to accomplish it.
CAD97 notes “part of the disconnect is a perception of what’s “in progress” from “inside” versus “outside””. Specifically, team triages and decisions affect what’s worked on, but not what the community perceives as “in progress”:
“obviously not everyone’s present for steering/triage meetings so what’s covered there, while potentially guiding what that team considers “active”, has little to no effect on “outside” atmosphere.”
“the “atmosphere” is that they’re “open” and taking some “cost” to host (even if that’s just real-estate on a digital issue tracker) even if the team isn’t going to look at it for a year due to other priorities.”
samsieber suggests that part of bridging the disconnect might be better tooling: “I’d go for more tooling making it easier for team members to mark where their attention is, and aggregating it into an index / portal that makes it easier for “community” members to see where attention is allocated.”
Do we want negative RFCs? My impression is that the leaning on this thread is “probably not” but we want more “guard rails” or something similar, though there are several who have expressed desire for negative RFCs. (Personally, I’m on the fence).
I certainly missed a bunch, so please just ping me, and I will add them
My immediate reaction is: That’s not so much complete as it is comprehensive. I don’t think we should expect or aim for the latter in summaries. In fact, one of the most important parts of a truly useful summary is to completely leave out details that are not significant (which is also why they can be contentious…), rather than forcing every reader to decide what is and isn’t significant.
(sorry if that sounds dismissive of all the hard work you put into that post!)
@mark-i-m This is the kind of think I was imagining! Thanks for a great demonstration! And since you edited the first comment I was able to click the link and go straight to the summary, read through it, and then feel like I had caught up on the thread without needing to read through each individual message. I think it would be nice if the RFC bot could edit the first post like @varkor suggested.
So this leaves the question of what to do once more than one summary has been made over time. Presumably some of the earlier points will become irrelevant, or some points will be repeated. For someone coming to the thread for the first time the ideal situation is for the summary to be edited to avoid them having to read irrelevant or duplicated points as they read through each summary post. However, someone who has already read the thread before would be interested in an "update" summary which only contains the new points since the last summary.
Perhaps it would be possible for the summariser to maintain summary at the top of the whole conversation, as well as posting update summaries every so often?
Good point - things that are insignificant, irrelevant, off-topic, unhelpful, or otherwise don't contribute to the discussion should be left out. I see that "comprehensive" probably captures this idea better than "complete".
This helps in the overarching goal of optimising for reading.
I'd rather just remove that kind of thing from the stream entirely. Flagging and hiding the writing we don't want seems easier than allowing the reader to avoid them by engaging in even more writing.
My thinking is that each summary would only cover things that changed since the last summary. The first post would contain a list of summary posts. I think this would optimize for people who are actively following the discussion without being a hindrance to those who are jumping in for the first time.
My impression is that the moderators on GitHub already do a pretty good job of collapsing comments like that. At a first reading I thought you were saying something more controversial, though: that we should collapse comments more aggressively than we do today (e.g. side conversations about details), forcing those conversations to happen on other media.
I almost wish we could have the summary in git. Well, not really. But it would be cool to keep one persistent up-to-date summary and be able to just see the changes since the last time you looked at it.
I do this in many of my RFCs: the alternatives and unresolved questions sections should reflect things raised in the thread, so people don't need to read the thread after the fact in addition to the RFC to know about important discussions that occurred around the RFC.