Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

A process for establishing the Rust roadmap #1728

Merged
merged 8 commits into from Nov 12, 2016
Merged

Conversation

@brson
Copy link
Contributor

@brson brson commented Aug 23, 2016

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
Copy link
Member

@aturon aturon commented Aug 23, 2016

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.

@aturon aturon added the T-core label Aug 23, 2016
and its ecosystem, along with the story we want to be able to tell the world
about Rust. Work toward solving those problems, our short-term goals, will be
decided in quarter-long cycles by individual teams. For the purposes of
reporting the project roadmap, goals will be assigned to quartely milestones,

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

quarterly

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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"


The changes proposed here are intended to work with the particular strengths of
our project - community development, collaboration, distributed teams, loose
management structure, constant change and uncertanty. It should introduce

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

uncertainty

minimal additional burden on Rust team members, who are already heavily
overtasked. The proposal does not attempt to solve all problems of project
management in Rust, nor to fit the Rust process into any particular project
mamnagement structure. Let's make a few incremental improvements that will have

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

management

front the most critical problems facing the project, formulated as _problem
statements_. Work toward solving those problems, _goals_, will be planned in
quarter-long cycles by individual teams. For the purposes of reporting the
project roadmap, goals will be assigned to _quartely milestones_, and where

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

quarterly

- The Rust compiler is too slow for a tight edit-compile-test cycle
- Rust lacks world-class IDE support
- The Rust story for asynchronous I/O is very primitive
- Rust compiler errors are dificult to understand

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

difficult

[alternatives]: #alternatives

Instead of imposing further process structure on teams we might attempt to
derive a roadmap soley from the data they are currently producing.

This comment has been minimized.

@kennytm

kennytm Aug 23, 2016
Member

solely

@kennytm
Copy link
Member

@kennytm kennytm commented Aug 23, 2016

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
Copy link

@tomaka tomaka commented Aug 23, 2016

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
Copy link
Member

@steveklabnik steveklabnik commented Aug 23, 2016

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
Copy link
Member

@joshtriplett joshtriplett commented Aug 23, 2016

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
Copy link
Member

@joshtriplett joshtriplett commented Aug 23, 2016

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.


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. We choose september for two reasons: it is

This comment has been minimized.

@frewsxcv

frewsxcv Aug 23, 2016
Member

Nit: Capitalization for September

This comment has been minimized.

@durka

durka Aug 23, 2016
Contributor

RFC ready for FCP?

@larsbergstrom
Copy link

@larsbergstrom larsbergstrom commented Aug 23, 2016

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
Copy link
Contributor

@nagisa nagisa commented Aug 23, 2016

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
Copy link
Contributor

@nikomatsakis nikomatsakis commented Aug 23, 2016

@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
Copy link
Contributor

@djc djc commented Aug 23, 2016

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.

decided in quarter-long cycles by individual teams. For the purposes of
reporting the project roadmap, goals will be assigned to quartely milestones,
and where these goals result in stable features the Rust version in which they
become stable will be estimated as well.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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.

the goals we achieved and how to use the new features in detail. It will
celebrate the year's progress toward our goals, as well as the achievements of
the wider community. It will evaluate our performance and anticipate its impact
on the coming year.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

This on the other hand, sounds excellent

so that everybody understands the direction the project is taking. These are
used as the broad basis for decision making throughout the year, and are
captured in the yearly "north star RFC", and tagged `R-problem-statement`
on the issue tracker.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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)

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

@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.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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.

goals; and because having the rallying point occur at the same time every year
makes it easy to know when to anticipate big news from the project. Being
calendar-based avoids the temptation to slip or produce feature-based releases,
instead providing a fixed point of accountability for shipping.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

@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.

calendar-based avoids the temptation to slip or produce feature-based releases,
instead providing a fixed point of accountability for shipping.

This planning effort is _problem-oriented_. Focusing on "why" may seem like an

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

Yep. Will fix.

includes both creating new goals and reviewing and revising existing goals. A
goal describes a task that contributes to solving the year's problems. It may or
may not involve a concrete deliverable, and it may be in turn subdivided into
further goals.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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.

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

@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.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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.

The social process of the quarterly planning cycle is less strict, but it
should be conducted in a way that allows open feedback. It is suggested that
teams present their quarterly plan on internals.rust-lang.org at the beginning
of the week, solicit feedback, then finalize them at the end of the week.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

@nrc Agree this is awkward.


All goals have estimated completion dates. There is no limit on the duration of
a single goal, but they are encouraged to be scoped to less than a quarter year
of work. Goals that are expected to take more than a quarter _must_ be

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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

This comment has been minimized.

@brson

brson Aug 23, 2016
Author Contributor

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.

This comment has been minimized.

@nrc

nrc Aug 23, 2016
Member

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
Copy link
Member

@aturon aturon commented Aug 31, 2016

@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
Copy link
Member

@aturon aturon commented Aug 31, 2016

@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
Copy link
Contributor

@nikomatsakis nikomatsakis commented Sep 1, 2016

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
Copy link
Member

@aturon aturon commented Sep 1, 2016

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.

- 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
@brson
Copy link
Contributor Author

@brson brson commented Sep 1, 2016

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
Copy link
Member

@aturon aturon commented Sep 1, 2016

@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
Copy link
Member

@aturon aturon commented Sep 20, 2016

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
Copy link

@rfcbot rfcbot commented Sep 20, 2016

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

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
Copy link

@rfcbot rfcbot commented Oct 21, 2016

All relevant subteam members have reviewed. No concerns remain.

@aturon
Copy link
Member

@aturon aturon commented Oct 21, 2016

🔔 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
Copy link

@rfcbot rfcbot commented Oct 31, 2016

The final comment period is now complete.

@nikomatsakis
Copy link
Contributor

@nikomatsakis nikomatsakis commented Nov 11, 2016

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

@nikomatsakis nikomatsakis merged commit 7355498 into rust-lang:master Nov 12, 2016
@chriskrycho chriskrycho mentioned this pull request Dec 30, 2016
0 of 17 tasks complete
phaazon pushed a commit to phaazon/rfcs that referenced this pull request Feb 10, 2017
@chriskrycho chriskrycho mentioned this pull request Mar 11, 2017
18 of 48 tasks complete
@aturon aturon mentioned this pull request Jan 30, 2018
@3442853561
Copy link

@3442853561 3442853561 commented Jan 30, 2018

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

@kennytm
Copy link
Member

@kennytm kennytm commented Jan 30, 2018

@3442853561 Command Line Interface.

@3442853561
Copy link

@3442853561 3442853561 commented Jan 30, 2018

@kennytm Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

You can’t perform that action at this time.