协作流程

选题

除了日常任务标准库翻译之外，可以在 issue 提出流行的第三方库。
下载最新稳定版的库。
生成库文档原文（markdown 格式），第一行需要带有库的版本号，放在项目 Source 目录。保持目录结构，比如 net/http 包文档放在 Source/net/http/http.md，golang.org/x/net/websocket 包文档放在 Source/golang.org/x/net/websocket/websocket.md

重新下载库，生成库文档。
如果 Translate 目录有这篇文章的译文，代表这篇文章旧版的翻译流程还没走完，原文就来新版本更新了，通常选题时遇见这个情况就会联系旧版译者注意的，如果没有联系到旧版译者，他弃坑了，负责选题的小朋友在 issue 里通知这个情况。
若原文内容有变化，把新版放在 Source 目录。（重新进入翻译流程）
若原文内容没有改变，直接把译文里第一行的版本标识改成新的。（直接跳过翻译流程）

从 Source 目录和 issue 扒拉文章，找到想翻译的还没人翻译的。（如果 Translate 目录有这篇文章的译文，代表这篇文章旧版的翻译流程还没走完，原文就来新版本更新了，通常选题时遇见这个情况就会联系旧版译者注意的，如果没有联系到旧版译者，他弃坑了，负责选题的小朋友会在 issue 里通知的）
查看项目中是否有旧版已完成译文。
Fork
如果这篇文章还没有被翻译过，把它从 Source 目录复制到 Translate 目录。在 Translate 目录开始翻译。复制时保持目录结构，不要不小心把子包也复制过来了。
如果有旧版本译文，把旧版译文复制到 Translate 目录。保持目录结构。（重复利用以前的资料）
- 通过查看旧版译文第一行的版本号，找到对应的旧版本原文。
- 对比原文这段时间的变化，在旧译文的基础上翻译有变化的部分并替换对应旧译文。
- 原文变化太复杂也可以重新翻译。
翻译完成后，提 Pull request 进入 review 环节。可以把旧版原文的 git 版本号放在 PR 里，用来提醒校对。

Translate 目录里可能有未完成弃坑的文章，也可能有已完成待 review 的文章，也可能有 review 后正在修改等待再次 review 的文章。
所以项目维护者作为校对的话，可以从 PR 开始，没必要去 Translate 目录领养文章，当然也可以没事逛逛 Translate 目录。
对 PR 提出改进意见，或接受 PR 后自己修改译文。
校对完成。移动文章到项目根目录，立即发布。保持目录结构。
校对不确定的话可以先把文章留在 Translate 目录，邀请别人来二次 review，最后移动文章到项目根目录时，提交注释要注明所有 review 过的人，每人一行，格式如 review: name <name@email.com

基于 github page 部署，在项目根目录的文档都会发布出去。

直接修改项目根目录文档，若修改太大，最好复制回 Translate 重新走 review 流程。

保持目录结构，比如 net/http 包文档放在 Source/net/http/http.md，golang.org/x/net/websocket 包文档放在 Source/golang.org/x/net/websocket/websocket.md
以“从 Source 目录复制进 Translate 目录”为翻译开始，以“从 Translate 目录移到项目根目录”为翻译结束。
Source 目录下只能有原文变动相关的 git 历史，方便对比原文不同版本之间的差异（使用 git log 命令和 git diff 命令完成这些），所以任何操作前都先把文章从 Source 复制出去，防止 Source 目录操作历史太杂乱，导致不方便对比原文不同版本之间的差异。（git log Source）
没有 Review 目录，Translate 目录就是 Review 目录的作用，因为译者在 Translate 目录下翻译提交，校对不可能先把文章移动进 Review 目录再去看内容，都是先看内容再接受 PR。
文档校对完成立刻发布。负责接受 PR 的人也负责文档的发布。
Source 与 Translate 用大写是为了与包名区分。
本文有点啰嗦，对于 wiki 来讲不算缺点。
暂时译文无签名。

推荐，任何人可以推荐新的第三方包，讨论后添加到项目 Source 目录，一旦进入项目，持续更新。
认领，译者翻译状态
- 译者新建 issue，标题使用版本号加引用路径，如 1.9.2 net、1.9.2 net/http、1.9.2 golang.org/x/net/websocket。（只能认领 Source 中已存在的包，否则请先走推荐流程）
- 一楼内容可留空，新建就代表认领。
- 若译者弃坑，维护者会给 issue 添加 待认领 标签，此时回复即可认领。（这里与主项目一样了）
- review 完成关闭 issue
- 与主项目区别在，译者自己新建 issue 认领，无 已认领 标签。（因为不存在选题工作，所以也没必要提前新建 issue 待认领了）
由于 issue 是译者自己创建的，这意味着译者可以在一楼写下想要置顶的内容，比如翻译心得、认领情况、翻译进度、多人协作翻译名单、校对名单等等，如果真想回复某人再使用回复功能。