大家的项目管理平台上，尚未决定在哪个版本中修复的问题和新功能，放在哪个版本分支或分类里？

[Keyes]

[ivenvd]

单独建个？ git 分支又不贵。

[caonan]

PMS 中 Incoming、Triage、TBD 之类的地方。。。反正就是单独的一个「尚未决定在哪个版本中修复的问题和新功能」的版本或者分类。

[Keyes]

@caonan 我们现在是直接建了一个版本，比如V1.0下面有V1.0.1、V1.0.2等，又建立了一个"V1.X"的版本，此类别标明尚未决定，总觉得有些不妥

[akfish]

平时喜欢用git flow分支模型：
http://nvie.com/git-model/
新功能开feature分支，修复开hotfix分支。

[akfish]

而且有命令行扩展工具：
https://github.com/nvie/gitflow

[rebornix]

尚未triage的功能和bug，一律放在Backlog中。

[Keyes]

@akfish 这个我还没看过，已入收藏夹，一会儿学习一下

不过可能是我标题说的意义不清，其实我的问题更偏向于“需求记录”和“问题记录”这个方向，收录issues后，再从中拿出来分配到各版本或补丁中进行发布，或者有些干脆就放在那不做，比如好点子，但当前阶段真心没法做的这种

[akfish]

@Keyes 哦，所以就是issue的生命周期管理。
以GitHub的issues为例，有四种动作：加label，添加到milestone，分配给某人，关闭issue。

收到一个issue一般首先加label分类，分配给相关人员跟进，或者直接关闭。
能确定发布到哪个版本的加入对应的milestone。

基本上能满足你的需求了。

[ferock]

@akfish 学习，v2ex 有回复收藏功能么？

[caonan]

@Keyes
@rebornix
@akfish

akfish 说的很实在，我来补充一点点

1. 楼主现在的情况是有产品版本，比如 v1.0 v1.0.1 v1.0.2 ，你这个应视作 milestone
2. 对于新进入的需求和问题，可以进入 backlog 中，打上 feature 或者 issue 或者其他你们定义的标签（也可以统一视作 issue）
3. 定期开 triage meeting 来对这些 issues 分类、定优先级，确定其是否需要跟进，进入哪一个 milestone， 比如 bug fix 一般都是进了 1.0.X 之类的版本，新功能 1.X，革命性进展 2.X
4. 然后让 dev 拼命去完成他负责的 milestone 上的 issue 吧，可以搞搞 scrum 来折磨他们，画个 burn down 图来激励他们
5. 另外，这些进入某个 milestone 中的 issue 也不是一成不变的，也会被产品发布周期、功能稳定性、市场风向等影响，而再次挑出来放到 backlog 中，重新被分配到某个 milestone 中。

[caonan]

@Keyes
对于你说的「需求记录」、「问题记录」的分配，可以在 backlog 中直接完成，如果他暂时没法被分配到具体的 milestone，可以继续放在 backlog 中，但为了更好的进行区分，需要添加各类属性和优先级即可。

功能属性举例：天才的想法，竞争对手的功能，市场呼声很高的功能...
优先级举例：有时间去做一做，等对手先做出来再做，设计师生完孩子回来再做...

[Keyes]

@rebornix
@caonan
@akfish
感谢几位的指点，我再考虑一下backlog的问题，我们的做法其实很@caonan 兄说的有些类似，而且没有意识到这些版本就是里程碑，再次感谢

[rebornix]

@caonan 这个分享很具体，而且也是现在流行且成熟的做法。点赞