pre-RFC: RFC "Deliberation period"

[Gankro]

Tags form pseudo-sub-forums. e.g. here is the “language design” subforum: https://internals.rust-lang.org/c/language-design

If you click “new topic” it will be automatically generated under that tag, too. So in theory we could make rfcs.rust-lang.org, with a tag for each rfc, and the rfc would link “discuss here” in the same way we link “rendered”.

Could be automated with a bot (locks and leaves a comment with the link, sets up the tag).

[johnthagen]

The Rust community is growing, and the RFC process is starting to feel some growing pains. It’s becoming more and more difficult for people to get involved in the deliberation part of the RFC process without feeling overwhelmed with content. We’re missing out on feedback from folks who look at a recently posted RFC, see that it already has 50, 100, 200 comments, and close the tab (I have done this).

On a tooling perspective, I agree with what @repax said:

I think that the linear format of the discussion forum is a major problem: all sub topics get mixed together and it can become overwhelming to read the whole lot of it.

I think a linear forum is probably not the most ideal place to try to have public discussion of this kind. Even reddit has a tree structure to comments.

---

But even more fundamentally, I think a major issue to consider is “Can we scalably decide every language/tooling change in a public forum?” For example, from what I understand about C++ and Python (python-dev) language development is that typically smaller groups of individuals (the committees, core team, etc) primarily have discussions and make decisions in small groups. Given how popular Python is, if the python-dev mailing list could be commented on (easily) by anyone, and they truly asked everyone in the community to join and give feedback, I think it would be chaotic.

So my point, I think Rust’s goals are very laudable to “include anyone and everyone” in these very important discussions, but has any other language ever successfully done this at scale? If so, what can Rust learn from how they succeeded? If not, should we consider changing our goals?

I personally worry a little that the core team members (who have done amazing work!) could get exhausted trying to genuinely incorporate feedback from every Rust developer at every step. I really don’t want them to get burned out.

[djc]

Agreeing with those who argue here that we really need better tooling for grouping related discussions, I’m wondering if there’s a point hiding in here that RFC’s should be smaller? Using part 2 of the modules epic as an example, there were a bunch of knobs under discussion. I think identifying those knobs and separating the discussions about each of them more would be a big help here. Of course, it would still be important to also identify new knobs as discussion goes.

[aturon]

I think something like this idea has a lot of promise – and, hilariously, while I’ve taken the time to read the entire comment thread I don’t have time to respond to people in detail right now.

What I did want to do right now is record a data point from the recent modules discussion, which has largely taken place on this discourse forum. It went something like this:

• I made an initial blog post and opened a thread, which got a huge amount of activity
• After a week, I wrote another blog post that was effectively my overall response to the thread (and included an alternative proposal), partly in an effort to reboot discussion.
  • I opened a new thread for that RFC and locked the original one.
  • The new thread also achieved a high comment volume very quickly
• @withoutboats wrote a post with an improved variant of the proposal as a new thread.
  • Most discussion moved to this new thread, but some continued on the previous one for a while.
• A half dozen people then created new threads with additional alternatives
• Some additional threads were started to tease out specific issues and discuss them head on

Having stepped away for a couple days, when returning I was faced with a large number of threads, each of which had a fair number of comments, and many of which were recapitulating the same points. It also quickly became clear that @withoutboats’s post was the “main” place for ongoing discussion, so I focused my energy catching up on that, and haven’t been able to keep up well with the others.

In short: I didn’t find this multi-thread approach to be particularly helpful. This might have some bearing on changes to the RFC discussion process.

In particular:

• There’s no way to actually “force” discussion on a particular topic to happen in a particular thread, so you end up with even more duplication of discussion, and a sinking feeling seeing multiple large threads to wade through.

• Even if we could enforce such threading, it’s far from clear what the threads should even be. Should alternative proposals garner fresh threads? Does it make sense to have a thread focused on one facet of a proposal, when the “main discussion” might end up discarding that entire portion of the proposal anyway?

• There was pretty clearly a “main” thread at all times. This thread seemed to play the vital role of maintaining the overall state of the conversation – and, in particular, of any emerging consensus. A lot of this back-and-forth process has been about gauging people’s reactions to things, about a give and take on both sides. It’s hard to do that spread across several threads, and left me with less certainty about buy-in.

On the other hand, throughout this process periodic summarization and collapsing of the main thread would’ve been extremely valuable.

[le-jzr]

While I agree that the modules discussion didn’t benefit much from its multi-threaded nature, I’d argue that the threads haven’t been structured to begin with. Instead of focusing on independent pieces of the overall problem, most of the new threads just tried to cook up a different complete solution from the author’s preferred components. If anything, it shows that even though we know how to modularize software, we haven’t yet learned how to do the same with discussions.

[Ixrec]

I’d agree with @le-jzr that the module threads here weren’t really “doing threading right”. But it also sounds like we’re approaching a consensus just from the three main threads we’ve had so far, so it may be that (to my surprise) even this module system debate isn’t quite complicated enough that it would have benefited from a dedicated github repo or subforum.

[aturon]

Yeah, I don’t disagree with this take, but I’m skeptical in our collective ability to do threads “right”. And the sense of being “off of the main discussion” was an interesting one to me.

[Centril]

I think josh’s proposal wrt. letting a bot providing a “Rendered” link, etc. is spot on and something that should be done irrespective of this RFC.

From an RFC-authors perspective, my experience so far has been that within 0-5 days of the RFC being published, I can, in collaboration, solve and clarify most issues.

To some (small) extent, it has been my experience that even if the RFC already discussed some motivational problem or alternative that a user’s comment is about, they write the comment in any case because they did not read those parts of the RFC.

My greatest fear when writing an RFC is to be hammered with down-votes on the PR itself, even if the RFC is very detailed. Getting a lot of down votes is very demoralizing. It is much better to have someone give a comment that gives motivated disapproval in a comment and then that comment is up-voted. I could be mistaken, but it seems to me that there’s a certain effect where once you’ve gotten a few down-votes, it becomes easier for readers to down-vote more, and then you get into an avalanche of down-votes. This is probably also true of up-votes, but they are not as problematic. If at all possible, I’d like down-votes on at least the RFC PR to be disabled on the RFC repo @ GitHub.

With respect to threads, I think we should encourage the use of line-comments which can act as threading on a specific issue on GitHub.

[carols10cents]

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