有名的开源社区是如何运营的? Roadmap 篇

本文调研：

• 开源项目如何管理roadmap
• 如何决策哪些需求做、哪些不做
• 如何决策要做的需求中，哪个优先级更高?
• 怎么做项目管理

# Dapr

https://github.com/dapr/dapr/issues/3335

如何管理roadmap

用一个 github project 管理所有版本的 roadmap，每个 issue 上通过 milestone 标记“预计哪个版本发布”

Q: bug fix,chore 会被放进roadmap吗
看起来不会

• Q: 社区会议在其中起到的作用?

如何决策哪些需求做、哪些不做

判断一个需求(issue) 做不做的标准是民主投票(在issue上点👍），投票越多优先级越高，投票多的会被放进 Roadmap 的Backlog栏。
Roadmap 有很多阶段:

• Backlog
• Planned (Committed)
  Once a GitHub issue (feature) has a proposal and/or has a targeted release milestone, it is moved into the “Planned” column. This is where design proposals are discussed before moving into the implementation phase (In progress).
• In Progress (Development) – Implementation specifics have been agreed upon and the feature is under active development.
• Done
• Released

个人看法

1. 可以理解成：判断“这个需求做不做”和“这个需求优先级高不高”是靠民主投票，很民主很社区, listen to the community.
   这样让项目更“可信”，make you feel like you are a part of a community, 我看了会想参与。
2. 不过从Backlog 到 Planned 阶段没懂要满足什么条件，这一步似乎不太民主（也可能是我理解错了）
3. 这种玩法适合人多的社区，如果是小社区用这种方式可能会尬，没人点赞

# apollo

https://github.com/apolloconfig/apollo/projects/1
也是一个project 管理所有roadmap。
看操作记录，似乎是由 PMC 维护这个 roadmap

# 一些共通的思路

Roadmap 透明、民主的好处

决策社区化，让项目更社区

一个需求的生命周期

需求/proposal --- 需求评审，决策做不做 --- （决策怎么做）等有人认领、给出系统设计的 proposal 了，进入方案评审阶段 --- 评审通过，启动开发 --- CR --- .....

Roadmap 是大而全，还是限制数量、少而精?

Putting together and maintaining a roadmap over time can be a challenge. There are two main dimensions involved: the number of things to include on the roadmap, and the amount of time covered by the roadmap.
There is a temptation, when drafting a roadmap for the first time, to put everything and the kitchen sink in it. You should resist that temptation. I think it is better to choose a small number (four or five) of high priority big goals, and to figure out what is involved in delivering those.
https://www.redhat.com/en/blog/building-community-roadmaps

少而精。确定近期会做的事情才拆细:

I like a kind of fractal planning method: for a release in 12 or more months, you might have a theme in mind (“Launch plug-in portal”), without a clear idea of what is involved. As you get closer to the release, you start to flesh out what is involved, and break down the big goal into more digestible chunks (something a person might get done in a single release or sprint). Finally, when planning features in detail, they can be broken down into checklists of work items that need to be done. For the current release or sprint, you should have a very good idea what will be done, down to the individual work item (bug, checklist item).

Roadmap 需要定期维护

定期讨论（比如在每个版本的社区会议）决定之前列在 roadmap 的事情还值得做么，更新维护 roadmap

The important thing is, on a regular cadence (every sprint or release), the roadmap is revisited, to see whether future themes are still important, to plan for the next sprints, and to break down bigger themes that are getting closer into a more concrete list of tasks.

leave seats at the table

标记清楚哪些是目前有人在做的，哪些是“我们很需要这个feature，但是暂无资源支持，所以欢迎贡献”

Finally, it’s important to indicate, particularly if this is a project with a lot of full time developers, what your development team has committed to, and which tasks you would like to have, but are not resourced or planned. In this way, you leave seats at the table, and establish an expectation that if someone from outside of your team implements a feature that it is likely to be accepted.

冷启的切入点

如果有 full time developer，“劫持工作流”是很好的切入点

如果 full time developer在做公司需求，那就先让公司提需求时按社区的工作流去提，“劫持”工作流

• 内部需求，谁提的需求谁录入github，录需求、以及想改成什么样，大概设计是啥

  • 比如 API 变更

• 有一个通知社区来 review 的机制

  • 有个社区开发者小群
  • 机器人通知变更到小群

• 设计文档按 proposal issue 的形式写

• 项目管理按社区的方式管理

# Reference

https://www.redhat.com/en/blog/building-community-roadmaps