A process for establishing the Rust roadmap #1728
Conversation
|
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
added
the
T-core
| 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, |
There was a problem hiding this comment.
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"
|
Sorry for the spelling stuff but the word "dificult" is too glaring in my eyes 😜
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? |
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? |
|
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. |
|
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. |
|
I really like this proposal. While I do think that this could lead to bikeshedding, I like the idea of defining the largest problems and most important goals facing the Rust community, as a target to work towards. This absolutely does need to remain problem-oriented; the north_star RFC should almost never say "we need to implement X"; instead, it should say "we need a solution to this problem". "Hold off on proposing solutions" applies heavily here; we want people thinking in many different directions, and coming up with novel solutions, not immediately latching onto a single solution. To avoid repeatedly editing the north_star RFC for a given year, it shouldn't become a clearing-house for links to the active work on those problems. But we should probably have a tracking issue or internals thread that does serve as such a clearing-house, with people posting links to relevant RFCs, discussions, or prototypes. (I hesitate to suggest a tracking issue, because a north_star RFC might contain problems that don't end up solved or change and become a different problem, in which case when can we close the tracking issue?) I don't think we should hesitate to propose problems for north_star that we don't know how to solve, but that we know we need some solution for. |
|
|
||
| The north star RFC development happens during the month of September, starting | ||
| September 1 and ending by October 1. This means that an RFC must be ready for | ||
| RFC by the last week of September. We choose september for two reasons: it is |
There was a problem hiding this comment.
Nit: Capitalization for September
|
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.
Hope this helps! |
|
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. |
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. :) |
|
FWIW, at work, we had a quarterly release cycle, and moved away from it in part because at least for us, it unevenly penalizes the Q1 and Q3 releases due to holidays. We have now moved to a Feb/Jun/Oct release schedule, which is one less release and therefore slightly longer cycles, which we found helpful, and make the big holidays (especially in northern hemisphere summer, for us at least) a bit less impactful. I think the Mercurial release schedule shifted to a similar cadence for similar reasons. YMMV. |
| decided in quarter-long cycles by individual teams. For the purposes of | ||
| reporting the project roadmap, goals will be assigned to quartely milestones, | ||
| and where these goals result in stable features the Rust version in which they | ||
| become stable will be estimated as well. |
There was a problem hiding this comment.
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.
I agree, and these kinds of shifts definitely do happen (including de-prioritizing work we thought was important). |
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. |
|
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:
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:
I'm excited about these directions. |
|
It's Sept 1, and I've posted a kick-off discussion for the 2017 cycle's North Star. As @brson pointed out, that discussion is useful regardless of this RFC, and can proceed in parallel. I think it's also useful to see this concrete example as we try to finalize the process. On that note: one difference in the writeup from what this RFC proposes is that it's oriented around "vision statements" rather than "problem statements". I found that this worked better as a way of writing/thinking, leading to an inspiring vision of where Rust could be a year from now, rather than a depressing littany of all our problems today. I think it's very important that the discussion stay problem-focused and not try to nail down too much of the technical solutions, but having the final artifact be a year vision feels really good to me. |
- Use 6-week cycles - Don't require time estimates - Do require release cycle milestone estimates - Add language about amending the north star RFC - Require 6-week status reports from teams
|
I've amended the text to reflect these changes:
|
|
@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. |
|
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 |
|
Team member aturon has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. See this document for info about what commands tagged team members can give me. |
aturon
added
the
final-comment-period
|
All relevant subteam members have reviewed. No concerns remain. |
|
🔔 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! |
|
The final comment period is now complete. |
|
Looks like it's time to accept this RFC! Especially as the process is well underway. =) |
|
Excuse me, what is CLI? It mean Command Line Interface(like cmd on Windows) or Common Language Infrastructure(like CLR or Mono)? |
|
@3442853561 Command Line Interface. |
|
@kennytm Thanks! |
Centril
added
A-meta
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:
Rendered.