我的意见:

项目是关于过程和人的。 里程碑是关于产品的。

A Project is best for getting insight into a process used by the people in the group. A better name for it would be "workflow" or "process". There's more overhead involved in creating a new project vs. creating a new Milestone. So you really only want to create a new Project when there's a new process in your team: Lanes must be chosen, configured, and ordered. They can also be very different in each Project. I think back to the original use of Kanban by Toyota: managing the people and their workload.

一个项目回答了这个问题，“我们目前在做什么?”

两个伟大的项目例子:软件开发和博客。每个组的配置将支持不同组的人员流程;他们如何一起工作，如何签署协议。

相比之下，里程碑的工作原理都是一样的。它们是一个有序的任务列表，必须全部关闭，才能认为工作产品是完整的。可选地，可以设置截止日期，这只是提供提醒，但不改变里程碑功能。

一个里程碑回答了这个问题，“完成这个产品还剩下什么?”

里程碑是一种标签，用来标记预计在某个时间点交付的组票。您可以从“问题”页面访问的“里程碑”页面清楚地表明—您可以看到特定里程碑和到期日期完成的票的百分比。您还可以根据到期日对里程碑进行排序，并在特定的里程碑中对票据进行优先级排序。

这里的压力在于交付日期和跟踪进度。

Projects on the other hand are implemented in GitHub as Kanban boards with some bells and whistles. You can specify a number of columns (and swimlanes - as @Doug said below swimlanes are not supported yet) to create simple workflows. You can then add tickets from one or many repositories, prioritise them, and then progress them from one column to another as they are being worked on. You could, for example, have 'Backlog', 'In Progress', 'Under Review', 'In Testing', and 'Done' columns and move tickets from left to right, or from right to left if, say, a defective ticket gets bounced from 'In Testing' back to 'Backlog'.

这里的重点是组织和管理工作。

那么如何组织和划分工作就取决于你了。您可以为每个里程碑创建一个项目，或者在一个项目中有几个里程碑，或者将里程碑分割为更短的冲刺。您还可以有多个项目，涵盖产品工作的不同方面，例如，一个用于开发人员，一个用于测试人员。

项目的一个好处是它们比里程碑形式更自由。你可以把笔记放在里面，链接到问题上，按照你的方式组织它们。它们非常适合记录想法，制定路线图，列出资源和依赖关系。在过去，我使用问题和wiki来做同样的事情，但我发现两者都太正式和事务性了(即更高的开销)。

我的意见:

项目是关于过程和人的。 里程碑是关于产品的。

A Project is best for getting insight into a process used by the people in the group. A better name for it would be "workflow" or "process". There's more overhead involved in creating a new project vs. creating a new Milestone. So you really only want to create a new Project when there's a new process in your team: Lanes must be chosen, configured, and ordered. They can also be very different in each Project. I think back to the original use of Kanban by Toyota: managing the people and their workload.

一个项目回答了这个问题，“我们目前在做什么?”

两个伟大的项目例子:软件开发和博客。每个组的配置将支持不同组的人员流程;他们如何一起工作，如何签署协议。

相比之下，里程碑的工作原理都是一样的。它们是一个有序的任务列表，必须全部关闭，才能认为工作产品是完整的。可选地，可以设置截止日期，这只是提供提醒，但不改变里程碑功能。

一个里程碑回答了这个问题，“完成这个产品还剩下什么?”

在GitHub上:

项目是一个有开始但没有结束的过程。 里程碑是一个强调结束时间的过程。

因此，使用里程碑将项目划分为许多具有结束时间的阶段是正确的。

我是这样使用的:

组织项目用于组织关于多个存储库的过程。 Repository Project用于组织长期分支的迭代过程，如开发分支、自定义分支。 里程碑是一个迭代阶段。

我也在想同样的事情。这是我想到的。

首先，让我们回顾一下主要的相似点和不同点:

An issue can belong to multiple Projects, but only one Milestone. Projects are never complete. There is no progress bar, or deadline. Projects have no progress bar or deadline (they do now, though it is hidden inside the project's menu as a "Track project progress" checkmark, and there's no percentage calculation of progress), but can now be closed (as pointed out by @Sheen) Milestones on the other hand have all that, but lack any form of organization. An issue is either in a milestone, or isn't. (They can be ordered as pointed out by @Nick McCurdy) Issues can be filtered by Milestone, but not by Project. As pointed out by @cmonkey, issues can now be filtered by Project as well as Milestone. Projects can contain Notes (which can be converted as issues) so it doesn't pollute the issue tracker with vague ideas A Project can span over multiple Milestones, and a Milestone can contains parts of different Projects. An Organization can have Projects as well. These projects can include tickets from any repository in the organization, which makes it quite useful.

所以我的看法是，项目是一种完全独立的方式来在更高的层次上可视化和组织你的工作(想想“项目管理”，多个团队，多个存储库，等等)，而里程碑是一种方式来组织你的截止日期和发布在更基本的层次上(想想“发布管理”，“版本”，等等)。考虑到这一点，一个问题只属于一个里程碑(它只发布或推向生产一次)，但可以是不同项目的一部分是有意义的。

我相信他们会从其他角度来看待这个问题，我也有兴趣听听其他的观点。

2017年12月

前段时间，在与里程碑和项目一起工作了一年多之后，我意识到我完全忽略了另一个重要的方面。

里程碑是Scrum方法论的一个工具。里程碑对于有时间框的迭代和处理批量问题的sprint很好。 Projects是看板方法的一个工具。项目有利于持续交付和稳定的工作流程。