Other naming ideas from IRC: dev, scribble, roughdraft, plumbing, marginalia.
I think this would also be a good place to automatically upload a version of the docs that contain the docs of the rust-internal crates. Currently there’s only an online version by @Manishearth’s at http://manishearth.github.io/rust-internals-docs/rustc/index.html
May I suggest another: arcana.
I suggest any name which is related to rabbits.
I love the idea, I’m just not very happy with any of the names…
I think this is a great idea, and fwiw I like “dungeon” too
Ooh the rustonomic- fuck.
- Stiki - static wiki
- gossip train
- black market
Agreed we should host this documentation. Here’s an issue specifically for it.
So, so tempting.
I like @Gankro’s ‘forge’ and ‘workshop’ too.
One aspect of this project that I didn’t say anything about in the op is that it can also act as a staging area for content that may belong on the website, but doesn’t possess the quality, or doesn’t yet fit for other reasons.
Another trivial thing to consider: we have a lot of subdomains and it’s fun to abbreviate them: either ‘u.r-l.o’ or even ‘urlo’. To me this says all subdomains ideally start with a unique letter.
‘wrlo’, ‘srlo’, ‘urlo’, ‘irlo’, ‘brlo’, ‘crlo’, ‘drlo’ all taken. Important stuff.
I think there’s a danger of this just being another developer wiki, with all of the disadvantages: the potential to become out of date quickly, poorly maintained, and inconsistent or incomplete. What ideas do you have about mitigating these possibilities? Such as tying documentation to version numbers, page “ownership”, and routine cleanup/triage.
Hmm, “forge.rust-lang.org” -> “frlo” -> “furlough” is kind of punny, but I can’t really make sense of it…
The main difference I propose to combat quality problems is to limit who can approve changes through the PR process, the main effect of this being to limit which pages are created at all and by whom. The old wiki suffered from many marginal pages that were unmaintained, while also containing several useful pages that were reasonably maintained.
Just name it developer_docs
Sorry for the very late reply on this. I feel like this is a pretty plausible way to grow our contributor-oriented content without some of the downsides of wikis (given the review process and clear scope that you outlined).
That said, some of the topics you outlined at the top seem user-focused/like they should go on the main site (or other documentation venues):
- platform building instructions, musl, android, mipsel, ios, etc, cross compiles
- tiers and support levels
- user groups / meetups
- lists of links to ides, libraries, other tooling etc.
- collections of videos, talks, blog posts
- bibliography / references
- high-profile projects?
- profiling tips
- lists of interesting tools to use on/with rust
And a couple were a bit ambiguous (not sure if the “hacks” here are for hacking on rustc itself, or just for using Rust):
- testing hacks
- debugging hacks
Can you elaborate on why these topics seemed like a good match for the dungeon, given that they seem of interest to the user community?
Maybe a different way of asking this is: is the split primarily about audience (user vs contrib)? I could imagine that we host some user-oriented content in the dungeon as a kind of pipelining/maturation process (for stuff that’s still changing rapidly, or where we want to iterate for a while before going fully public).
I don’t totally see this is being oriented toward devs. It’s an easy way to rationalize its need, but I also see this as being for more dynamic, low-quality, and underbaked documentation.
Not in my view, but others have expressed that desire.