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.