Thanks for starting this discussion @aturon. I’ve done some thinking about this lately so here’s a braindump. The scope of this is somewhat larger than you’ve brought up - it’s not organizing just major initatives, but the RFC / feature pipeline and more forward-thinking ’on-the-radar’ issues.
From my perspective, the most important thing is that the roadmap reflects what is actually happening in the project at any time. It is the zeitgeist of Rust, regardless of the process that determines what the various corners of the project is working on.
To that end I suggest we focus on packaging up the resources we already have into a coherent top-down window into the whole project, prefering to nudge everyone into alignment around current practices rather than make big changes.
I have some bulleted lists for you.
Goals for a project roadmap are:
- give users and contributors a picture of what’s happening in rust and where it’s going
- inspire contributors and users with a common vision
- progressive detail - on first glance anybody gets a high-level overview of the project, but you can drill down further to find details of individual work items
- link relevant conversations, issues, rfcs
- provide entry points for contributors
- link to tracking issues for initatives
- illuminate current initiatives
- illuminate the RFC / feature pipeline
- foreshadow future initiatives / “on-the-radar” topics
- show progress towards goals
- show what’s in the next release
- living updates - allow multiple people to maintain it, keep it updated as the project evolves and the zeitgeist changes
The last point, about ‘living updates’ is in contrast to your primary thrust, that the roadmap is published on a 12 week cadence. I don’t care about the cadence of the process so much, as long as teams are in some way generating suitable information to feed into a roadmap and it is periodically being refreshed. Actually, I worry that attempting to get every person or team responsible for some major area of the project to update their plan at the same time will be asking too much.
We can draw from these existing sources of information:
- feature pipeline: RFCs, tracking issues, feature names
- initatives: tracking issues, milestones
- “on-the-radar” subjects: irlo, RFCs, issues
- release notes
The tracking issues are key to bringing a roadmap together - they are something we are already mostly in the habit of making and maintaining. And they are limited in scope so that those responsible for each initiative only need to worry about keeping their tracking issue fresh.
Some current major activities in the project:
- rustfmt
- IDEs
- rustup
- language feature pipeline - main focus of lang team
- std feature pipeline - main focus of libs team
- memory model - on-the-radar
- GC - perpetually on-the-radar
- MIR
- MIR-trans
- incremental compilation
- cross-compile
- error messages
One problem we’re going to find is that many of what we think of now as ‘initatives’ are quite open ended - IDEs will be a major focus of the project for years. We’ll need to keep such areas fresh and focused on more limited goals so that we can demonstrate progress.
A hypothetical roadmap outline:
- vision statement - what does the product we are delivering ideally look like? what are the common themes that unite all these initiatives?
- current initiatives - 8-12 top-priority rallying points in rust, each with their own tracking issues, hopefully connected to ‘E-help-wanted’, ‘E-easy’ issues
- feature pipeline - this is much more fine-grained than the initiatives, covering every RFC’d (and some un-RFC’d) feature; but the scope of what might be in the feature pipeline is also much smaller than what may be in initiatives - consider that most of what happens outside of the language and std don’t go through the RFC pipeline.
- on-the-radar - subjects that the team is thinking about a lot and is interested in dialog about, in anticipation of launching an organized effort in the future. an example of this recently might be the memory model, which many people have been debating, but which as a project we’re not quite actively committed to yet. This is related to the "problem tracker" you suggest elsewhere, perhaps highlights of.
- release history / future - this is the concrete record of what we actually achieved or are expecting to achieve in the next release
I’m not sure the exact organization of these or how to achieve
’progressive detail’. Certainly you wouldn’t want to see the firehose
of everything going on in the feature pipeline upon first glance, for
example. But contributors should be able to drill down into the
feature pipeline to see that, e.g. ? is stalled at stage X and
that work Y is left to do.