你可以点击右上角的添加卡片Add Cards，然后找你想要添加的东西。在这里，特殊的搜索语法就派上用场了，举个例子，输入 is:pr is:open 然后现在你可以拖动任何开启的 PR 到项目面板上，或者要是你想清理一些 bug 的话就输入 label:bug。
亦或者你可以将现有的备注转换为工单。
再或者，从一个现有工单的屏幕上，把它添加到右边面板的项目上。
它们将会进入那个项目面板的分类列表，这样你就能决定放到哪一类。
在实现那些任务的同一个仓库下放置任务的内容有一个巨大（超大）的好处。这意味着今后的几年你能够在一行代码上做一个 git blame，可以让你找出最初在这个任务背后写下那些代码的根据，而不需要在 Jira、Trello 或其它地方寻找蛛丝马迹。
缺点在过去的三周我已经对所有的任务使用 GitHub 取代 Jira 进行了测试（在有点看板风格的较小规模的项目上) ，到目前为止我都很喜欢。
但是我无法想象在 scrum（LCTT 译注：迭代式增量软件开发过程）项目上使用它，我想要在那里完成正确的工期估算、开发速度的测算以及所有的好东西怕是不行。
好消息是，GitHub 项目只有很少一些“功能”，并不会让你花很长时间去评估它是否值得让你去切换。因此要不要试试，你自己看着办。
无论如何，我听说过 ZenHub 并且在 10 分钟前第一次打开了它。它是对 GitHub 高效的延伸，可以让你估计你的工单并创建 epic 和 dependency。它也有 velocity 和燃尽图burndown chart功能；这看起来可能是世界上最棒的东西了。
延伸阅读： GitHub help on Projects。
#10 GitHub 维基对于一堆非结构化页面（就像维基百科一样）， GitHub 维基wiki提供的（下文我会称之为 Gwiki）就很优秀。
结构化的页面集合并没那么多，比如说你的文档。这里没办法说“这个页面是那个页面的子页”，或者有像‘下一节’和‘上一节’这样的按钮。Hansel 和 Gretel 将会完蛋，因为这里没有面包屑导航（LCTT 译注：引自童话故事《糖果屋》）。
（边注，你有读过那个故事吗? 这是个残酷的故事。两个混蛋小子将饥肠辘辘的老巫婆烧死在她自己的火炉里。毫无疑问她是留下来收拾残局的。我想这就是为什么如今的年轻人是如此的敏感 —— 今天的睡前故事太不暴力了。)
继续 —— 把 Gwiki 拿出来接着讲，我输入一些 NodeJS 文档中的内容作为维基页面，然后创建一个侧边栏以模拟一些真实结构。这个侧边栏会一直存在，尽管它无法高亮显示你当前所在的页面。
其中的链接必须手动维护，但总的来说，我认为这已经很好了。如果你觉得有需要的话可以看一下。
它将不会与像 GitBook（它使用了 Redux 文档）或定制的网站这样的东西相比较。但它八成够用了，而且它就在你的仓库里。
我是它的一个粉丝。
我的建议：如果你已经拥有不止一个 README.md 文件，并且想要一些不同的页面作为用户指南或是更详细的文档，那么下一步你就需要停止使用 Gwiki 了。
如果你开始觉得缺少的结构或导航非常有必要的话，去切换到其他的产品吧。
#11 GitHub 页面（带有 Jekyll）你可能已经知道了可以使用 GitHub 页面Pages 来托管静态站点。如果你不知道的话现在就可以去试试。不过这一节确切的说是关于使用 Jekyll 来构建一个站点。
最简单的来说， GitHub 页面 + Jekyll 会将你的 README.md 呈现在一个漂亮的主题中。举个例子，看看我的 关于 github 中的 readme 页面:
点击 GitHub 上我的站点的设置settings标签，开启 GitHub 页面功能，然后挑选一个 Jekyll 主题……
我就会得到一个 Jekyll 主题的页面：
由此我可以构建一个主要基于易于编辑的 markdown 文件的静态站点，其本质上是把 GitHub 变成一个 CMS（LCTT 译注：内容管理系统）。
我还没有真正的使用过它，但这就是 React 和 Bootstrap 网站构建的过程，所以并不可怕。