Distinction between user and developer audiences for this forum


This forum was originally opened to replace the mailing list, which was considered difficult to manage as traffic grew, and which will be shut down soon. Currently it is only open to ‘internals’ discussion, that is discussion between developers of the Rust project itself on concerns relating to the evolution of the project and language. It is explicitly not for users of the Rust language.

Currently, users who wish to discuss Rust are directed toward Reddit or Stack Overflow, but there is a somewhat widely-held opinion that the combination of these two resources is still insufficient. Neither is a general-purpose forum: Reddit is best as a news aggregator, and Stack Overflow for collecting answers to questions.

I’m currently trying to decide the best way to provide users a space for general discussion, the two primary options being: adjust the configuration of this Discourse instance to accommodate both audiences, or install a second Discourse instance for users, leaving this one just for project developers.

Per @codinghorror’s request this is comparison of the two audiences we are trying to cater to.

Project developers are mostly people contributing to Rust, but also library authors and others invested in the design and evolution of the language. Their communication is most often about debating language design matters and issues of project governance. Discussion is often with the intent of vetting ideas and shoring up consensus in anticipation of proposing RFCs or submitting pull requests.

Users are people developing software in Rust. They are most concerned with asking questions, learning, sharing tips and best practices, discussing projects in Rust. Users greatly outnumber the project developers.

There is overlap between these two audiences, e.g. library authors who also participate in Rust’s development.

It is considered highly-desirable to maintain separation between user discussion and developer discussion. One of the perceived problems of the mailing list was that the audience was not clear, there was a great deal of drive-by bikeshedding, and a resulting high signal-to-noise ratio. What began as a place for project coordination ended as a free-for-all with little relevance to the development of the project as discussion migrated elsewhere.


This is a big risk. I think they should be two separate sites for this reason (a strong wall between audiences). You want a higher bar to entry for the developer side, and more vetting of users. Otherwise the general purpose and bikeshed stuff will dominate the site, because that’s the way these things go…

Maybe developers.rust-lang.org (or internals.rust-lang.org or perhaps contributors.rust-lang.org is even better IMO) and discuss.rust-lang.org ?


If you think it’s most appropriate to have two sites, then that’s what we’ll do. I’ll look into setting it up sometime in the next few weeks.


I think two sites is the way forward too. (And, for the bikeshed, I prefer internals.rust-lang, since it mirrors the irc channel).


We could also consider committing to the current migration of languages idea traffic to the RFCs repo, and just allow WIP RFCs, in the same way WIP PRs are permitted on the main repo. This would reduce the number of places people need to look to track design ideas.


Cross-reference to a related reddit thread:


brson mentions “people contributing to Rust” where “Rust” is defined as the GitHub project, but might it also be worth distinguishing between discussion of the language/compiler/toolchain itself and discussion of the standard library?

Most of the content here so far has been the former, but I’d think that the latter will increase as a proportion as the language starts stabilizing after 1.0, and at that point it might start drowning out the core stuff. Stdlib work also has a significantly lower bar to entry than core work, which is great for new contributors getting their feet wet (e.g. me) but bad for noise.


@mrec That’s an interesting point, yeah. The libs do provide a lower bar to entry than the compiler, and people do often prefer to focus on one or the other.