Refining RFCs part 1: Roadmap

1

I've recently written a blog post enumerating several ideas for improving Rust's RFC process. The post contains three separate (but interdependent) proposal sketches, which I'm eager for feedback and discussion on. I'm carving out each proposal as a standalone thread here on internals.

At the heart of Rust's open development is the RFC process. Every major change to the language, compiler, core libraries, tooling, and policy go through an RFC writeup and consensus-building process. The process served us incredibly well in clarifying our technical direction on the road to 1.0, and has continued to be highly active since then, with on average about 2 RFCs merged every week.

But it's not all roses. There's been a growing sense among both Rust leadership and the broader community that the RFC process needs some further refinement as we continue to grow the community. I want to lay out my view of the problems and sketch some possible solutions, based on extensive discussion and brainstorming with many others on the team.

Each idea operates at a different scale (from big-picture to low-level mechanics), but they are intended to fit together into a whole; each one supports the others. Ultimately, these should result in a single RFC, but in the meantime I'll start a discuss thread for each proposal.

There is a clear common theme to all of the problems I want to raise: communication. We need to find ways to better scale up lines of communication around the RFC process, and for Rust core development in general. There is also a cross-cutting concern: a need to increase our focus on mentoring and the path to team membership. @wycats has a great saying about measuring the health of the team structure:

Being a very active contributor who is not yet on a subteam should feel very close to actually being on that subteam.

Shooting for such a state of affairs has many benefits, not least of which is increasing the scalability of our community.

This thread is for the "Roadmap" part of the proposal.

Proposal: Roadmap

The problem

Lack of clear rallying points. One thing that made the run-up to the 1.0 release so exhilarating was the way the release focused our effort: there was a big overarching goal we were all working toward, which led to a number of fairly clear-cut subgoals that everyone could pitch in on.

Since then, though, we've never had quite as clear of a "north star". We've communicated some very high-level plans, and had success rallying efforts around self-contained projects like MIR. But we don't have a systematic way of rallying our efforts around important goals on a regular basis. This gap is a shame, because there are many people eager to contribute, who we should be directing toward common, important goals with good mentoring opportunities. Likewise, there are lots of people who could provide useful perspective on goals, or even provide leadership on initiatives, who don't have an outlet today.

Relatedly, it can be difficult to contribute at the RFC level. Is the problem you want to solve a priority for the relevant team or wider community? When it comes to the core language, there is only so much design work that can be in flight at once (since it all needs to fit together), so greater clarity on priorities and motivations is essential.

The proposal

Idea: publish a roadmap on a regular cadence, e.g. every two release cycles (12 weeks).

The roadmap would contain, at a minimum, a small set of "major initiatives" for that period. An initiative might cover any phase of development, e.g.:

  • Early investigation: For example, building out NDK support in rustup or exploring implications of various memory model choices.
  • Design: For example, working out a revised design for rand or const generics.
  • Implementation: For example, the MIR initiative or rustbuild.
  • Documentation: For example, focused effort on updating API docs in a portion of the standard library.
  • Community: For example, launching RustBridge.

And potentially many other categories as well.

Initiatives are intended to be a primary rallying point for the community, and thus should share some basic traits:

  • Clear scope: an initiative should have clear-cut goals that can actually be finished. So, an open-ended goal like "MIR" doesn't fly, but "Get MIR-trans working on all of crates.io" does.
  • Timeboxed: relatedly, an initiative should realistically last at most, say, 24 weeks (two roadmaps).
  • Commitment: There should be some level of commitment from multiple people to actually work on the initiative. In particular, the initiative should list some primary points of contact, and ideally mentors.

Each initiative would have a dedicated status page with this information, links to issues or other materials, and potentially a FAQ. We've often found that there are recurring questions ("When is MIR going to be turned on by default?") about big, ongoing work. The roadmap and status pages give us a highly visible, central and curated place to put this information.

The roadmap should be set via an open consensus process in which anyone can propose or influence initiatives. The initiatives should fit criteria like those listed above, and should also fit into an overall vision for Rust's evolution over a longer period.

Details to be worked out:

  • Cadence
  • Can initiatives be added mid-stream?
  • Full guidelines for initiatives; how many should be in flight at once? Needs to be a small number to make this practical and useful (it's a form of curation/rallying).
  • What is the process for deciding on the initiatives?
  • Do we divvy things up by subteam? That would make the discussion easier, but doesn't allow for cross-cutting initiatives very easily.
  • Can we find less boring terms than "Roadmap" and "Initiative"?
  • Can we also include the "feature pipeline" and other long-running concerns into a roadmap somehow?
1 Like
2

This has worked very well for Servo. I’ve been maintaining a Roadmap (https://github.com/servo/servo/wiki/Roadmap ) for most of the life of the project and it’s really been a huge help for letting the community know what’s in now vs. later.

Related to that, though, is also the “zomg backlog” of everything we think is in eventually: https://github.com/servo/servo/wiki/Remaining-work

I’m not sure how these carry over to Rust, as building a web browser has a lot of “just gotta do a ton of things that are in a list that already exists” whereas a new programming language can be a bit more open-ended, but these are definitely things that have helped us in communicating not only with contributors, but also with external companies and the press.

3

First: I think this is a great idea! One of the things that made initial contributions to Rust easier was that @brson put together a list of major initiatives for improvement to the Rust website, providing a clear task that I could then direct myself toward. This sort of clarity is really helpful in directing contributions, and inspiring potential contributors.

This would also help to answer the common question of something being or not being a priority for Rust. At the moment, knowing whether something is a priority is done via word-of-mouth. How do you know that addition of higher-kinded types isn’t a priority? Because someone told you it wasn’t (or rather, that there are other priorities, and people may get interested if a good proposal were to be made). Providing a clear view into where Rust wants to go, and where people could best contribute, is a win for everyone, and it makes discussion of those priorities easier.

On to the questions posed at the end, splitting up by subteam makes sense to me, and it may actually be desirable for there to be some friction in making cross-cutting changes. Inherently, these changes will be bigger and more complicated, and so slowing down the process in that case may be a good thing.

For deciding on the initiatives, there’s a balance to be struck between community input and the leadership of the Rust teams. I think looking at the history of the more contentious debates would be a good idea (for example, the debate on the naming of isize and usize). The more contentious the disagreement about prioritization within the community, the more time would be spent gathering community feedback and arguments, with the final call made by the relevant Rust team. Obviously, that Rust team would provide reasoning regarding the final decision, and the hope would be that it any decision would be made with deference to the desires of the community, and with clear and strong reasoning when the community and the Rust Team disagree.

The naming issue will no doubt be subject to substantial bikeshedding. I don’t have much of an opinion on this.

On the “feature pipeline” idea, it may be useful for the Rust Teams (or maybe just the Core Team) to provide periodic reports on where they think Rust should go next. This means essentially listing those issues deemed most important by the community (like the main issues identified in the recent community poll). Making this sort of reporting regular, and including in each report some substantive identification of progress on issues listed in the previous report, would provide insight both into where Rust is trying to go, and how well it is moving on the road to that goal. This would be, in essence, a higher-level accompaniment to the roadmap process described here (the roadmap addresses specific initiatives, whereas the report identifies goals).

4

I think a roadmap is great.

I think the issue I have... I'm not sure where to put this, so I'll put this on part 1. I don't think this solves the real issue.

I don't think this is that issue. I think the real issue is the subteams, honestly. They have too much power, and not enough people on them. The compiler and lang teams have 9 people between them, despite having 6 and 7 people each. 2 people. 2 people on the lang team aren't on the compiler team. We need to spread the load between more people.

(Note, this would happen over the next 10 years). My personal preference is to switch from subteams to something more like the strike teams seen for unsafe code, and for style, except (more-ish) permanent. It'd, in my perfect world, be modeled after the Study Group model from C++, which are very easy to join, unlike the current teams which are very exclusionary.

The two teams that'd stick around are Libs, and Lang and Core, which would merge. The other teams would turn into community, Mozilla, or rustc teams, but wouldn't have any effect on standardization. The new Libs and Core teams would open up to other compilers, and stop being a mostly-Mozilla show.

5

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.

6

I'm not sure where to put this, so I'll put this on part 1

Perhaps we should start another thread for general discussion? It does seem there is a lot that could be discussed that doesn't fall into either of the three buckets?

I think the real issue is the subteams, honestly. They have too much power, and not enough people on them.

This is a fundamentally difficult problem in any governance structure. Furthermore, language design has some quirks of its own that make it particularly difficult to address. In particular, language evolution is a pretty conservative affair, it is fairly slow going, and requires a well-coordinated and focussed vision. I believe that this sometimes looks like group-think or (less charitably) corruption from 'outside'.

I hypothesise that the sub-teams do not have as much power as you imagine. As a member of the lang sub-team, I feel like most of the work is administration. The only power as such is having a voice in the acceptance process for RFCs, however, I think this is kind of an illusion of sorts - nearly all the time the language team have similar opinions about an RFC, and it is unlikely that one dissenting voice would ever meaningfully change that. If it appears that sub-team RFCs are treated more favourably, that is because the authors are more likely to have a good understanding of what is likely to be accepted, rather than that they are writing RFCs according to their own agenda and influencing decisions.

As a supporting example I offer RFC 1373 which was proposed by a sub-team member (me) but closed because every other member of the team didn't like it (they were all wrong, btw) and it didn't have the support of the community.

One motivation for the roadmap idea is to keep the whole community aware of the Zeitgeist in the community and thus be able to focus on RFCs or other work most likely to be welcome.

Being a very active contributor who is not yet on a subteam should feel very close to actually being on that subteam.

To turn this around a bit, if you (or anyone else in the community) were added to a subteam, what would you do that you cannot do today?

FWIW, I empathise with the feeling of exclusion - I feel the same way about the core team. Although I am probably not missing out on much, and I would be hard pressed to answer my question above with respect to the core team, it still feels uncomfortable to be watching from the outside in and not to have a voice. In the past I have found better communication to be the solution to this as much as actual devolution of powers and hope that we can do better in both respects from the subteams.

Finally, one problem that is unique to the lang team is that there is no 'outer circle' of the team in the way that libs and compiler teams have a set of respected community members with r+ rights. I would like to solve that problem, though not sure how exactly. Perhaps we can use the mechanisms described in part 3 to extend the circle of community members who have a voice in RFC acceptance without necessarily expanding the team itself.

1 Like
7

I have some other thoughts but since I'm short of time, I just wanted to link to an issue that's open on the dashboard repository about providing better introspection into the feature pipeline:

If there are automate-able ways to expand that view to cover a higher level of project abstraction, I'm all ears. I think it would be a big win if some of the roadmap presentation could be automated without having to manually edit the website.

8

I said what I wanted to say weirdly… I meant more of like, y’all are too few, with too many jobs. I don’t mean any offense, but, stuff slips through the cracks because there’s so much going on, and you have so few people actually helping. Like, RFC 1524. That RFC is in total limbo; I really want to edit it and make it better, and I have no idea how because one lang team person has replied to critique the design, or if I should because it might get rejected out of hand. I have absolutely no idea.

Also, they were not wrong about RFC 1373 :stuck_out_tongue_winking_eye:

9

I was very happy to see your post this morning, because I have been thinking (as a recently converted Rustacean – about 7 weeks in) these exact things. Some notes/comments:

You mention clear scope, timeboxed, commitment; this sounds a lot like the SMART acronym I recently learned about (Specific, Measurable, Achievable, Relevant, Time-bound). There might be value in reusing something there.

As for naming, agile people use the term epic to refer to a collection of related tasks that only deliver their value once they’re all done. At least for something like MIR, it feels to me like “epic” fits what happened there, unless of course we don’t want to evoke over-eager Agile evangelists.

I think I wholeheartedly agree with @brson’s point about the importance of the coherent top-down window, a high-level view where everyone can see what is deemed to be important. Making it more living updates rather than updated at specific intervals also makes sense, although I guess the risk you’re trying to work around is that not everyone will keep it up-to-date.

To me, the most important thing is the prioritization; that the core of the community agrees on what the most important things should be to work on, and, indeed, how casual or new contributors can help out with those. Another important thing, I think, is to make it possible to identify things that have stalled. As an example, especially with Rust’s learning curve (as recently reconfirmed in the survey results), I’m wondering what has happened to the new error format stuff, which seems very valuable from my newbie perspective, but very hard to find/learn about. If we can clearly identify projects that have stalled, we can also take put some extra focus on them to try and resolve the problems.

I also worry about the lack of transparency/feeling of exclusion, but I think it’s largely a problem of communication. I think doing more here on the forums rather than the relatively fragmented/hard to follow GitHub issues flow could help a lot with that.

As for language design/language evolution being slow, I think we should also try to explicitly combat that were relatively conservative/safe ideas exist. For example, thinking of named parameters here, which seems fairly low-risk/high-reward to me.

1 Like
10

You seem to think there's some kind of consensus here :slight_smile:

I personally hate the idea, and I know at least a few core developers do too. That's the issue with "relatively conservative/safe ideas" -- conservative/safe from what angle?

11

Fair enough, it might be a bad example.

12

It seems like there is a core question to be answered here: do we want these roadmaps to be merely a "reflection" of what is happening, or are they something more? I think one of the things that we are currently lacking is a central place to discuss -- and come to consensus on -- what features and changes ought to be priorities. I was hoping that the roadmap could fill this role.

It seems like if the roadmap is merely a snapshot of what is happening, then it is more of a "dashboard", and it will not help us to drive to consensus here. (That said, dashboards and the like seem valuable regardless.) On the other hand, if we have a set time -- like every two cycles -- where we revisit the question, it will be a good opportunity for people to advocate for their favorite ideas, and also give everybody a clear time to consider those questions.

One of the reasons that I prefer having this discussion in a centralized forum, rather than spread out over the individual issues for each initiative, is that it lets us examine tradeoffs and search for interactions more easily. So for example we might all debate whether named parameters are a good choice -- it seems like something that could be done fairly orthogonally. Custom DSTs, on the other hand, are a core-language change, and hence probably have important interactions.

This seems to address @ubsan's core concern:

It seems like there is nothing stopping anyone from doing large amounts of design right now. The very existence of RFC 1524 shows that. But we don't really have a good way to get feedback on the prioritization of an idea, or for feedback on whether the idea is considered to be "on the right track". I think that some of the other proposed changes -- especially pulling out the idea of motivation from other parts of an RFC -- will help a lot here, because it makes it easier to engage with RFCs before they have tons of detail and design behind them. But I can also imagine that being able to raise custom DSTs (say) during a roadmap discussion will be a good opportunity to make the case for why they are important, and see what the community has to say (as well as the lang team, of course).

I am sad that you see the teams as exclusionary. This is not the intention and I think definitely what @aturon's proposals are intending to address. I think the idea of study groups may be a fine thing, but I'm not sure it's necessary: if we succeed in moving all conversations to the open, and have a way to openly discuss priorities, then influencing Rust shouldn't require membership in anything -- study group or otherwise. It should just require showing up and making your case persuasively.

One thing about study groups that I do like was a point @brson made somewhere -- basically that there would be a nice way to get a broader picture of all the people involved in helping shape Rust's future (which I think extends far beyond the subteam members). It seems likely that @aturon's proposals around shepherding help here (they also offer an answer to the important question of what is the pipeline for becoming a subteam member). But I haven't fully dug into those proposals yet so I'll leave that for later.

13

All of this sounds great, but I think the roadmap is the most important part, and the most likely to work without a hitch — this is the low hanging fruit.

I remember after 1.0 came out, there was some murmurs that much language design was going to be put on hold as we focused on cleaning house, namely tool improvements like the MIR, incremental compilation, etc. Even as a language design buff, I was OK with that, because it made sense and it showed other areas (that I am still interested in, yay!) where one can contribute. The MIR is coming along great, but incremental compilation seems stalled, and it is definitely somewhat unclear what are the exact priorities right now.

14

I guess what I really think is stronger than that. I'm not sure this is the best place to discuss it, but I don't actually like the idea of persistent "study groups" (or "strike teams") very much. I think they are too narrow in their focus, and prefer the existing subteams, which intentionally target a broader area. I think this helps a lot with recognizing cross-cutting concerns and well as developing shared vision and values.

(I do think we should work on the pipeline for growing the teams, as I already wrote, to incorporate in some cases a wider diversity of viewpoints, but that is precisely what many of these proposals are about.)

15

See, this is where I disagree. I feel like the current subteams are too broad to do the kinda... down and dirty work. It feels like there should be a bubbling up, so that subteams don't have to focus on everything happening at once. A subteam should only get involved once a proposal is very close to completion, very likely to be accepted. Persistent sub-sub teams (heh) allow for proposals to get better, to get a lot of advice and such from people who are specifically interested in that part of it. For example, a proposal for a new fixed point type could go through a games subsubteam, before eventually going up to the libs team when it's been fully figured out.

The other issue I have is that the subteams feel kind of... forced together into one structure. The Lang and Lib teams are designing Rust-the-language's future; the Compiler Tooling and Infrastructure teams makes sure rustc's compiler and tooling works; and the community and moderation teams shape the community. It feels like there are three classes of subteam, which are very different in scope. It's very... strange, anyways.

16

Not just a snap shot of what is happening but a snapshot of what is being planned. All over the project there are plans in place, just not surfaced (though we need to be more consistent about making plans too). I don't see a great need to 'drive consensus'. The main problem is not that we haven't consulted enough people in making decisions, but that we're not communicating those decisions. Further, by communicating the decisions we are making in one place, it gives those that are out of the loop a venue to express their opinions about those decisions.

1 Like
17

Some thoughts on the roadmap:

  • to me, ‘rallying points’ and roadmaps fulfil different roles - a rallying point is a way to build morale internally, and publicity externally, and to focus work. It must be linked to some time-based event - a specific data (e.g., Rust '17) or event (Rustconf) or release (1.12, 2.0). A roadmap is a way to keep people informed of the community’s priorities and focus and to ensure that (as much as possible) we are all aiming at the same target. Both are important, but I don’t believe there is much cross-over in terms of achieving the different goals.
  • one of the great things about the 1.0 release was that it was a shared goal for the whole community, not just a particular sub-community. By contrast the MIR work was very much the work of the compiler group. Both kinds of initiative have pros and cons, good to note the difference.
  • I think it is important for the roadmaps to cover the low priority items as well as the currently important stuff. This will pre-empt a bunch of less important discussion, shows that topics are not forgotten, and gives the community a place to explain why some topics are considered currently low-priority.
  • I would like to see the roadmap as a ‘living document’ such as a wiki. It should be kept up to date with continuous updates. The 12 week cycle (or whatever) is then not a deadline to release a roadmap, but an opportunity to ensure that the roadmap has been properly kept up to date, nothing has been missed, and to reflect on the work to ensure it is correctly prioritised, etc.
  • The core team should also have a roadmap. This should not be a roadmap for the whole project (maybe that is also nice to have, but I hope it is simply the union of each team’s), instead it should cover the work items which are considered a priority for the core team itself to consider, i.e., those that are too cross-cutting for any one team or that ‘fall between the cracks’ of the sub-teams.
1 Like
18

I’ve been hacking on a prototype tool to support the roadmap, and want to show it to you and get feedback. I’ve tried to reflect my own ideas expressed earlier while incorporating other feedback from this thread, particularly to reflect the process improvements around roadmap planning that @aturon and @nikomatsakis want. My intent here is to suggest a conceptual framework for thinking about how we plan and communicate the roadmap, how we might modify our processes to generate the right kinds of information, and even to pursue the use of the tool.

You’re going to need to dig deep into your imagination because it’s real rough, but the basic shape is there. I suggest you poke around it a bit then come back here and read about what it all means. (Note: this may only work in Firefox ATM - it uses some unstable web APIs :blush:)

Here’s the public interface to the tool: https://brson.github.io/rust-z/

And you might want to look at this page as well which shows a relatively complete set of details for a single project goal.

The rest of this post is discussion about goals, the tool, recommendations for process improvements to support generation of better data for the roadmap. Much of it is duplicated from the README.

Goals of the tool

These are mostly the same as previously posted in this thread.

  • Give users and contributors a picture of what’s happening in Rust and where it’s going.
  • Illuminate current project initiatives and the RFC feature pipeline.
  • Inspire users and contributors with a common vision for the future.
  • Progressive detail - on first glance one should sense the scope of the project, and the key deliverables for the coming releases across all corners of the project. Drilling down, both users and contributors should be able to discover detailed information about the state of the project’s goals.
  • Link all relevant issues, RFCs, pull reuests, etc. associated with any particular feature or initiative.
  • Provide entry points for contributors.
  • Foreshadow future initiatives and features.
  • Demonstrate progress towards the project’s goals.
  • Visualize the finished and unfinished sub-tasks for any particular initiative.
  • Show what’s in the next release.
  • Living updates - everybody can help maintain it.

How does it work?

Fundamentally, this tool helps organize the tracking issues already produced by the Rust development process. Tracking issues of strategic importance are registered with the tool as goals, and they are stated as concrete, limited deliverables. The tool automatically derives important data about the progress of each goal and presents it to the user in a way that is easier to understand than attempting to discover the same information through the usual GitHub, etc. UI.

There are three major components to this:

  • A data schema defined by yaml files in _data, maintained by humans, and in _data/gen, generated by machines.
  • A static webapp that presents that data.
  • A Rust application that keeps the data up to date by scraping sources, and guiding the user to improve the data set.

It is intended that manual curation is kept to a minimum, but achieving that will be an ongoing matter of discovery, tool improvement, and process improvement.

Process implications

Goals (coresponding to tracking issues) are categorized into themes, which represent the overarching direction of the project. These are the subjects that we emphasize most frequently in our PR/marketing/outreach. There are relatively few of them (5-7), and they change infrequently. They tie in to the long ‘narrative arc’ of Rust, and can be decided every 12/18/24/TBD months. We’ll need a process for it that takes a global, long-term view of the project, and allows for participation across the entire project.

Goals are short-term deliverables that should take only a few cycles to complete. They can be established by teams as part of a periodic planning process that does not need to involve the entire project. Goals that go on the roadmap must fit into a theme that serves the project’s long-term ambitions. This potentially gives us a somewhat objective measure of features that are in-scope for consideration during any time period - and a more objective rationale for saying ‘no’, steering our precious resources in the most productive direction.

The quality of information we can present is only as good as the quality of data generated by the Rust development process. In some places - most notably RFC-driven features - that data is quite complete already; in others we’ll need to improve. But hopefully making the changes necessary is mostly a matter of being more consistent in our process, and the tool can be designed to help discover places where the data is poor.

From what I’ve seen so far I think these are the places we need to improve in order to make the right data available:

Tracking issues should be consistently tagged as such. Right now we have B-RFC-approved and B-unstable that can serve this purpose, but they are only used for things that go through the RFC process or are otherwise tagged with stability attributes (i.e. things that go through the ‘feature pipeline’). We need to similarly tag other key tracking issues. We can get by without proper data for this, but then the task of putting ‘goals’ into the tool is dependent on somebody knowing a priori what they are - the tool can’t help ’discover’ goals from the repo.

All tracking issues should be assigned a T- team tag, and preferably assigned to a person so we can list a ‘point of contact’.

All tracking issues that have an associated RFC should mention the RFC number or link in the OP. We’re pretty good about that already.

Tracking issues for tasks with multiple steps should have them tasked out in the OP, and we should lean toward having more subtasks because that lets us give better progress estimates. We sometimes do this now, but not consistently, and they are often not up to date. This is a fair bit of maintenance, but there are things we can do to make it easier.

It’s highly desirable to associate E-easy, E-mentored, etc. issues with tracking issues and their subtasks so we can surface them here and provide strong guidance to contributors. Again the tool can potentially help root these out (e.g. it might ask ‘is this new subtask E-easy?’).

The hardest thing to do is to start estimating the release in which a goal will be completed. We have no system for this at all right now, but one could easily imagine using milestones for it. Obviously estimates are hard, and it will take work to keep up to date, but this is one of the highest-impact data points we can provide for our users and we should try.

Finally, maintaining the roadmap presented by this tool itself will take effort. As part of the process for establishing the roadmap, teams might be strongly encouraged to submit their plans directly to the tool repo, or at least write up descriptions suitable for integration into the tool. The tool must be designed in a way that encourages contribution, and somebody must periodically refresh the data. This is unlikely to become a completely automatable process since the data will never be perfectly reliable.

Additional concepts

The tool is intended to provide ‘progressive detail’ in a few ways. First, it divides both themes and goals into ‘top’ and ‘bottom’. The top goals are displayed by default, but the bottom goals must be toggled on. This allows us to track important work being done that isn’t part of our primary ‘narrative’, without overwhelming on first glance.

Second, both concepts support ‘details’. These are not displayed in e.g. the overview, or the list view of all goals, but are displayed when drilling down to specific goals. Details can also be turned on globally with a toggle.

The tool includes a third, less important concept - ‘problems’. These are areas of improvement that are on our radar, and we want to see solutions to, but have no concrete plans for. This fills a significant gap in our tracking and planning right now, where some important subjects that we talk about a lot informally don’t have a clear place for tracking. Once the solution for any given problem becomes reasonably clear, they can be converted to concrete goals. Examples of these types of topics might be ‘bundling our own linker’, ‘specification’, ‘HKT’.

On terminology

The concepts introduced by this tool, particularly ‘theme’ and ‘tool’, but also ‘problem’, ‘vision statement’, and the name of the tool, are placeholders (the word ‘goal’ in particular is problematic since both the major concepts here could be considered ‘goals’- overloaded word). I much prefer wrapping the tool in an evocative and fun metaphor. I was originally using a war metaphor: ‘battlefronts’ and ’campaigns’; but while it’s powerful, it’s also too antagonistic for an official Rust thing. Other sources of potential metaphors might be exploration, the age of discovery, space travel, etc.

Some examples of evocative words:

  • “north star”
  • “campaign”
  • “quest”
  • “mission”
  • “waypoint”

The concepts here that need names:

  • The overall tool. What is this?
  • The vision statement
  • Themes, the unit used to group tracking issues
  • Goals, the discrete units of work we expect to deliver
  • Problems, areas of interest, on-the-radar subjects, future work
  • Archive, where we celebrate accomplished goals and those who made them happen

Next steps

I’d like to work on an RFC to post in the next few weeks that outlines the roadmap planning process (completely independent of this tool). I suspect it will be pretty simple, mostly establishing the idea of two cadences to the planning process: one long-term (12/18/24) month cycle where we establish high-level goals (‘themes’) for the whole project one short term (quarterly) cycle, wherein the teams establish their deliverables (‘goals’) in service of the long-term objectives. Also, defining what they are expected to produce as a result of the planning process (which we can formulate in a way that works with or without this tool). I’ll be happy to run it by here before submitting it.

OK, that’s a huge amount of stuff to consider. What do you think?

4 Likes
19

Precedence with MIR, we should make it space themed. Calling it. :smile:

But this is cool!

1 Like
20

The Rust Ecosystem as a product

One goal of the platform idea was to emphasize that Rust is much more than rustc, Cargo and std. The arrival of a new async IO library can have as much impact as shipping a new language feature. As a community, we need to make sure we’re thinking clearly about this bigger picture, and organizing our efforts accordingly.

The platform proposal emphasized this bigger picture in a particularly concrete way: by tying together work in many areas into a single deliverable, making the core Rust ecosystem into a coherent product.

Why is that important? As I argued in the original post, planning for the next major release of the platform could serve as a North Star for our work. Articulating what we want the “Rust experience” to be 18 months from now sharpens our focus, and gives us clear rallying points (and a quasi-deadline) for shipping and polishing. It’s what should be informing our roadmap.

Having a concrete “deliverable” seems key, though, for a couple reasons:

  • It makes shipping, and a timeline, much more meaningful, which in turn is a great aid to organizing and focusing our work.

  • It provides a discrete moment in time to gather the “Rust experience” into something coherent, concrete, and polished that we can talk to the world about. It can be very difficult to follow the evolution in dribs and drabs as it happens. Telling our story in coherent, big steps can make a clarifying impact.

These were key aspects of what it meant to ship Rust 1.0, and I think there’s room to find such a rhythm in a repeatable way, establishing a clear narrative about where Rust is going.

The Rust Platform deliverable was mainly the code/metapackage, of course. But ideally at release, we could point to a set of major library improvements, each of which is accompanied with code samples and/or tutorials – essentially answering the question “What does this release mean for me, in concrete terms?”

But assuming we don’t go with the Rust Platform, maybe we can turn this situation on its head: think of the code samples and tutorials that a release enables as being the deliverable we’re aiming at. Rather than being part of a metapackage, the samples can just tell you what to add to your Cargo.toml. In this model, we could set out a vision for Rust and its ecosystem a regular cadence (say, a year), and at the end of that period ship such a “Report on Rust”, announcing what was accomplished with links to samples and HOWTOs. That gives us a clear rallying point as a community, something to work toward all year, and a way to meaningfully showcase Rust’s evolution in big, discrete steps. But it’s more open-ended, less heavy-handed than curating and packaging particular crates.

To be really concrete, I could imagine setting out as part of the vision for a year to “advance Rust’s HTTP sever story”, with that concretely turning into a community-wide push to help get Hyper to 1.0, to generate good samples and tutorials for it, and to build a larger ecosystem around it – all in time for the next “Report on Rust”.

I’ve been working with @brson on the roadmap proposal, and some of these ideas are present in his recent post. This thinking is at a pretty early stage, but I’m hoping we can iterate on it on discuss and, if successful, include it in the forthcoming RFC establishing the roadmap process.

3 Likes