leadership-council icon indicating copy to clipboard operation
leadership-council copied to clipboard

Project roadmap strategy

Open ehuss opened this issue 11 months ago • 1 comments

RFC #1728 started a roadmap process that was carried out from 2017-2021.

  • 2017: https://rust-lang.github.io/rfcs/1774-roadmap-2017.html
  • 2018: https://rust-lang.github.io/rfcs/2314-roadmap-2018.html
  • 2019: https://rust-lang.github.io/rfcs/2657-roadmap-2019.html
  • 2020: https://rust-lang.github.io/rfcs/2857-roadmap-2020.html
  • 2021: https://rust-lang.github.io/rfcs/3037-roadmap-2021.html

Should we continue this? If so, how? What parts of this are useful? Should there be an overall roadmap, or should teams own their own roadmap? Who is responsible for running this?

Some crude thoughts of my own:

  • Carefully present things so they don't appear as deliverables for the year, but instead as these are things teams are specifically working on right now and have people actually doing stuff.
  • Difficult to plan out 1 year in advance. Work is very ephemeral in an open source project with volunteers. Roadmaps don't capture things that start in the middle of the year that weren't planned ahead of time.
  • Aspirational items are pretty useless, since they usually don't get started.
  • Vague platitudes like "Rust should be easier to learn" are also useless, since they don't point to specific people doing specific things.
  • It is difficult to tell teams what they should be doing, since they may not necessarily want to follow whatever priorities the council suggests. It also seems unlikely that there is enough overlap between teams for those priorities to matter.

ehuss avatar Aug 08 '23 22:08 ehuss