Skip to content

Commit

Permalink
Update north star RFC
Browse files Browse the repository at this point in the history
- 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
  • Loading branch information
brson committed Sep 1, 2016
1 parent 2832657 commit 7355498
Showing 1 changed file with 77 additions and 70 deletions.
147 changes: 77 additions & 70 deletions text/0000-north-star.md
Original file line number Diff line number Diff line change
Expand Up @@ -14,10 +14,9 @@ Rust's roadmap will be established in year-long cycles, where we identify up
front - together, as a project - the most critical problems facing the language
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 quarterly milestones,
and where these goals result in stable features the Rust version in which they
become stable will be estimated as well.
decided by the individual teams, as they see fit, and regularly re-triaged. For
the purposes of reporting the project roadmap, goals will be assigned to release
cycle milestones.

At the end of the year we will deliver a public facing retrospective, describing
the goals we achieved and how to use the new features in detail. It will
Expand Down Expand Up @@ -115,12 +114,12 @@ the way we work today.

Rust's roadmap will be established in year-long cycles, where we identify up
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 _quarterly milestones_, and where
these goals result in stable features the Rust version in which they become
stable will be estimated as well. Along the way, teams will be expected to
maintain _tracking issues_ that communicate progress toward the project's goals.
statements_. Work toward solving those problems, _goals_, will be planned as
part of the release cycles by individual teams. For the purposes of reporting
the project roadmap, goals will be assigned to _release cycle milestones_, which
represent the primary work performed each release cycle. Along the way, teams
will be expected to maintain _tracking issues_ that communicate progress toward
the project's goals.

At the end of the year we will deliver a public facing retrospective, which is
intended as a 'rallying point'. Its primary purposes are to create anticipation
Expand Down Expand Up @@ -156,20 +155,25 @@ Key terminology used in this RFC:
celebrating those who contribute to achieving the project's goals and
resolving it's problems.

- _quarterly milestone_ - All goals have estimates for completion, placed on
quarterly milestones. Each quarter that a goal remains incomplete it must be
re-triaged and re-estimated by the responsible team.

## The big planning cycle (problem statements and the north star RFC)

The big cycle spans one year. At the beginning of the cycle we identify areas of
Rust that need the most improvement, and at the end of the cycle is a 'rallying
point' where we deliver to the world the results of our efforts. We choose
year-long cycles because a year is enough time to accomplish relatively large
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.
- _release cycle milestone_ - All goals have estimates for completion, placed on
milestones that correspond to the 6 week release cycle. These milestones are
timed to corrspond to a release cycle, but don't represent a specific
release. That is, work toward the current nightly, the current beta, or even
that doesn't directly impact a specific release, all goes into the release
cycle milestone corresponding to the time period in which the work is
completed.

## Problem statements and the north star RFC

The full planning cycle spans one year. At the beginning of the cycle we
identify areas of Rust that need the most improvement, and at the end of the
cycle is a 'rallying point' where we deliver to the world the results of our
efforts. We choose year-long cycles because a year is enough time to accomplish
relatively large 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 planning effort is _problem-oriented_. Focusing on "how" may seem like an
obvious thing to do, but in practice it's very easy to become enamored of
Expand Down Expand Up @@ -234,45 +238,63 @@ the rust-lang/rust issue tracker and tagged `R-problem-statement`. In the OP of
each metabug the teams are responsible for maintaining a list of their goals,
linking to tracking issues.

## The little planning cycle (goals and tracking progress)

The little cycle is where the solutions take shape and are carried out. They
last one quarter - 3 months - and are the responsibility of individual teams.

Each cycle the teams will have one week to update their set of _goals_. This
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.

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.

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
subdivided into smaller goals of less than a quarter, each with their own
estimates. These estimates are used to place goals onto quarterly milestones.

Not all the work items done by teams in a quarter should be considered a goal
nor should they be. Goals only need to be granular enough to demonstrate
consistent progress toward solving the project's problems. Work that
contributes toward quarterly goals should still be tracked as sub-tasks of
those goals, but only needs to be filed on the issue tracker and not reported
directly as goals on the roadmap.
Like other RFCs, the north star RFC is not immutable, and if new motivations
arise during the year, it may be amended, even to the extent of adding
additional problem statements; though it is not appropriate for the project
to continually rehash the RFC.

## Goal setting and tracking progress

During the regular 6-week release cycles is where the solutions take shape and
are carried out. Each cycle teams are expected to set concrete _goals_ that work
toward solving the project's stated problems; and to review and revise their
previous goals. The exact forum and mechanism for doing this evaluation and
goal-setting is left to the individual teams, and to future experimentation,
but the end result is that each release cycle each team will document their
goals and progress in a standard format.

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. Not all the work items done by teams in a quarter should be
considered a goal. Goals only need to be granular enough to demonstrate
consistent progress toward solving the project's problems. Work that contributes
toward quarterly goals should still be tracked as sub-tasks of those goals, but
only needs to be filed on the issue tracker and not reported directly as goals
on the roadmap.

For each goal the teams will create an issue on the issue tracker tagged with
`R-goal`. Each goal must be described in a single sentence summary with an
end-result or deliverable that is as crisply stated as possible. Goals with
sub-goals and sub-tasks must list them in the OP in a standard format.

During each planning period all goals must be triaged and updated for the
following information:
During each cycle all `R-goal` and `R-unstable` issues assigned to each team
must be triaged and updated for the following information:

- The set of sub-goals and sub-tasks and their status
- The estimated date of completion
- The release cycle milestone

Goals that will be likely completed in this cycle or the next should be assigned
to the appropriate milestone. Some goals may be expected to be completed in
the distant future, and these do not need to be assigned a milestone.

The release cycle milestone corresponds to a six week period of time and
contains the work done during that time. It does not correspend to a specific
release, nor do the goals assigned to it need to result in a stable feature
landing in any specific release.

Release cycle milestones serve multiple purposes, not just tracking of the goals
defined in this RFC: `R-goal` tracking, tracking of stabilization of
`R-unstable` and `R-RFC-approved` features, tracking of critical bug fixes.

Though the release cycle milestones are time-oriented and are not strictly tied
to a single upcoming release, from the set of assigned `R-unstable` issues one
can derive the new features landing in upcoming releases.

During the last week of every release cycle each team will write a brief
report summarizing their goal progress for the cycle. Some project member
will compile all the team reports and post them to internals.rust-lang.org.
In addition to providing visibility into progress, these will be sources
to draw from for the subsequent release announcements.

## The retrospective (rallying point)

Expand Down Expand Up @@ -303,21 +325,6 @@ Since the retrospective must be a high-quality document, and cover a lot of
material, it is expected to require significant planning, editing and revision.
The details of how this will work are to be determined.

## Release estimation

The teams are responsible for estimating only the _timeframe_ in which they
complete their work, but possibly the single most important piece of information
desired by users is to know _in what release_ any given feature will become
available.

To reduce process burden on team members we will not require them to make that
estimate themselves; the teams will work purely in terms of quarterly
milestones. Instead, we will have a separate process to map the goals and time
estimates into release estimates for individual features - a process that is
likely automatable.

The precise mechanics are to be determined.

## Presenting the roadmap

As a result of this process the Rust roadmap for the year is encoded in three
Expand Down

0 comments on commit 7355498

Please sign in to comment.