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

Conversation

Projects
None yet
@brson
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 23, 2016

Member

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.

Member

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

Show outdated Hide outdated text/0000-north-star.md
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

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

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

Show outdated Hide outdated text/0000-north-star.md
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

@kennytm

kennytm Aug 23, 2016

Member

uncertainty

Show outdated Hide outdated text/0000-north-star.md
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

@kennytm

kennytm Aug 23, 2016

Member

management

Show outdated Hide outdated text/0000-north-star.md
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

@kennytm

kennytm Aug 23, 2016

Member

quarterly

Show outdated Hide outdated text/0000-north-star.md
- 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

@kennytm

kennytm Aug 23, 2016

Member

difficult

Show outdated Hide outdated text/0000-north-star.md
[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

kennytm Aug 23, 2016

Member

solely

@kennytm

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Aug 23, 2016

Member

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?

Member

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

This comment has been minimized.

Show comment
Hide comment
@tomaka

tomaka 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?

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

This comment has been minimized.

Show comment
Hide comment
@steveklabnik

steveklabnik Aug 23, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2016

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@joshtriplett

joshtriplett Aug 23, 2016

Member

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.

Member

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.

Show outdated Hide outdated text/0000-north-star.md
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

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

@durka

durka Aug 23, 2016

Contributor

RFC ready for FCP?

@larsbergstrom

This comment has been minimized.

Show comment
Hide comment
@larsbergstrom

larsbergstrom 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!

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

This comment has been minimized.

Show comment
Hide comment
@nagisa

nagisa Aug 23, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Aug 23, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@djc

djc Aug 23, 2016

Contributor

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.

Contributor

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.

Show outdated Hide outdated text/0000-north-star.md
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.

@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

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

@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

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.

@brson

brson Aug 23, 2016

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.

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

Show outdated Hide outdated text/0000-north-star.md
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?

@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

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.

@brson

brson Aug 23, 2016

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.

Show outdated Hide outdated text/0000-north-star.md
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

@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

Contributor

Yep. Will fix.

@brson

brson Aug 23, 2016

Contributor

Yep. Will fix.

Show outdated Hide outdated text/0000-north-star.md
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.

@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

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.

@brson

brson Aug 23, 2016

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.

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

Show outdated Hide outdated text/0000-north-star.md
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

@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

Contributor

@nrc Agree this is awkward.

@brson

brson Aug 23, 2016

Contributor

@nrc Agree this is awkward.

Show outdated Hide outdated text/0000-north-star.md
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?

@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

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.

@brson

brson Aug 23, 2016

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

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

Show outdated Hide outdated text/0000-north-star.md
to be front-loaded with 'problems'. Likewise, 'goal' and 'retrospective' could
be more colorful.
Can we call the yearly RFC the 'north start RFC'? Too many concepts?

This comment has been minimized.

@nrc

nrc Aug 23, 2016

Member

typo: s/start/star

@nrc

nrc Aug 23, 2016

Member

typo: s/start/star

This comment has been minimized.

@nrc

nrc Aug 23, 2016

Member

On the name itself, I don't think "north star" is the most obvious metaphor, I would prefer a plain name, rather than a metaphorical one.

@nrc

nrc Aug 23, 2016

Member

On the name itself, I don't think "north star" is the most obvious metaphor, I would prefer a plain name, rather than a metaphorical one.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 23, 2016

Contributor

Typos fixed. Thanks @kennytm. You are a master proofreader. Someday I will learn to run spellcheck.

Contributor

brson commented Aug 23, 2016

Typos fixed. Thanks @kennytm. You are a master proofreader. Someday I will learn to run spellcheck.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 23, 2016

Member

I have uncertainty about the direction of information flow for the yearly stuff. It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities. That seems a better way to come up with reasonable problem statements, rather than asking the whole community what is an issue and then have the sub-teams/communities deal with fallout.

Part of my reasoning here is that in reality, there are very few cross-cutting issues. Looking at the sample list of problem statements, the only one that concerns more than one team in any meaningful way is the async I/O one. Given this lack of cross-cutting issues, it seems that a smaller, more focussed discussion with more specific expertise will do a better job at identifying problems than a larger, less focussed discussion.

  • 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
  • Rust plugins have no clear path to stabilization
  • Rust doesn't integrate well with garbage collectors
  • Rust's trait system doesn't fully support zero-cost abstractions
  • The Rust community is insufficiently diverse
  • Rust needs more training materials
  • Rust's CI infrastructure is unstable
  • It's too hard to obtain Rust for the platforms people want to target
Member

nrc commented Aug 23, 2016

I have uncertainty about the direction of information flow for the yearly stuff. It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities. That seems a better way to come up with reasonable problem statements, rather than asking the whole community what is an issue and then have the sub-teams/communities deal with fallout.

Part of my reasoning here is that in reality, there are very few cross-cutting issues. Looking at the sample list of problem statements, the only one that concerns more than one team in any meaningful way is the async I/O one. Given this lack of cross-cutting issues, it seems that a smaller, more focussed discussion with more specific expertise will do a better job at identifying problems than a larger, less focussed discussion.

  • 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
  • Rust plugins have no clear path to stabilization
  • Rust doesn't integrate well with garbage collectors
  • Rust's trait system doesn't fully support zero-cost abstractions
  • The Rust community is insufficiently diverse
  • Rust needs more training materials
  • Rust's CI infrastructure is unstable
  • It's too hard to obtain Rust for the platforms people want to target
@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 23, 2016

Contributor

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?

@kennytm The timing will be awkward this year. If we can get this RFC into a shape approaching consensus by September, then I think it would be reasonable to informally start talking about problem statements for the coming year with the anticipation of this RFC merging. Exact timing could be fudged a bit, but I could imagine e.g. talking about the problem statements in irlo for the first 2 weeks of September so that basically everybody is onboard for a north star RFC the third week. I believe that would fit more-or-less into the timing as stated in the current draft, but it's clearly all very tight timing.

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?

@tomaka The RFC does intentionally leave it a bit squishy for experimentation. I would expect the core team to seed the discussion in a useful direction, b that direction to not be a surprise to anybody, and would only expect that to be a starting point for discussion. I think it would be good, e.g. to start the discussion on irlo, with somebody from the core team saying 'this is how we see the situation, how do you?'. Then taking that feedback to an RFC, perhaps in the second week of September in the proposed timeline.

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?".

@joshtriplett Added.

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.

@larsbergstrom These seems similar to the proposed problem statements in their intent to focus direction and creating ability to say 'no'. Difference seems to me that this RFC doesn't leave room for specific goals without timetables.

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.

@larsbergstrom Similar sentiments have been expressed by several. The way I see that quarterly subdivision is that it is just a convenient subdivision that doesn't require too much thought - if things get done faster then great, estimate it at quarterly-resolution and finish it early. Most important that team members periodically confront the reality of shipping on some schedule. One aspect of the quarterly number not emphasized is that the mechanics of estimation involve putting issues on GitHub milestones, so we can't allow arbitrary estimation - we can only have so many milestones.

We could reconsider whether milestones make sense for time estimates. It makes a lot of sense for release number estimates - but in the current draft I had to sacrifice release estimate milestones for quarterly milestones since issues only get one.

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?"

@larsbergstrom I agree this is an important question to answer. In my earlier thinking I had more ambitious plans about how to tackle this by surfacing E-easy/help-wanted issues through the roadmapped tracking issues, but have kinda punted. I'm hopeful that just having a funnel to the most important issues, plus a mandate to task them out better, will be a good step.

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

@nagisa I agree there's quite some risk. Especially if we get through the full year and nobody comes through with a high-quality retrospective, that would be very bad.

Regarding trial runs, it's fine by me, as long as we agree to commit to improvements in some way and try to carry them out. The actual merging of an RFC is somewhat secondary to getting things done.

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.

@djc Yeah holidays are really slow. This RFC specs a planning week for January 1, which is rough.

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)

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

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

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

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.

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

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

@nrc Agree this is awkward.

Please forgive me for duplicating some of my responses both here and inline with the text.

Contributor

brson commented Aug 23, 2016

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?

@kennytm The timing will be awkward this year. If we can get this RFC into a shape approaching consensus by September, then I think it would be reasonable to informally start talking about problem statements for the coming year with the anticipation of this RFC merging. Exact timing could be fudged a bit, but I could imagine e.g. talking about the problem statements in irlo for the first 2 weeks of September so that basically everybody is onboard for a north star RFC the third week. I believe that would fit more-or-less into the timing as stated in the current draft, but it's clearly all very tight timing.

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?

@tomaka The RFC does intentionally leave it a bit squishy for experimentation. I would expect the core team to seed the discussion in a useful direction, b that direction to not be a surprise to anybody, and would only expect that to be a starting point for discussion. I think it would be good, e.g. to start the discussion on irlo, with somebody from the core team saying 'this is how we see the situation, how do you?'. Then taking that feedback to an RFC, perhaps in the second week of September in the proposed timeline.

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?".

@joshtriplett Added.

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.

@larsbergstrom These seems similar to the proposed problem statements in their intent to focus direction and creating ability to say 'no'. Difference seems to me that this RFC doesn't leave room for specific goals without timetables.

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.

@larsbergstrom Similar sentiments have been expressed by several. The way I see that quarterly subdivision is that it is just a convenient subdivision that doesn't require too much thought - if things get done faster then great, estimate it at quarterly-resolution and finish it early. Most important that team members periodically confront the reality of shipping on some schedule. One aspect of the quarterly number not emphasized is that the mechanics of estimation involve putting issues on GitHub milestones, so we can't allow arbitrary estimation - we can only have so many milestones.

We could reconsider whether milestones make sense for time estimates. It makes a lot of sense for release number estimates - but in the current draft I had to sacrifice release estimate milestones for quarterly milestones since issues only get one.

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?"

@larsbergstrom I agree this is an important question to answer. In my earlier thinking I had more ambitious plans about how to tackle this by surfacing E-easy/help-wanted issues through the roadmapped tracking issues, but have kinda punted. I'm hopeful that just having a funnel to the most important issues, plus a mandate to task them out better, will be a good step.

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

@nagisa I agree there's quite some risk. Especially if we get through the full year and nobody comes through with a high-quality retrospective, that would be very bad.

Regarding trial runs, it's fine by me, as long as we agree to commit to improvements in some way and try to carry them out. The actual merging of an RFC is somewhat secondary to getting things done.

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.

@djc Yeah holidays are really slow. This RFC specs a planning week for January 1, which is rough.

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)

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

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

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

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.

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

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

@nrc Agree this is awkward.

Please forgive me for duplicating some of my responses both here and inline with the text.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 23, 2016

Contributor

It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities.

Keen observation. The question of how the discussion is seeded is fairly crucial to starting on the right foot and not getting bogged down in bikesheds.

Contributor

brson commented Aug 23, 2016

It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities.

Keen observation. The question of how the discussion is seeded is fairly crucial to starting on the right foot and not getting bogged down in bikesheds.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 24, 2016

Member

Lots of good replies/questions -- I want to follow up on a bunch later, but had time for one in particular right now. There have been a couple questions related to the core team's role with the yearly planning:

@tomaka

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?

@nrc

It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities. That seems a better way to come up with reasonable problem statements, rather than asking the whole community what is an issue and then have the sub-teams/communities deal with fallout.

It seems that each of you came away with opposite perspectives on what the RFC was suggesting here. So let me give a bit more detail on how we envision this working in practice.

In the run-up to the yearly planning period, we would undergo some specific data-gathering exercises -- like the survey and production user outreach -- to help inform the initial pitch as well as the general discussion. The subteams would hold specific discussions teasing out their thoughts. Then the subteam leaders, in conjunction with the rest of the core team, would digest this detailed picture into a smaller set of initial problem statements to propose.

All of that would happen prior to September. At the start of the month, the core team would make an internals post with a list of some candidate problem statements -- likely a too-long list. The community would discuss there, until at some point things reach a steady enough state to open an actual RFC.

So the core team facilitates and leads the discussion, but there's plenty of scope for everyone to make a case.

@nrc

Part of my reasoning here is that in reality, there are very few cross-cutting issues.

That might, or might not, be true in terms of implementation, but this planning process is inherently cross-cutting: it's about surfacing the most important problems that face Rust users in general, that stand in the way of Rust's adoption and success. You don't have to be on the tools team to have a stake in IDE support. And in some sense the lang team is ill-equipped to propose the biggest lang problems to solve -- what you really want is to hear from users about what corners of the language give them problems.

One of the core team's foundational roles is precisely to track these kinds of concerns, to "think big" and help lay out a vision for the project as a whole. As such, the team spends a lot of time talking to a wide variety of users or pre-users, paying attention to complaints across the community, and generally trying to read the tea leaves for where we can have the most impact. In terms of "information flow", we've tried to set things up specifically so that the core team is well informed on these issues, and their role is to provide leadership on them.

So it's a balance -- there's an opportunity for feedback and influence, including prior to an RFC even being written -- but we make the core team responsible for taking the lead in data gathering, outreach, digestion, and some initial proposals.

Member

aturon commented Aug 24, 2016

Lots of good replies/questions -- I want to follow up on a bunch later, but had time for one in particular right now. There have been a couple questions related to the core team's role with the yearly planning:

@tomaka

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?

@nrc

It seems that the sub-teams and their respective sub-communities are the best place to start, and then the whole community/core team should sanity check the results and decide on relative priorities. That seems a better way to come up with reasonable problem statements, rather than asking the whole community what is an issue and then have the sub-teams/communities deal with fallout.

It seems that each of you came away with opposite perspectives on what the RFC was suggesting here. So let me give a bit more detail on how we envision this working in practice.

In the run-up to the yearly planning period, we would undergo some specific data-gathering exercises -- like the survey and production user outreach -- to help inform the initial pitch as well as the general discussion. The subteams would hold specific discussions teasing out their thoughts. Then the subteam leaders, in conjunction with the rest of the core team, would digest this detailed picture into a smaller set of initial problem statements to propose.

All of that would happen prior to September. At the start of the month, the core team would make an internals post with a list of some candidate problem statements -- likely a too-long list. The community would discuss there, until at some point things reach a steady enough state to open an actual RFC.

So the core team facilitates and leads the discussion, but there's plenty of scope for everyone to make a case.

@nrc

Part of my reasoning here is that in reality, there are very few cross-cutting issues.

That might, or might not, be true in terms of implementation, but this planning process is inherently cross-cutting: it's about surfacing the most important problems that face Rust users in general, that stand in the way of Rust's adoption and success. You don't have to be on the tools team to have a stake in IDE support. And in some sense the lang team is ill-equipped to propose the biggest lang problems to solve -- what you really want is to hear from users about what corners of the language give them problems.

One of the core team's foundational roles is precisely to track these kinds of concerns, to "think big" and help lay out a vision for the project as a whole. As such, the team spends a lot of time talking to a wide variety of users or pre-users, paying attention to complaints across the community, and generally trying to read the tea leaves for where we can have the most impact. In terms of "information flow", we've tried to set things up specifically so that the core team is well informed on these issues, and their role is to provide leadership on them.

So it's a balance -- there's an opportunity for feedback and influence, including prior to an RFC even being written -- but we make the core team responsible for taking the lead in data gathering, outreach, digestion, and some initial proposals.

@nrc

This comment has been minimized.

Show comment
Hide comment
@nrc

nrc Aug 24, 2016

Member

In the run-up to the yearly planning period, we would undergo some specific data-gathering exercises -- like the survey and production user outreach -- to help inform the initial pitch as well as the general discussion. The subteams would hold specific discussions teasing out their thoughts.

This sounds good to me and pretty close to what I was suggesting

Then the subteam leaders, in conjunction with the rest of the core team, would digest this detailed picture into a smaller set of initial problem statements to propose.

This, on the other hand, doesn't make sense to me, given the example problem statements. And it gets back to the cross-cutting point - if we expect that the core team takes a problem stmt from team a and team b and make a single problem stmt out of it, then it would be fine. But given the examples (and thinking in general about what we're working on in Rust right now), that doesn't seem likely. It seems more like you'll take two stmts from team a and make a single stmt, and it seems that team a would be better qualified to do that than the core team. Anyway, this seems like a relatively small procedural point in the grand scheme of things, and I'm sure either way will work in practice.

You don't have to be on the tools team to have a stake in IDE support.

True, but I would expect the tools team to be the best people at weighing the relative priority of IDE support vs debugger support vs some new thing that only tools nerds might have heard about, based on the needs and reports of users.

And in some sense the lang team is ill-equipped to propose the biggest lang problems to solve -- what you really want is to hear from users about what corners of the language give them problems.

Agreed, but this doesn't really suggest anything cross-cutting to me. Users talk about language issues and the lang team should listen and then make decisions about the language. There doesn't seem to be much that cross-cuts (or whatever the verb is).

In terms of "information flow", we've tried to set things up specifically so that the core team is well informed on these issues, and their role is to provide leadership on them.

Getting off topic, sorry. This just makes me sad. I'd much rather the core team did more to share this information so the sub-teams and others can do more leadership in their own areas.

Member

nrc commented Aug 24, 2016

In the run-up to the yearly planning period, we would undergo some specific data-gathering exercises -- like the survey and production user outreach -- to help inform the initial pitch as well as the general discussion. The subteams would hold specific discussions teasing out their thoughts.

This sounds good to me and pretty close to what I was suggesting

Then the subteam leaders, in conjunction with the rest of the core team, would digest this detailed picture into a smaller set of initial problem statements to propose.

This, on the other hand, doesn't make sense to me, given the example problem statements. And it gets back to the cross-cutting point - if we expect that the core team takes a problem stmt from team a and team b and make a single problem stmt out of it, then it would be fine. But given the examples (and thinking in general about what we're working on in Rust right now), that doesn't seem likely. It seems more like you'll take two stmts from team a and make a single stmt, and it seems that team a would be better qualified to do that than the core team. Anyway, this seems like a relatively small procedural point in the grand scheme of things, and I'm sure either way will work in practice.

You don't have to be on the tools team to have a stake in IDE support.

True, but I would expect the tools team to be the best people at weighing the relative priority of IDE support vs debugger support vs some new thing that only tools nerds might have heard about, based on the needs and reports of users.

And in some sense the lang team is ill-equipped to propose the biggest lang problems to solve -- what you really want is to hear from users about what corners of the language give them problems.

Agreed, but this doesn't really suggest anything cross-cutting to me. Users talk about language issues and the lang team should listen and then make decisions about the language. There doesn't seem to be much that cross-cuts (or whatever the verb is).

In terms of "information flow", we've tried to set things up specifically so that the core team is well informed on these issues, and their role is to provide leadership on them.

Getting off topic, sorry. This just makes me sad. I'd much rather the core team did more to share this information so the sub-teams and others can do more leadership in their own areas.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Aug 24, 2016

Contributor

@nrc the overall goal of the early part of the process, from my perspective, is a loose discussion that starts with some seeding of goals from the core team and subteams, but is mostly a way for people with thoughts on what we might spend time on to jump in and offer their thoughts.

The intent is a quite lightweight process, where community members and people who have time to do some implementation work can do some brainstorming about what the main problems facing the project are.

A subteam-driven process (as you're envisioning) seems far for formal to me: it requires someone with an idea to figure out which subteam to pitch it to, which might often be met with a "not our domain" response. This would be even more annoying and complicated for cross-cutting issues. If our goal is to spur a discussion about what the Rust project should focus its time on, even that kind of thing can easily suck the oxygen out of an enthusiastic idea.

I also second @aturon's point that this process is somewhat intrinsically cross-cutting. It's true that a number of ideas won't have an immediately obvious "home" at first, and it's also true that a discussion about what the project should focus its time on is somewhat intrinsically cross-cutting.

But perhaps more important, the focus on identifying problems rather than implementation strategies will naturally produce discussions that require help from multiple specialties.

For example, if a problem is "Rust lifetimes are too hard to understand", it's useful to flesh out the nature of the problem before we decide whether it makes sense to tackle it via docs, an --explain mode in rustc, language changes that could simplify the use of lifetimes, or perhaps even other solutions.

To make the discussions as inclusive as possible (and we really want this: Rust beginners have valuable insights into many problem areas that are hard to arrive at synthetically), we should defer process or implementation questions until there's a shared sense (across many kinds of Rust users) about what the problem actually is.

That's why I think it makes sense to start with a discussion about what problems people think we should be solving, rather than driving the discussion through ideas bubbled up through subteams.

Contributor

wycats commented Aug 24, 2016

@nrc the overall goal of the early part of the process, from my perspective, is a loose discussion that starts with some seeding of goals from the core team and subteams, but is mostly a way for people with thoughts on what we might spend time on to jump in and offer their thoughts.

The intent is a quite lightweight process, where community members and people who have time to do some implementation work can do some brainstorming about what the main problems facing the project are.

A subteam-driven process (as you're envisioning) seems far for formal to me: it requires someone with an idea to figure out which subteam to pitch it to, which might often be met with a "not our domain" response. This would be even more annoying and complicated for cross-cutting issues. If our goal is to spur a discussion about what the Rust project should focus its time on, even that kind of thing can easily suck the oxygen out of an enthusiastic idea.

I also second @aturon's point that this process is somewhat intrinsically cross-cutting. It's true that a number of ideas won't have an immediately obvious "home" at first, and it's also true that a discussion about what the project should focus its time on is somewhat intrinsically cross-cutting.

But perhaps more important, the focus on identifying problems rather than implementation strategies will naturally produce discussions that require help from multiple specialties.

For example, if a problem is "Rust lifetimes are too hard to understand", it's useful to flesh out the nature of the problem before we decide whether it makes sense to tackle it via docs, an --explain mode in rustc, language changes that could simplify the use of lifetimes, or perhaps even other solutions.

To make the discussions as inclusive as possible (and we really want this: Rust beginners have valuable insights into many problem areas that are hard to arrive at synthetically), we should defer process or implementation questions until there's a shared sense (across many kinds of Rust users) about what the problem actually is.

That's why I think it makes sense to start with a discussion about what problems people think we should be solving, rather than driving the discussion through ideas bubbled up through subteams.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Aug 24, 2016

Contributor

@larsbergstrom said:

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?"

I strongly agree with this, and I think that it's easy to forget that while there are many people who want to provide input into the project's plans, quite a few people are enthusiastic to contribute and just want to know what makes sense to work on.

The "north star" approach lets people who want to suggest problems to work on, people with ideas, people with time (and all of the shades of grey that of course exist) to have a conversation together about what makes the most sense to work on.

Contributor

wycats commented Aug 24, 2016

@larsbergstrom said:

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?"

I strongly agree with this, and I think that it's easy to forget that while there are many people who want to provide input into the project's plans, quite a few people are enthusiastic to contribute and just want to know what makes sense to work on.

The "north star" approach lets people who want to suggest problems to work on, people with ideas, people with time (and all of the shades of grey that of course exist) to have a conversation together about what makes the most sense to work on.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 30, 2016

Member

I wanted to address a few of the remaining concerns around cadence, and particularly the "little cycle" (for setting goals).

@larsbergstrom points out that having an "over-arching", non-time-specific direction can also be important, especially for saying "no" to big projects. I definitely agree! I expected this kind of vision to play a role in how we choose the problem statements for the year, but it wasn't clear to what degree it should be formalized as part of the process. It might be worth trying the problem statement planning once, and seeing how best to structure that discussion/rationale, then revising this RFC accordingly.

I think there was also some confusion about the aims of the various cycles. In summary:

  • The "big" (yearly) cycle is about layout out the most important problems we want to tackle over a long enough period of time that we can make some serious progress. It's also about having fixed a point of internal accountability and external communication. Of course we'll celebrate major accomplishments as they happen, but pulling a year's worth of work together into a coherent narrative is an important way to talk to the larger world about how Rust is evolving, and to celebrate the totality of what we've accomplished together.
  • The "small" (quarterly) cycle is about coordinating the concrete work of the subteams toward our larger goals. It fleshes out the detailed, concrete steps we're taking to make sure we achieve our year's goals. It's not intended for wide consumption, though it's useful for contributors who want to know what's going on right now and find places to pitch in.

@nrc also raised some questions about the team goal-setting process -- in particular, having it be continuously updated. In my mind, this should definitely be happening. The formal process is just ensuring that the whole team regularly steps back and triages the goals against the problem statements, often while laying out a plan for the quarter. IOW, there's a regular planning process, but we keep the goals up to date with reality as the quarter progresses.

Part of the work of goal setting is deciding on concrete steps we're going to take to work toward solving one of the year's problem statements. That might be "prototype X" or "write RFC for Y". At the least, we should communicate these plans (but any version of the goal trackers will do so).

The RFC proposes a week-long period for getting feedback about these plans before "locking in" the goals. I agree with @nrc that it's not clear how this is going to work.

I've been talking with @brson and others about possibly changing the "short cycle" cadence to be release-aligned -- so, six weeks long. The idea would be that, at all times, the repo has a milestone for the next beta release (which is what nightly will turn into). This milestone would contain:

  • All tracking issues for features in FCP for that release;
  • All R-Goal issues where we expect completion during that release cycle;
  • Any P-high regressions or other issues that need to be fixed before we cut the beta.

Note that an R-Goal issue being assigned to a milestone doesn't mean anything about a feature shipping; the goal issue might for posting an RFC, or doing a particular bit of community outreach. The release here is acting as a convenient way of talking about time (and should be tagged with the date of the release as well).

Each release cycle, the subteams would do triage, which includes both moving features into FCP and breaking down R-Goal issues into a list of what they want to tackle that cycle. The result of that triage would take effect immediately (by putting things onto the milestone, etc), but would also be written up in an internals post to ensure visibility. That should make clear what's on the docket.

Doing this every six weeks makes me queasy about overhead, but note that we're already doing FCP triage on this cadence, and even if we're working with quarterly goals, we're going to need more frequent check-ins. The hope is that we can keep this very lightweight, and planning in terms of these shorter periods is easier to do.

Even if we do stick with a quarterly cadence, I think having release milestones is a good idea (since several things we want to track must be release-aligned). Quarterly planning could just map quarterly goals onto expected release cycle.

I also feel like there are enough unknowns about the goal-setting process that we might want to leave it a bit under-specified in this RFC -- basically, set up the milestones and the R-Goal hierarchy, but allow the subteams to iterate on the precise process and cadence of triaging those goals.

I think most people agree that attempting to give release estimates for every feature, no matter where it is in the pipeline, is not workable. As above, I think we should move strongly in the opposite direction: use milestones for tracking what we plan to do for the next release cycle, and nothing more. In particular, when tracking issues come up for FCP, they can be tagged with this milestone, which will ensure we're recording the stabilization/deprecation version info.

One final note: we've been employing a variant of this process for the past year+. In particular, the Rust in 2016 post laid out the problems we wanted to solve this year, and the Mozilla team does quarterly planning in terms of what each person is trying to get done. We've even recently tried doing this tracking on github. So we're not going into this totally blind.

Member

aturon commented Aug 30, 2016

I wanted to address a few of the remaining concerns around cadence, and particularly the "little cycle" (for setting goals).

@larsbergstrom points out that having an "over-arching", non-time-specific direction can also be important, especially for saying "no" to big projects. I definitely agree! I expected this kind of vision to play a role in how we choose the problem statements for the year, but it wasn't clear to what degree it should be formalized as part of the process. It might be worth trying the problem statement planning once, and seeing how best to structure that discussion/rationale, then revising this RFC accordingly.

I think there was also some confusion about the aims of the various cycles. In summary:

  • The "big" (yearly) cycle is about layout out the most important problems we want to tackle over a long enough period of time that we can make some serious progress. It's also about having fixed a point of internal accountability and external communication. Of course we'll celebrate major accomplishments as they happen, but pulling a year's worth of work together into a coherent narrative is an important way to talk to the larger world about how Rust is evolving, and to celebrate the totality of what we've accomplished together.
  • The "small" (quarterly) cycle is about coordinating the concrete work of the subteams toward our larger goals. It fleshes out the detailed, concrete steps we're taking to make sure we achieve our year's goals. It's not intended for wide consumption, though it's useful for contributors who want to know what's going on right now and find places to pitch in.

@nrc also raised some questions about the team goal-setting process -- in particular, having it be continuously updated. In my mind, this should definitely be happening. The formal process is just ensuring that the whole team regularly steps back and triages the goals against the problem statements, often while laying out a plan for the quarter. IOW, there's a regular planning process, but we keep the goals up to date with reality as the quarter progresses.

Part of the work of goal setting is deciding on concrete steps we're going to take to work toward solving one of the year's problem statements. That might be "prototype X" or "write RFC for Y". At the least, we should communicate these plans (but any version of the goal trackers will do so).

The RFC proposes a week-long period for getting feedback about these plans before "locking in" the goals. I agree with @nrc that it's not clear how this is going to work.

I've been talking with @brson and others about possibly changing the "short cycle" cadence to be release-aligned -- so, six weeks long. The idea would be that, at all times, the repo has a milestone for the next beta release (which is what nightly will turn into). This milestone would contain:

  • All tracking issues for features in FCP for that release;
  • All R-Goal issues where we expect completion during that release cycle;
  • Any P-high regressions or other issues that need to be fixed before we cut the beta.

Note that an R-Goal issue being assigned to a milestone doesn't mean anything about a feature shipping; the goal issue might for posting an RFC, or doing a particular bit of community outreach. The release here is acting as a convenient way of talking about time (and should be tagged with the date of the release as well).

Each release cycle, the subteams would do triage, which includes both moving features into FCP and breaking down R-Goal issues into a list of what they want to tackle that cycle. The result of that triage would take effect immediately (by putting things onto the milestone, etc), but would also be written up in an internals post to ensure visibility. That should make clear what's on the docket.

Doing this every six weeks makes me queasy about overhead, but note that we're already doing FCP triage on this cadence, and even if we're working with quarterly goals, we're going to need more frequent check-ins. The hope is that we can keep this very lightweight, and planning in terms of these shorter periods is easier to do.

Even if we do stick with a quarterly cadence, I think having release milestones is a good idea (since several things we want to track must be release-aligned). Quarterly planning could just map quarterly goals onto expected release cycle.

I also feel like there are enough unknowns about the goal-setting process that we might want to leave it a bit under-specified in this RFC -- basically, set up the milestones and the R-Goal hierarchy, but allow the subteams to iterate on the precise process and cadence of triaging those goals.

I think most people agree that attempting to give release estimates for every feature, no matter where it is in the pipeline, is not workable. As above, I think we should move strongly in the opposite direction: use milestones for tracking what we plan to do for the next release cycle, and nothing more. In particular, when tracking issues come up for FCP, they can be tagged with this milestone, which will ensure we're recording the stabilization/deprecation version info.

One final note: we've been employing a variant of this process for the past year+. In particular, the Rust in 2016 post laid out the problems we wanted to solve this year, and the Mozilla team does quarterly planning in terms of what each person is trying to get done. We've even recently tried doing this tracking on github. So we're not going into this totally blind.

@brson

This comment has been minimized.

Show comment
Hide comment
@brson

brson Aug 30, 2016

Contributor

The idea would be that, at all times, the repo has a milestone for the next beta release (which is what nightly will turn into).

I think it's problematic to think of this milestone in terms of a single release, since the things on it serve multiple purposes (goal completion, feature stabilization, critical bug fixing - which could even be beta bugs for the next release). It's easier to me to think of it as just a 6 week block of time. In this irlo post that reuses this milestone concept for release-critical bugs I propose an example name "2016-08-18 - 2016-09-29 (nightly-1.13 / beta-1.12)", which is horribly unwieldy, but unambiguous.

Doing this every six weeks makes me queasy about overhead, but note that we're already doing FCP triage on this cadence

The libs team is, I think the lang and compiler team are; tools, community and docs don't have this practice and will be taking on new overhead.

It looks to me like the changes to be made are:

  • The little goal setting cycle is 6 weeks to correspond to the release cycle
  • R-goal issues don't need estimates
  • R-goal issues and feature tracking issues for completion this quarter go onto the release milestone
  • Goal setting begins at the beginning of every quarter, triage is expected to be continuous, but the exact process is unspecified. Let's see how it works.

What else?

It's unclear to me whether we need to make changes to the text about how the big planning process is kicked off. It's also unclear to me whether to specify that R-problem-statement, R-goal issues live on rust-lang/rust or in a new repo. If they live in their own repo then they can't share milestones with feature tracking issues and feature-tracking issues can't directly be goals.

Because we want to try this process in September, we need to move fast to come to agreement here, but I'm a bit uneasy about it. While I believe all the team leads are aware of this and the impact it will have on their process, I don't know that the team members more broadly realize what is happening. It's also not obvious to me that we must have this RFC merged before starting discussions about the direction of the project (talking about problems facing Rust is a reasonable thing to do regardless of a sanctioned process).

What are the next steps?

Contributor

brson commented Aug 30, 2016

The idea would be that, at all times, the repo has a milestone for the next beta release (which is what nightly will turn into).

I think it's problematic to think of this milestone in terms of a single release, since the things on it serve multiple purposes (goal completion, feature stabilization, critical bug fixing - which could even be beta bugs for the next release). It's easier to me to think of it as just a 6 week block of time. In this irlo post that reuses this milestone concept for release-critical bugs I propose an example name "2016-08-18 - 2016-09-29 (nightly-1.13 / beta-1.12)", which is horribly unwieldy, but unambiguous.

Doing this every six weeks makes me queasy about overhead, but note that we're already doing FCP triage on this cadence

The libs team is, I think the lang and compiler team are; tools, community and docs don't have this practice and will be taking on new overhead.

It looks to me like the changes to be made are:

  • The little goal setting cycle is 6 weeks to correspond to the release cycle
  • R-goal issues don't need estimates
  • R-goal issues and feature tracking issues for completion this quarter go onto the release milestone
  • Goal setting begins at the beginning of every quarter, triage is expected to be continuous, but the exact process is unspecified. Let's see how it works.

What else?

It's unclear to me whether we need to make changes to the text about how the big planning process is kicked off. It's also unclear to me whether to specify that R-problem-statement, R-goal issues live on rust-lang/rust or in a new repo. If they live in their own repo then they can't share milestones with feature tracking issues and feature-tracking issues can't directly be goals.

Because we want to try this process in September, we need to move fast to come to agreement here, but I'm a bit uneasy about it. While I believe all the team leads are aware of this and the impact it will have on their process, I don't know that the team members more broadly realize what is happening. It's also not obvious to me that we must have this RFC merged before starting discussions about the direction of the project (talking about problems facing Rust is a reasonable thing to do regardless of a sanctioned process).

What are the next steps?

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 31, 2016

Member

@brson

It's easier to me to think of it as just a 6 week block of time.

Yes, I agree -- I kind of muddled this. I think it might be most clear if the milestone was tagged only with the end date and the beta release that will occur on that date.

It looks to me like the changes to be made are ...

That certainly covers the things I mentioned, which I think addresses most of the concerns that have been raised.

I just want to note that the outcome here, specifically, is that goals are mapped onto six-week-long milestones, and triage/planning is happening at least quarterly, but we're leaving it up to the subteams how they keep the goals up to date, how they do (and announce) the triage, and whether there are additional times that triage takes place. I think that's a pretty good move that will give each team flexibility to find the right way of managing the process.

It's unclear to me whether we need to make changes to the text about how the big planning process is kicked off.

I don't think so -- I don't particularly think it needs to be formalized beyond what's already in the text.

If they live in their own repo then they can't share milestones with feature tracking issues and feature-tracking issues can't directly be goals.

Yes, and I think that's a deal-breaker. It's very appealing to have a single milestone per cycle that gathers all of the work we are trying to get done, and can be kept up to date. This will always want to include "normal" issues so that we can flag P-High regressions and so on.

Because we want to try this process in September, we need to move fast to come to agreement here, but I'm a bit uneasy about it.

FWIW, it seems so far that most everyone is excited about the overall goals and ideas here, and most discussion has centered around the fine points. I think with what you've summarized, we'll be making a good step toward addressing the worries there as well.

It's also not obvious to me that we must have this RFC merged before starting discussions about the direction of the project

Definitely! I think we can and should start the problem statement thread ASAP, regardless of the status of this RFC. I think it's also OK if the process slips a bit beyond September this time around. But I also think we're not far off from consensus here.

What are the next steps?

Making the updates you laid out is a good immediate step. It also seems like doing another round of advertising, perhaps mailing team@, would be helpful to make sure we're getting enough eyeballs on this discussion.

Member

aturon commented Aug 31, 2016

@brson

It's easier to me to think of it as just a 6 week block of time.

Yes, I agree -- I kind of muddled this. I think it might be most clear if the milestone was tagged only with the end date and the beta release that will occur on that date.

It looks to me like the changes to be made are ...

That certainly covers the things I mentioned, which I think addresses most of the concerns that have been raised.

I just want to note that the outcome here, specifically, is that goals are mapped onto six-week-long milestones, and triage/planning is happening at least quarterly, but we're leaving it up to the subteams how they keep the goals up to date, how they do (and announce) the triage, and whether there are additional times that triage takes place. I think that's a pretty good move that will give each team flexibility to find the right way of managing the process.

It's unclear to me whether we need to make changes to the text about how the big planning process is kicked off.

I don't think so -- I don't particularly think it needs to be formalized beyond what's already in the text.

If they live in their own repo then they can't share milestones with feature tracking issues and feature-tracking issues can't directly be goals.

Yes, and I think that's a deal-breaker. It's very appealing to have a single milestone per cycle that gathers all of the work we are trying to get done, and can be kept up to date. This will always want to include "normal" issues so that we can flag P-High regressions and so on.

Because we want to try this process in September, we need to move fast to come to agreement here, but I'm a bit uneasy about it.

FWIW, it seems so far that most everyone is excited about the overall goals and ideas here, and most discussion has centered around the fine points. I think with what you've summarized, we'll be making a good step toward addressing the worries there as well.

It's also not obvious to me that we must have this RFC merged before starting discussions about the direction of the project

Definitely! I think we can and should start the problem statement thread ASAP, regardless of the status of this RFC. I think it's also OK if the process slips a bit beyond September this time around. But I also think we're not far off from consensus here.

What are the next steps?

Making the updates you laid out is a good immediate step. It also seems like doing another round of advertising, perhaps mailing team@, would be helpful to make sure we're getting enough eyeballs on this discussion.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 31, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Aug 31, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Sep 1, 2016

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 1, 2016

Member

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.

Member

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.

Update north star RFC
- 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

This comment has been minimized.

Show comment
Hide comment
@brson

brson Sep 1, 2016

Contributor

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 1, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Sep 20, 2016

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot 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 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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Oct 21, 2016

All relevant subteam members have reviewed. No concerns remain.

rfcbot commented Oct 21, 2016

All relevant subteam members have reviewed. No concerns remain.

@aturon

This comment has been minimized.

Show comment
Hide comment
@aturon

aturon Oct 21, 2016

Member

🔔 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!

Member

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

This comment has been minimized.

Show comment
Hide comment
@rfcbot

rfcbot Oct 31, 2016

The final comment period is now complete.

rfcbot commented Oct 31, 2016

The final comment period is now complete.

@nikomatsakis

This comment has been minimized.

Show comment
Hide comment
@nikomatsakis

nikomatsakis Nov 11, 2016

Contributor

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

Contributor

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 referenced this pull request Dec 30, 2016

Closed

Document all features in the reference #38643

0 of 17 tasks complete

phaazon pushed a commit to phaazon/rfcs that referenced this pull request Feb 10, 2017

@chriskrycho chriskrycho referenced this pull request Mar 11, 2017

Closed

Document all features #9

18 of 48 tasks complete

@aturon aturon referenced this pull request Jan 30, 2018

Merged

RFC: Rust 2018 Roadmap #2314

@3442853561

This comment has been minimized.

Show comment
Hide comment
@3442853561

3442853561 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)?

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

This comment has been minimized.

Show comment
Hide comment
@kennytm

kennytm Jan 30, 2018

Member

@3442853561 Command Line Interface.

Member

kennytm commented Jan 30, 2018

@3442853561 Command Line Interface.

@3442853561

This comment has been minimized.

Show comment
Hide comment
@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