谈到时间管理，最先映入脑海的恐怕是番茄工作法了。我不是番茄工作法的粉丝，我有一套自己的时间管理工具和方法。简单来说，所有的任务被分成两类：有明确时间期限且耗时较短的，和时间期限模糊或耗时较长的。对于第一类任务，便签/日历/定时提醒就可以胜任；而至于第二类，时间本身变得不那么重要，对任务追踪的要求凸显出来。在各类任务管理工具中，GitHub 的 issue 和 project 给我留下了深刻的印象。即便不是程序员也没关系，我们不需要写一行代码，不需要有提交记录，就能享受那些工具带来的便利。
我相信，谁也不愿意向全世界公开心里想做的事情，所以需要开设一个 GitHub 私有仓库。不过，倘若仅仅为了时间管理摊上每个月 $7 的费用，确实有些得不偿失。另一些 git 仓库托管厂商，比如 BitBucket 和 GitLab 等都免费提供了类似的工具，各位看官不妨一试。
启程
GitHub issue 从邮件列表进化而来，主要用于讨论问题。我们借鉴过来，改造成故事板，记录每件要做的事。照理来说，每个新的任务都该由一个单独的 issue 管辖（好比每个话题在贴吧新开一个帖子）。不过，实践中我们不必严格执行——跟着感觉走就好了。像给同事回邮件这种事不值得单列一个 issue，这样付出的时间管理成本太高了；学习单反摄影技术也不适合，因为它的周期太长，内容又很多，在 GitHub 盖楼很容易爆吧，最后落得个“被字淹没、不知所措”。以我的经验，像撰写论文开题报告这样，需要数小时至数天完成的任务，适合创建单独的 issue。对于长期和庞大的任务，则适合分解成多个部分，为每一块创建 issue 之后，再用后文提及的 project 工具统一管理。
GitHub issue 面板
考虑到显示宽度的限制，理想的 issue 标题应该足够简短而又不失区分度，最好能让使用者一眼回想起任务的内容。任务的背景介绍、执行流程、检查点和验收条件等最重要的内容，应放在 issue 帖子的一楼。写完之后，点击 submit new issue，这件事就算顺利记录在案了。
创建 issue 的时候，在右侧能看到几个重要的选项。label 是筛选任务的必备神器，强烈推荐为每个 issue 配置。关于 project 和 milestone 的用法请见后文的讲解。
GitHub 的帖子除了普通的文字，还可以使用 Markdown 格式化文本。GitHub 支持的 Markdown 语法十分强大，可以勾选和取消列表中的项目，这简直就是为检查点量身打造的。不过，只有一楼的复选框会以进度条的形式显示在 issue 面板下，所以请记得把所有的检查点都挪到一楼。下面展示了这种特别的 Markdown 语法。
1 | - [x] 一个已勾选的复选框 |
通常，伴随着任务的新进展，执行记录一层层堆叠在帖子下方。不用怕写错了什么，因为咱们总有修改和删除任何帖子的机会。等任务做完，就可以点击 close issue 关闭这个帖子了。关闭的帖子依旧可以编辑和评论，必要时可以回来看看。
追踪
像学习单反摄影这样的长期任务，如果拆分成好几块，各部分间经常会出现依赖关系。比如，尝试不同光圈和快门的组合与练习构图可以同时进行，但建筑写生就要等它们都完成之后才好开展。在 project 工具中，我们可以更细一步描述和管理大型任务。
GitHub project 面板
project 面板允许我们自由地添加、删除和拖拽“列”，以及列中的 issue。每个列代表了任务执行的一个阶段。issue 从左到右划过整个流水线，完成它的生命周期。同时，issue 在列中的上下位置代表了其优先级。我建议每个 project 至少含有以下 5 个列：
- To Do
- Blocked
- In Progress
- Review
- Done
在 issue 面板中指定一个 project 后，相应的 project 就会出现一个需要 triage（分拣）的 issue。在多数情况下，新 issue 将被扔到 To Do 或是 Blocked 里面，其中 Blocked 就是用来记录和整理依赖关系的。任务开始执行后，便可调整至 In Progress 列。对于需要事后反馈与总结的任务，应当在完成后置于 Review 状态，否则可以直接移动至 Done。我的个人偏好是关闭处于 Review 状态的 issue，你也可以等到 Done 了再关闭它们。当然，定期把已关闭的 issue 从 project 中移除也是一个好习惯。
上面是一个最基本的五级任务管理流水线。实际的大型任务可能需要更加复杂的结构。凭借各位的聪明才智，创作出一个合适的框架，肯定不是什么难事。
轮回
在 GitHub 提供的工程管理工具中，我最喜欢的是 issue 附属的 milestone 特性，这个特性让 issue 回归了时间管理的本质。无数事例已经证实，对普罗大众来说，deadline 才是第一生产力。打上里程碑的印记，就如同标记了 deadline 一样，有助于我们战胜拖延症，限期完成任务。
milestone 和 label 一样，在 issue 面板下创建和编辑。每个 milestone 都有固定的期限，半个月或者一个月是合理的长度。我们的目标是，每个标记了 milestone 的任务，都应该在这个期限结束前关闭。每到月中或是月底，请打开当前的 milestone，逐一清理还没有关闭的 issue。尚未开始的任务，也许干脆取消更好。已有进展的任务，要不要考虑中止呢？实在无法割舍的，就不得不转移到下个 milestone 了。重复几次清理的过程，就会对自己的执行力有比较透彻的了解，有助于挖掘生产力的潜能。
进化
GitHub 原生的工具完全可以满足我对第二类任务的时间管理的需要。如果你想寻求一站式的编辑体验，以及长叙事、燃烧图等高级功能，可以为 GitHub 加上 ZenHub 插件。该插件对个人用户免费开放。更多功能，有待你的逐步探索。