Mastering Issues
原文链接 -> 传送门
Issues（问题单）是一种伟大的工作方式，它用于对项目进行跟踪、增强和排错。它们就像电子邮件一样 —— 除了它们可以与团队的其他成员进行分享和讨论。大多数软件项目都会有某种错误跟踪器，GitHub 的错误跟踪器称为“Issues”，并且在每个仓库中都有自己的 Issues 部分。
例如，让我们来看看 Bootstrap 的 Issues 部分内容（传送门）：
GitHub 的问题跟踪是很特别的。因为我们（GitHub）专注于协作，参考和优秀的文本格式，所以一个典型的 GitHub 问题应该像这样：
- 标题和描述概括了这个问题是关于什么的。
- 彩色 Labels（标签）可以帮助你对问题进行分类和过滤（就像电子邮件中的标签一样）。
- Milestone（里程碑）就像一个问题单的容器。这对于将问题单与特定功能或项目阶段（例如 Weekly Sprint 9/5-9/16 或者 Shipping 1.0）进行关联非常有用。
- assignee（责任人）负责在任何指定的时间解决相应的问题
- Comments（评论）允许有权访问仓库的任何人对该问题进行回复。
Milestones（里程碑），Labels（标签）和 Assignees（责任人）
一旦你添加了太多的问题单，它们就会像杂草一样让你觉得凌乱。不过有了 Milestones，Labels 和 Assignees，你就可以轻松地对问题单进行分类和过滤了。
你可以通过点击右边栏上相对应的小齿轮，修改或添加一个 milestone，assignee 和 labels。
如果你没有看到编辑按钮（小齿轮），那是因为你没有编辑问题的权限。你可以请求仓库管理者将你添加为协作者来获得相应的权限。
Milestones（里程碑）
Milestones 是对应于项目，功能或时间段的问题组。人们在进行软件开发时，可以以不同的方式使用它们。下面是 Github 上使用 Milestones 的一些例子：
- 发布测试（Beta Launch）—— 在你发布项目的 Beta 版之前，包含你需要修复的 bug 文件。这样可以确保你不会漏掉什么。
- 十月冲刺（October Sprint）—— 记录你在十月份应该做的问题单文件。相当于一个工作清单，时刻提醒你应该重点完成哪些工作。
- 重新设计（Redesign）—— 记录与重新设计项目的问题单文件。这是一种收集灵感的好方法。
注：为啥这里用“十月”呢？我推测应该跟美国总统通常都是 11 月选举有关，所以 10 月份就是最后拉票的冲刺月，不过这是我自己猜测的……知道真相的童鞋请回帖告知，谢谢~
Labels（标签）
标签是组织不同类型问题单的好方法。每个问题可以包含任意数量的标签，你可以一次性过滤一个或多个标签。
Assignees（责任人）
每个问题都可以有一个责任人 —— 一个人负责解决该问题的人。通过问题顶部的灰色栏，以同样的方式选择受责任人。
Notifications（通知），@mentions（@提及）和 References（参考）
通过使用 Issues 的 @memtions 和 references 功能，你可以通知其他的 GitHub 用户和团队，还可以与其他问题单相互连接。这些功能提供了一种灵活的方式，可以让合适的人帮助你有效地解决问题。并且这些功能非常易于学习和使用。它们在 GitHub 的所有文本字段中均可正常工作 —— 它们是我们的 GitHub Flavored Markdown 文本格式的一部分。
如果你想学习更多编辑相关的内容，请接着学习 后面的 掌握 Markdown 章节（大家可以与我们的CSDN的 MarkDown编辑器 比较一下）
Notifications（通知）
Notifications（通知）是 GitHub 保持你的 Issues 最新状态的方式。你可以通过它们找到仓库中最新的问题单，或者仅仅知道某人需要你的输入来推进一个问题。
有两种方式可以接收通知：通过电子邮件和通过浏览器。你可以在设置中指定接收通知的方式。如果你计划收到大量的通知，我们建议你在“Participating”处设置为 web + email，在“Watching”处设置为 web。
通过这些设置，当别人特别提及你的时候，你就会收到电子邮件通知，然后访问基于网页的界面并随时了解你感兴趣的仓库。
你可以通过通知页面访问收到的通知。这个界面对于一次浏览多个通知十分方便，而且也可以将通知标记为已读或者屏蔽。你可以使用快捷键来加快你的工作流程 —— 在 GitHub.com 的任何页面按下 ? 键你就可以看到有哪些快捷键可供使用了。
被屏蔽的通知不会再显示为未读状态，直到你再次被特别地 @mentioned（提及）。这样你就可以屏蔽那些你不感兴趣的线程（可能是你不熟悉的子系统）。如果你将某个问题标记为已读，它将保持这种方式，直到有人再次进行评论。
GitHub 还会同步电子邮件的状态为已读/未读 —— 如果你在邮箱客户端读取一条通知，那么在网页界面上的该条通知就会自动标记为已读（如果你喜欢这个功能，那要先确保邮箱客户端允许显示图片）。
@mentions（@提及）
@memtions（@提及）是在 GitHub 的问题单中提及其他 GitHub 用户的方式。我们可以在任何问题的描述或评论中使用该功能，也可以通过 @username（@用户名）向另一个 GitHub 用户发送通知，这跟 twitter 中的 @memtions 功能很像。
我们喜欢使用 /cc 语法（carbon copy 的缩写）将人们包含在问题中：
It looks like the new widget form is broken on Safari. When I try and create the widget, Safari crashes. This is reproducible on 10.8, but not 10.9. Maybe a browser bug?
/cc @kneath @jresig如果你知道具体要提及哪些人的话，那是非常好的。不过在大多数情况下，我们是跨团队工作，可能并不知道谁才能真正地帮助到我们。所以 @memtions 也适用于对 GitHub 中的团队进行提及。如果你在 @acmeinc 组织中创建了一个叫做 browser-bugs 的团队，你也可以通过 @mentions来引用这个团队：
/cc @acmeinc/browser-bugs这样的话就会给团队的每个成员发送通知。
References（参考）
通常情况下，issue 会依赖于其他 issues，或者至少与它们相关。如果你想将它们关联起来，可以通过输入 #issue编号 来引用相关的问题：
> 嘿 @kneath，我认为这个问题开始于 #42。当你这样做了，我们将创建一个事件内部的问题 ＃42，看起来像这样：
如果问题在另一个仓库怎么办？只需要在名字前面包含仓库名即可，例如 kneath/example-project#42。
有一种更有趣的方式来引用问题，就是直接从提交中引用问题。你可以在提交信息中包含问题编号。
当你将提交合并到主分支时，以 "Fixes"，"Fixed"，"Fix"，"Closes"，"Closed" 或者 "Close" 开头的提交信息会自动关闭相应的问题。
引用这一功能将正在完成的工作与正在跟踪的 bug 紧紧联系在一起，而且它是也将项目历史得以可视化的好方法。
搜索
在每个页面的上方都有一个搜索框，你可以通过它来搜索问题单。
你可以通过下面的方式检索搜索结果：
- 关键字，例如：提到 sidebar 的所有问题
- 状态，例如：提到 sidebar 且状态为已关闭的所有问题
- 责任人，例如：提到 sidebar 并分配给 mdo 的所有已关闭的问题
概况和报告
在 Issues 部分之外，还有两个页面分别用于帮你总结一个仓库中的问题和所有仓库中的问题。
The Issue Dashboard（问题面板）
如果你正在寻找一个包含多个项目中出现的所有问题的列表，Issues Dashboard（问题面板）将是一个非常好的工具。这个面板的工作方式与 issues 部分非常相似，但是收集问题的方式却是不同的：
- 所有你拥有的和参与的仓库的问题
- 被分配给你的问题
- 你创建的问题
如果你使用了 organizations（组织），那么就会为每位组织成员划分一个问题面板。
Pulse（脉息）
在每个仓库下面都会有一个叫做“Pulse”的部分 —— Pulse 是该仓库过去一周（或者一天或者三个月等等）发生的所有活动的快照。
当你离开一段时间后，这是一个很好的方式来赶上仓库的工作进度，而不用查看观察的（Watch）仓库发来的每一个通知。
Issues 的其他用法
问题可以用来跟踪各种各样的东西 —— 并且在 GitHub 上，你可以很容易的分享和协作你的问题。下面是一些我们平日最喜欢做的事儿：
- 跟踪房子的维护问题例如门有没有被正确的挂着（真的房子，跟代码没关系……）
- 跟踪开源项目的 bug
- 需要的菜谱（或许你拥有一个无麸披萨的菜谱？）
结尾
祝贺一下你自己吧 —— 竟然读完了这么长的文章！问题管理器在任何开发者的处理中都是一个强有力的工具。我想现在要做的就是修复 bug 了。