又解锁了 github project 的一个新技能，当做里程碑来用。

issue 里有 “Milestone No Milestone” 的设置，你没用起来。不然 issue 列表的视图本身就可以用 milestone 做聚合

@harrozze #1 project 的视图里，也可以再加一列 milestone 的

@harrozze




你说的是这个吗，最开始我也试过这个，但是感觉有点麻烦，需要先到 iusses 那边去创建，然后才能在 porject 里面进行关联，project 里面不能直接新建一个里程。（不知道有没有更加简单的方式，我暂时没有找到，如果有的话，可以交流学习哈。）

@wcao #3 我看不到你发的图 不过我猜应该是我说的那个。一般是先创建好 milestone ，然后创建 issue 的时候就可以直接选了。我是在 gitea 里用的，等我去 github 上看看操作流程。

@wcao #3 明白你说的了，确实是这样。不过创建里程碑的频率应该不会高于创建 issue 或者 project 里的 item ？

@harrozze 是的，确实频率比较低，当然也能实现同样的效果。但是我个人感觉好像有点反版本发布的操作，为啥会现有里程碑，才关联 issues 。比如我创建了一个里程 1.0.0 ，然后我把符合要求的 issues 关联到 1.0.0 里面。

正常情况下（我的操作）：先提 Issues => 提 pr => merge => 自动关闭 issues => 如果感觉可以了 => 打 tag （ beta or 正式） => 生成 release => 里程碑自动生成，就是 release 的版本。

不知道大厂是怎么玩的。

应该叫大的项目是怎么玩的

@wcao #6 先创建里程碑是项目管理流程里要求的，通常是先把完整需求进行拆分，由于大项目通常耗时比较长，而超过两周（我不记得具体理论里说是多久了）的一个项目基本上时间预估就不靠谱了，所以用里程碑的方式同时达到 大项目分拆成若干小项目 和 对小项目建立检查点 的目的。当然，你可以不用考虑对完成时间的约束，只用来表示某个自洽功能集完成，就可以发新版了。对于现在的小步快跑的开发模式也同样适用，先设定一个时间跨度相对较短的功能或任务集目标，作为下一个里程碑（时间要求并不强制），然后分拆具体任务，分拆到估计工时和实际工时基本相等的颗粒度即可。

我是习惯这种先计划后开工模式的，所以不觉得先设定 milestone 会增加麻烦。如果有那种还没考虑到底放到哪一期实现的功能，可以先不写属于哪个里程碑，定期回顾和排期（里程碑归属）即可。

@wcao #6 另外是，你可以预先设定 下一个 和 下下一个 里程碑，这样其实每次完成一个里程碑，也只需要增加一个"下下一个“。issue 或 pr ，也并不是每次都会包含在下一个版本的，甚至有可能包含在 1.0=>2.0 的升级中？

另外。。。你中间的空行怎么打出来的……

我知道了，发评论的时候看不到空行，回来看就有了

@harrozze 原来如此，学到了。哈哈