Yes, this is the lang-team plan, but only for approved project groups, not for any idea ever. We did toy with the idea of allowing anyone to make a "new rfc repo" when first considering staging ~2 years ago (blogpost), @steveklabnik even created a rust-rfcs github org for it, I think. But I've come to have hesitations.
I guess overall I'm not sure that I think "massive parallelism" is a win. It feels like a moderation challenge, for example, and all of that activity will be happening on repos that fall under a blessed github org and for which we are ultimately responsible. It also feels like it will perhaps be equally hard or harder to track activity, and to know when things are ready.
If people want a repo, I think I would prefer to start that people can roll their own repos (it's not hard...) and transfer them to the rust-lang org if/when we decide to make something an approved project.
Maybe another way to look at it is just that this a big a problem, and there are lots of orthogonal aspects of it. What I'm most focused on I think is how we can help to coordinate what the Rust org is doing and make sure we are making progress on the ideas we decide to take on, as well as making sure that we support people who have ideas that are a good fit for the moment in full. But there is also a need to help generate that base of productive ideas, and sometimes the existing RFC PRs fill that need -- I think that under the scheme as I've envisioned it thus far there would be less of a place for that, it would ultimately fall more on internals or on people organizing a bit on their own. That may be worth correcting, or just worth keeping in mind and thinking about how to address down the line.
In term of visibility, a badge or a tag could be added at the top of the RFC draft to know what is the current stage. Something like initial draft, gathering feedback, ready for review, accepted, implemented.
I think that github project can be used more or less like this (except for sorting). Tags would be assigned (like new issue, lang-team-concern, …) and would automatically assign the issue to the corresponding column.
This all just screams "classical forum" to me. In this "RFC forum", each RFC would be it's own subforum, and the author of an RFC would get moderation rights for this subforum. For large RFCs, the author would need to solicit help in the form of additional moderators. The RFC itself is a sticky post only the author can edit. Discussion happens in separate threads for each concern, a kind soul could provide a summary post to onboard people. Individual threads can be locked if discussion goes out of hand, but discussion could be resumed in a new thread where a mod explains what went wrong with the old one (say, too much noise without relevant information or such). Offtopic posts can be split off into their own thread, so discussion can stay focused on isolated concerns.
This somewhat hinges on active moderation, but very much feels like quite a bit of burden of the original RFC author can be remedied by people "just helping", i.e. without in-depth knowledge of the topic at hand.
I'm against putting the burden of moderation on the RFC author. Moderation is a surprisingly labor-intensive process and cannot be conducted by people involved in the discussion. I agree that moderation is key here, but it's also hard to find people who want to do this day in, day out.
An additional problem is that in a global project, discussions happen 24/7 and would need to be to be monitored all day around.
As a footnote here: this is to an inherent conflict of interest. Even if the RFC author is a perfect infallible benevolent dictator over discussion of their RFC, selection biases (on the others' part; we're assuming an impossibly perfect author) trivially makes it appear as if the author is, at least in part, using their moderation hammer to advance their argument.
It's the exact same reason conflict of interest law isn't concerned with "actual" conflicts of interest (whatever that is), but the appearance of a potential conflict of interest.
On the topic of blogging updates, Factorio (a factory-building game) has what I would consider a stellar example of a team regularly writing about their project on their public blog, which has had regular weekly updates for 350+ continuous weeks (!). Often, different sections are written by a wide range of contributors, sometimes even contributors from the community.
What I would like to underscore is that even though most posts are pretty substantial on the whole, not every topic is covered every week and weekly contributions related to different topics grow and fade over time. I.e individual subjects may range from no coverage, to a big writeup, to single paragraph updates, and may or may not have followups. Yet the consistently high quality posts on the wide variety of topics within their domain makes the blog one of my weekly reading highlights. It also gives individual contributors and groups a chance to show off their work and get feedback from the community.
Looping back to Rust, I think a similar model of regular conglomerate blog posts created by collecting small/medium updates from many naturally irregular work streams would be beneficial for the Rust community for many of the same reasons.
I did a first experiment of creating PR to the anonymous enum proposal instead of just commenting on IRLO. This is the result of a 10 minutes experiment:
While creating a fork is really easy, and modifying a markdown file using the online editor too, the commit + branch freshly created cannot be to directly used to create a PR against the main branch of the original repository. If I had been able to create the commit directly on @Jon-Davis's github, I could have created a PR in 2 clicks instead of probably a dozen.
The tags proposed by default don't make any sense for the pre-RFC process. pool, unresolved issue, possible direction, and similar tags would be much more useful.
It's not easy to find the current pre-RFC being worked on (currently there is only the pre-RFC on anonymous enum, but you get the idea) since they are not grouped in a central location.
So I still think that having a dedicated organization would be useful.
Any member of the organization could create a new branch in any pre-RFC repo and it would be easier than forking.
The list of default tags would be tailored for the pre-RFC process
It would be easy to list all the pre-RFC that people are working on currently
I still need to explore more this idea, but I think it's a good start.
