A process for establishing the Rust roadmap

[brson]

A refinement of the Rust planning and reporting process, to establish a shared
vision of the project among contributors, to make clear the roadmap toward that
vision, and to celebrate our achievements.

The primary outcome for these changes to the process are that we will have a
consistent way to:

• Decide our project-wide goals through consensus.
• Advertise our goals as a published roadmap.
• Celebrate our achievements with an informative publicity-bomb.

Rendered.

[aturon]

This is the follow-up to the roadmap discussion; we've worked out many more of the details, and @brson has brought them to life in this vivid writeup.

[kennytm]

quarterly

[nrc]

At a project-level, I'm not sure how useful it is to set quarterly milestones - these things are hard to estimate and we only risk bad publicity and disappointment for not meeting them. I'd rather see relative time estimates of goals, i.e., "you can expect to see feature a delivered before feature b, and feature a is a high priority"

[kennytm]

uncertainty

[kennytm]

management

[kennytm]

quarterly

[kennytm]

difficult

[kennytm]

solely

[kennytm]

Sorry for the spelling stuff but the word "dificult" is too glaring in my eyes 😜

The north star RFC development happens during the month of September, starting September 1 and ending by October 1. This means that an RFC must be ready for RFC by the last week of September.

Considering it is almost end of August now, do we have time to merge this RFC #1728 and also reach consensus for the North Star of 2017 in just 5 weeks?

[tomaka]

This planning takes place via the RFC process and is open to the entire community.

If I understand correctly, someone on the core team decide on a set of problems, then opens an RFC about it, and then the discussion starts? Can community members suggest problems as well?

[steveklabnik]

In my understanding, anyone can suggest problems; it's the core team's jobs to take that big set of problems, suggest an initial set of them to kick off the conversation about this year's set of them, and then we all discuss and go from there.

[joshtriplett]

The questions section mentions "Are 1 year cycles long enough?"; I'd also suggest discussing "Are 1 year cycles too long?". In particular, I'd like to see this RFC answer the question "What happens if something important to the ecosystem comes up in October?".

If that happens, and consensus agrees that the new problem needs the Rust community to work together towards it, I'd think that we might want to amend that year's north_star RFC to add that additional problem.

[joshtriplett]

I really like this proposal.

While I do think that this could lead to bikeshedding, I like the idea of defining the largest problems and most important goals facing the Rust community, as a target to work towards. This absolutely does need to remain problem-oriented; the north_star RFC should almost never say "we need to implement X"; instead, it should say "we need a solution to this problem". "Hold off on proposing solutions" applies heavily here; we want people thinking in many different directions, and coming up with novel solutions, not immediately latching onto a single solution.

To avoid repeatedly editing the north_star RFC for a given year, it shouldn't become a clearing-house for links to the active work on those problems. But we should probably have a tracking issue or internals thread that does serve as such a clearing-house, with people posting links to relevant RFCs, discussions, or prototypes. (I hesitate to suggest a tracking issue, because a north_star RFC might contain problems that don't end up solved or change and become a different problem, in which case when can we close the tracking issue?)

I don't think we should hesitate to propose problems for north_star that we don't know how to solve, but that we know we need some solution for.

[frewsxcv]

Nit: Capitalization for September

[durka]

RFC ready for FCP?

[larsbergstrom]

This looks neat! There are a few things that have been really useful to us and things we've learned over the few years that I've been maintaining Servo' roadmap that might or might not be useful to you here.

• Much larger, over-arching goals that define the direction of the project without a definite timeline help. Having those two for Servo has given us the ability to say "no" to otherwise potentially attractive things that would nonetheless have tied up the core team with competing efforts. In Rust's world, I could see things like feel like "language feature parity with {SML, Scheme, Common LISP, Haskell}" as being similar tempting but slippery slopes. Or help with pushing back on Servo's requests 😄
• Quarterly feels too frequent; yearly too short. Most "big" things end up taking a non-aligned quarter-ish and end up being independently celebrated when they are completed rather than rolled-up at the end of the quarter. Quarters are useful for planning and BigCo HR stuff, but haven't provided us any value outside of that.
• Part of what many people are looking into with a roadmap is "what are the major volunteers and full-time staff actively working on, so I could join the party and know my work won't be ignored?" For Servo, we've been pretty bad about getting our major volunteers reported in our Roadmap, and I'm reluctant to put people on-the-hook like that, but we've definitely talked about how to increase their visibility, too. It also has really helped to reduce some of the needless hierarchy, which manifested as, "ask larsberg/jack on IRC what is going on with {X}" and has let other people have more visible ownership.

Hope this helps!

[nagisa]

I’m generally against process RFCs, because it is hard to be sure about whether the proposed process will or will not work. Before this process RFC is accepted and implemented I’d like to see at least two trial runs of the process; perhaps on a smaller scale (e.g. 3 months each, involving only a few teams). In case we accept this RFC and then decide the process is not for us, we’ll have wasted a long time implementing the proposed process (i.e. building tooling for it, thinking up the problems/goals etc) and maybe some extra effort following through it; all ending up in us abandoning the process altogether.

[nikomatsakis]

@nagisa

I’m generally against process RFCs, because it is hard to be sure about whether the proposed process will or will not work.

I don't really understand what makes process RFCs so different in this respect. Plenty of technical RFCs, even those that try to be very thorough, encounter problems during implementation and must be amended (or abandoned).

I don't see why we would want to just launch into some process without talking it over -- there's a good chance we can avoid some obvious pitfalls right from the start, or just find a better way of doing things.

My view of the RFC process is that it is used to achieve consensus on an initial stab at how to solve a problem. We discuss alternatives, tweak the idea where possible, and then -- if we still like it -- give it a try for a while. If we are happy, we "stabilize" (in this case, that probably just means "keep on doing it"). Seems like this general procedure fits process RFCs pretty well. :)

[djc]

FWIW, at work, we had a quarterly release cycle, and moved away from it in part because at least for us, it unevenly penalizes the Q1 and Q3 releases due to holidays. We have now moved to a Feb/Jun/Oct release schedule, which is one less release and therefore slightly longer cycles, which we found helpful, and make the big holidays (especially in northern hemisphere summer, for us at least) a bit less impactful. I think the Mercurial release schedule shifted to a similar cadence for similar reasons. YMMV.

[nrc]

It seems wildly optimistic that we will be able to do this for all but the smallest features or those very late in development. I.e., it might make sense to do this for features that are implemented and waiting to stabilise, but not before then.

[nrc]

This on the other hand, sounds excellent

[nrc]

Which repo are you proposing using the issue tracker on? Rust, RFCs, something new? (I would like something new - I feel the existing repos are already overloaded)

[brson]

@nrc I'd propose rust-lang/rust, but a new repo is also fine by me. My preference is that they be in one repo though and we not try to split these issues across repos. With all 'goals' in a single repo though necessarily some of the work will be done to complete those goals in other repos, which is kind of strange.

[nrc]

some of the work will be done to complete those goals in other repos, which is kind of strange.

This doesn't seem too strange to me - in particular GH is quite good at cross-referencing issues between repos.

[nrc]

Is there any kind of release associated with the yearly cycle, or is it just a punctuation thing?

[brson]

@nrc No special releases besides the retrospective. If we ever get to point where we are ready to do LTS or larger-scope "platform" releases that could fill a similar role.

[nrc]

Do you mean "how" rather than "why" here? Thinking about "why" seems important

[brson]

Yep. Will fix.

[nrc]

I much prefer a model where the teams update goals throughout the quarter and then have a week to reflect and confirm the goals. This allows more flexibility and less artificial time-boxing.

[brson]

@nrc Would the goals come with time estimates? One of my main objectives is to be able to project out estimates for when each individual feature will hit a stable release, with the expectation that the initial estimate would be poor, and through reestimates would get more accurate as the release approaches. Secondarily, periodically writing down estimates is good for a sense of urgency.

[nrc]

My preference would be for 'no', but that isn't intrinsic to my 'continuous update' model.

I generally feel that bad time estimates are worse than no estimates, but I can understand disagreement there.

[nrc]

A week seems very quick for this, in particular if a team is expected to post goals at the start of the week that implies some time before the week begins to discuss amongst the team

[brson]

@nrc Agree this is awkward.

[nrc]

encouraged and must seem to be in contradiction here - is it a firm rule or not?

[brson]

Hm, I don't see the contradiction. I'm trying to say that small goals are best, but if you must make long goals, then subdivide them into small goals.

[nrc]

The contradiction is in the mandatory-ness of the rule/guideline (in my reading). I.e., is it merely encouraged that goals be < 1/4 or is it required.

I think I understand what you mean, which is that we should choose small goals, but if we can't manage that, then they must be split up into sub-goals. I guess the repeated use of "goal" in the text makes this hard to understand (for me).

[aturon]

@joshtriplett

I'd like to see this RFC answer the question "What happens if something important to the ecosystem comes up in October?".

If that happens, and consensus agrees that the new problem needs the Rust community to work together towards it, I'd think that we might want to amend that year's north_star RFC to add that additional problem.

I agree, and these kinds of shifts definitely do happen (including de-prioritizing work we thought was important).

[aturon]

@nrc

I think I understand what you mean, which is that we should choose small goals, but if we can't manage that, then they must be split up into sub-goals.

Yes, that's the intent.

The core idea here is that we're planning and executing work each "little cycle", so goals that are actively being worked on should have at least some component that's on the current milestone, i.e. an increment we can accomplish during the little cycle.

The expectation, I think, is that we'll have a (hopefully shallow) hierarchy flowing down from the problem statements into increasingly granular goals, terminating at cycle-length goals on the current milestone.

[nikomatsakis]

Argh. So I've been writing and re-writing a comment that I never finish and then which keeps getting lost. Let me try to write a shorter version that I actually get done in one sitting.

I feel pretty good about aligning more with the release cycle. I like the idea that, every release, the teams will get together and do a kind of "release triage", with the goal of assessing:

• what is the motion towards our Big Goals?
• what concrete steps can we identify?
  • in particular, which of these steps provide good mentoring opportunities for people who want to get involved in Rust?
• what unstable features can we move towards stabilization?
• how have we done with other high-priority bugs and so forth (of course we are also monitoring those as we go)?

From this we can then produce a brief "team status report" -- this would supercede the old weekly reports which didn't work that well. It'd be less frequent and focused on the big goals, and hence a lot more interesting. This could then go into the release announcement, maybe, or else onto an internals post.

At least in the @rust-lang/compiler and @rust-lang/lang teams, I see many parts of the current weekly meetings being transformed into more async processes:

• for rfc decision making, we've been moving towards the "async" process discussed on internals. We hope to have bots and other tools but for now we're just doing it manually. It already feels great.
• for triage, the new triage meeting supercedes a lot of that activity, and I hope that we can do lighter-weight check-ins, as well as using some of the async process mechanics to drive things a bit more naturally that way as well.

I'm excited about these directions.

[aturon]

It's Sept 1, and I've posted a kick-off discussion for the 2017 cycle's North Star. As @brson pointed out, that discussion is useful regardless of this RFC, and can proceed in parallel. I think it's also useful to see this concrete example as we try to finalize the process.

On that note: one difference in the writeup from what this RFC proposes is that it's oriented around "vision statements" rather than "problem statements". I found that this worked better as a way of writing/thinking, leading to an inspiring vision of where Rust could be a year from now, rather than a depressing littany of all our problems today. I think it's very important that the discussion stay problem-focused and not try to nail down too much of the technical solutions, but having the final artifact be a year vision feels really good to me.

[brson]

I've amended the text to reflect these changes:

• Use 6-week cycles
• Don't require time estimates
• Do require release cycle milestone estimates
• Add language about amending the north star RFC
• Require 6-week status reports from teams

[aturon]

@brson Changes look great! I think we're getting to a pretty clear picture on the mechanics here.

Remaining open question: do all the goal issues live in the main repo or elsewhere? I previously noted that having a single milestone for ALL project goals is appealing, but e.g. the community team already has their own tracker, and a tool like rusty-dash could aggregate milestones across the org into a single "burn-down" view.

Having these live in their own repo could make it a lot easier for people to track goal-level activity in the project.

[aturon]

Discussion here has reached a steady state, and I believe that all of the big concerns have been addressed; the first planning discussion is ongoing. There are a few remaining minor open questions, e.g., about which repo to use for goal tracking, but I don't think those need to block the RFC.

@rfcbot fcp merge

[rfcbot]

Team member aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• @alexcrichton
• @aturon
• @brson
• @erickt
• @nikomatsakis
• @pcwalton
• @steveklabnik
• @wycats

No concerns currently listed.
Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[rfcbot]

All relevant subteam members have reviewed. No concerns remain.

[aturon]

🔔 This RFC is moving into its final comment period, with disposition to merge. 🔔

Note that we will likely want to iterate on the precise way we triage the roadmap into cycle-length goals and so on, but at this point there seems to be widespread agreement on the broad outlines of this plan.

In addition, the first actual roadmap RFC has now been posted!

[rfcbot]

The final comment period is now complete.

[nikomatsakis]

Looks like it's time to accept this RFC! Especially as the process is well underway. =)

[3442853561]

Excuse me, what is CLI? It mean Command Line Interface(like cmd on Windows) or Common Language Infrastructure(like CLR or Mono)?

[kennytm]

@3442853561 Command Line Interface.

[3442853561]

@kennytm Thanks!