github issue & project 使用方式

整体上看，issue 列表 和 project看板 两者的关系是 issue 作为一个任务池，供挑选入 project 中进行管理，project 中的任务尽量保证各个参与者能够聚焦自己的任务。

使用的 issue 列表主要有：

1. developer-center 主要作为外部汇报问题、提交建议的入口。
2. internal-discussion 主要作为公司内部工作人员搜集、提交问题的入口。

TODO: 为何作如此区分？

使用的 project看板主要有：deepin 系统发布看板。

看板分列

• 搜集 从 issue 列表中挑选的没有争议需要做的内容；
• 确定的需求 已经确定了最近几个版本会做的内容；
• 开发 当前正在开发的任务；
• 测试 开发、修复完成，需要验收的内容；
• 回归测试 需要在最终的版本上进行回归验证的测试项；

任务过滤

任务过滤是指在任务进入实质的开发之前进行的任务筛选过程，主要由产品、开发、系统负责人进行。

• 第一层过滤过滤点是从 issue 列表到看板，放到看板的 issue 自动进入搜集列。
• 第二层过滤过滤点是从搜集列，进入确定的需求列，只选择确定在下一个或者两个版本周期内进行开发的内容，放入确定的需求列，并为任务添加 milestone 。

任务移动

任务移动是指在任务在确定开始处理到 issue 被关闭，所进行的任务在列之间的移动动作，主要有开发负责人、开发、测试人员进行。

• 开发负责人按照优先级、工作量，分配任务到人员以后，从确定的需求列中移动到开发列中；
• 开发人员在完成开发后，将任务从开发列移动到测试列中供测试进行验收；
• 测试人员功能验收后，将验收成功的任务移动到回归测试中待集成测试后关闭issue，验收失败的任务移回开发列继续进行开发；

关注点聚焦

为了保证各个人员的关注点不产生分散，做以下规则：

• 除产品、开发、系统、测试负责人需对 issue 列表进行关注外，其余人不必须关注 issue 列表的变化，但需要及时回应自己参与的 issue 中提及自己的内容；
• 晨会只关注标记了当前版本 milestone 的任务、开发列表的任务；
• 开发当天只需要关注开发列中属于自己的任务， 测试当天只需要关注测试列中属于自己的任务；
• 在以上规则之上，还有余力的同学可以在确定的需求中挑选自己认为有能力做到的需求进行实现；