diff --git a/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md b/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md
index f6cb33fe9e..25cd7c93c4 100644
--- a/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md
+++ b/translated/talk/20170602 Why working openly is hard when you just want to get stuff done.md
@@ -1,21 +1,13 @@
当你只想将事情搞定时，为什么开放式工作这么难？
============================================================
-### 学习使用开放式决策框架来写一本书
+> 学习使用开放式决策框架来写一本书
-
->图片来源 : opensource.com
+
-GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数年来，我将各种方法论融入我日常工作的习惯中，包括精益方法的反馈循环，和敏捷开发的迭代优化，以此来更好地 GSD（如果把 GSD 当作动词的话）。这意味着我必须非常有效地利用我的时间：列出清晰，各自独立的目标；标记已完成的项目；用迭代的方式地持续推进项目进度。但是当我们默认使用开放的时仍然能够 GSD 吗？又或者 GSD 的方法完全行不通呢？大多数人都认为这会导致糟糕的状况，但我发现事实并不一定这样。
+GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数年来，我将各种方法论融入我日常工作的习惯中，包括精益方法的反馈循环，和敏捷开发的迭代优化，以此来更好地 GSD（如果把 GSD 当作动词的话）。这意味着我必须非常有效地利用我的时间：列出清晰、各自独立的目标；标记已完成的项目；用迭代的方式地持续推进项目进度。但是当我们以开放为基础时仍然能够 GSD 吗？又或者 GSD 的方法完全行不通呢？大多数人都认为这会导致糟糕的状况，但我发现事实并不一定这样。
-在开放的环境中工作，遵循[开放式决策框架][6]中的指导，会让项目起步变慢。但是在最近的一个项目中，我们作出了一个决定，一个从开始就正确的决定：以开放的方式工作，并与我们的社群一起合作。
-
-关于开放式组织的资料
-
-* [下载《开放式组织 IT 文化变革指南》][1]
-* [下载《开放式组织领袖手册》][2]
-* [什么是开放式组织][3]
-* [什么是开放决策][4]
+在开放的环境中工作，遵循[开放式决策框架][6]中的指导，会让项目起步变慢。但是在最近的一个项目中，我们作出了一个决定，一个从开始就正确的决定：以开放的方式工作，并与我们的社群一起合作。
这是我们能做的最好的决定。
@@ -23,13 +15,13 @@ GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数
### 建立社区
-2014 年 10 月，我接手了一个新的项目：当时红帽的 CEO Jim Whitehurst 即将推出一本新书《开放式组织》，我要根据书中提出的概念，建立一个社区。“太棒了，这听起来是一个挑战，我加入了！”我这样想。但不久，[冒牌者综合征][7]便出现了，我又开始想：“我们究竟要做什么呢？怎样才算成功呢？”
+2014 年 10 月，我接手了一个新的项目：当时红帽的 CEO Jim Whitehurst 即将推出一本新书《开放式组织》，我要根据书中提出的概念，建立一个社区。“太棒了，这听起来是一个挑战，我加入了！”我这样想。但不久，[冒牌者综合征][7]便出现了，我又开始想：“我们究竟要做什么呢？怎样才算成功呢？”
让我剧透一下，在这本书的结尾处，Jim 鼓励读者访问 Opensource.com，继续探讨 21 世纪的开放和管理。所以，在 2015 年 5 月，我们的团队在网站上建立了一个新的板块来讨论这些想法。我们计划讲一些故事，就像我们在 Opensource.com 上常做的那样，只不过这次围绕着书中的观点与概念。之后，我们每周都发布新的文章，在 Twitter 上举办了一个在线的读书俱乐部，还将《开放式组织》打造成了系列书籍。
我们内部独自完成了该系列书籍的前三期，每隔六个月发布一期。每完成一期，我们就向社区发布。然后我们继续完成下一期的工作，如此循环下去。
-这种工作方式，让我们看到了很大的成功。近 3000 人订阅了[该系列的新书][9]，《开放式组织领袖手册》。我们用 6 个月的周期来完成这个项目，这样新书的发行日正好是前书的两周年纪念日。
+这种工作方式，让我们看到了很大的成功。近 3000 人订阅了[该系列的新书][9]：《开放式组织领袖手册》。我们用 6 个月的周期来完成这个项目，这样新书的发行日正好是前书的两周年纪念日。
在这样的背景下，我们完成这本书的方式是简单直接的：针对开放工作这个主题，我们收集了最好的故事，并将它们组织起来形成文章，招募作者填补一些内容上的空白，使用开源工具调整字体样式，与设计师一起完成封面，最终发布这本书。这样的工作方式使得我们能按照自己的时间线（GSD）全速前进。到[第三本书][10]时，我们的工作流已经基本完善了。
@@ -39,59 +31,55 @@ GSD（get stuff done 的缩写，即搞定）指导着我的工作方式。数
开放式决策框架列出了组成开放决策制定过程的 4 个阶段。下面是我们在每个阶段中的工作情况（以及开放是如何帮助完成工作的）。
-### 1\. 构思
+#### 1、 构思
我们首先写了一份草稿，罗列了对项目设想的愿景。我们需要拿出东西来和潜在的“顾客”分享（在这个例子中，“顾客”指潜在的利益相关者和作者）。然后我们约了一些领域专家面谈，这些专家能够给我们直接的诚实的意见。这些专家表现出的热情与他们提供的指导验证了我们的想法，同时提出了反馈意见使我们能继续向前。如果我们没有得到这些验证，我们会退回到我们最初的想法，再决定从哪里重新开始。
-### 2\. 计划与研究
+#### 2、 计划与研究
-经过几次面谈，我们准备在 [Opensource.com 上公布这个项目][11]。同时，我们在 [Github 上也公布了这个项目][12], 提供了项目描述，预计的时间线，并阐明了我们所受的约束。这次公布得到了很好的效果，我们最初计划的目录中欠缺了一些内容，在项目公布之后的 72 小时内就被补充完整了。另外（也是更重要的），读者针对一些章节，提出了本不在我们计划中的想法，但是读者觉得这些想法能够补充我们最初设想的版本。
+经过几次面谈，我们准备在 [Opensource.com 上公布这个项目][11]。同时，我们在 [Github 上也启动了这个项目][12]，提供了项目描述、预计的时间线，并阐明了我们所受的约束。这次公布得到了很好的效果，我们最初计划的目录中欠缺了一些内容，在项目公布之后的 72 小时内就被补充完整了。另外（也是更重要的），读者针对一些章节，提出了本不在我们计划中的想法，但是读者觉得这些想法能够补充我们最初设想的版本。
-我们体会到了 [Linus 法则][16]： "With more eyes, all _typos_ are shallow."
+回顾过去，我觉得在项目的第一和第二个阶段，开放项目并不会影响我们搞定项目的能力。事实上，这样工作有一个很大的好处：发现并填补内容的空缺。我们不只是填补了空缺，我们是迅速地填补了空缺，并且还是用我们自己从未考虑过的点子。这并不一定要求我们做更多的工作，只是改变了我们的工作方式。我们动用有限的人脉，邀请别人来写作，再组织收到的内容，设置上下文，将人们导向正确的方向。
-回顾过去，我觉得在项目的第一和第二个阶段，开放项目并不会影响我们搞定项目的能力。事实上，这样工作有一个很大的好处：发现并填补内容的空缺。我们不只是填补了空缺，我们是迅速地就填补了空缺，并且还是用我们自己从未考虑过的点子。这并不一定要求我们做更多的工作，只是改变了我们的工作方式。我们动用有限的人脉，邀请别人来写作，再组织收到的内容，设置上下文，将人们导向正确的方向。
-
-### 3\. 设计，开发和测试
+#### 3、 设计，开发和测试
项目的这个阶段完全围绕项目管理，管理一些像猫一样特立独行的人，并处理项目的预期。我们有明确的截止时间，我们提前沟通，频繁沟通。我们还使用了一个战略：列出了贡献者和利益相关者，在项目的整个过程中向他们告知项目的进度，尤其是我们在 Github 上标出的里程碑。
-最后，我们的书需要一个名字。我们收集了许多反馈，指出书名应该是什么，更重要的反馈指出了书名不应该是什么。我们通过 [Github 上的 issue][13] 收集反馈意见，并公开表示我们的团队将作最后的决定。当我们准备宣布最后的书名时，我的同事 Bryan Behrenshausen 做了很好的工作，[分享了我们作出决定的过程][14]。人们似乎对此感到高兴——即使他们不同意我们最后的书名。
+最后，我们的书需要一个名字。我们收集了许多反馈，指出书名应该是什么，更重要的是反馈指出了书名不应该是什么。我们通过 [Github 上的工单][13]收集反馈意见，并公开表示我们的团队将作最后的决定。当我们准备宣布最后的书名时，我的同事 Bryan Behrenshausen 做了很好的工作，[分享了我们作出决定的过程][14]。人们似乎对此感到高兴——即使他们不同意我们最后的书名。
-书的“测试”阶段需要大量的[校对][15]。社区成员真的参与到回答这个“求助”贴中来。我们在 GitHub issue 上收到了大约 80 条意见，汇报校对工作的进度（更不用说通过电子邮件和其他反馈渠道获得的许多额外的反馈）。
+书的“测试”阶段需要大量的[校对][15]。社区成员真的参与到回答这个“求助”贴中来。我们在 GitHub 工单上收到了大约 80 条意见，汇报校对工作的进度（更不用说通过电子邮件和其他反馈渠道获得的许多额外的反馈）。
-关于搞定任务：在这个阶段，我们亲身体会了 [Linus 法则][16]："With more eyes, all _typos_ are shallow." 如果我们像前三本书一样自己独立完成，那么整个校对的负担就会落在我们的肩上（就像这些书一样）！相反，社区成员慷慨地帮我们承担了校对的重担，我们的工作从自己校对（尽管我们仍然做了很多工作）转向管理所有的 change requests。对我们团队来说，这是一个受大家欢迎的改变；对社区来说，这是一个参与的机会。如果我们自己做的话，我们肯定能更快地完成校对，但是在开放的情况下，我们在截止日期之前发现了更多的错误，这一点毋庸置疑。
+关于搞定任务：在这个阶段，我们亲身体会了 [Linus 法则][16]：“众目之下，_笔误_无所遁形。” 如果我们像前三本书一样自己独立完成，那么整个校对的负担就会落在我们的肩上（就像这些书一样）！相反，社区成员慷慨地帮我们承担了校对的重担，我们的工作从自己校对（尽管我们仍然做了很多工作）转向管理所有的 change requests。对我们团队来说，这是一个受大家欢迎的改变；对社区来说，这是一个参与的机会。如果我们自己做的话，我们肯定能更快地完成校对，但是在开放的情况下，我们在截止日期之前发现了更多的错误，这一点毋庸置疑。
-### 4\. Launch
-
-### 4\. 发布
+#### 4、 发布
好了，我们现在推出了这本书的最终版本。（或者只是第一版？）
-遵循开放决策框架是《IT 文化变革指南》成功的关键。
-
我们把发布分为两个阶段。首先，根据我们的公开的项目时间表，在最终日期之前的几天，我们安静地推出了这本书，以便让我们的社区贡献者帮助我们测试[下载表格][17]。第二阶段也就是现在，这本书的[通用版][18]的正式公布。当然，我们在发布后的仍然接受反馈，开源方式也正是如此。
### 成就解锁
-遵循开放式决策框架是《IT 文化变革指南》成功的关键。通过与客户和利益相关者的合作，分享我们的制约因素，工作透明化，我们甚至超出了自己对图书项目的期望。
+遵循开放式决策框架是《IT 文化变革指南》成功的关键。通过与客户和利益相关者的合作，分享我们的制约因素，工作透明化，我们甚至超出了自己对图书项目的期望。
我对整个项目中的合作，反馈和活动感到非常满意。虽然有一段时间内没有像我想要的那样快速完成任务，这让我有一种焦虑感，但我很快就意识到，开放这个过程实际上让我们能完成更多的事情。基于上面我的概述这一点显而易见。
-所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：Get **more** done，搞定**更多**工作，并且就这个例子说，取得更好的结果。
+所以也许我应该重新考虑我的 GSD 心态，并将其扩展到 GMD：Get **More** Done，搞定**更多**工作，并且就这个例子说，取得更好的结果。
+
+（题图：opensource.com）
--------------------------------------------------------------------------------
作者简介：
-Jason Hibbets - Jason Hibbets 是 Red Hat 企业营销中的高级社区传播者，也是 Opensource.com 的社区经理。 他自2003年以来一直在 Red Hat，并且是开源城市基金会的创立者。之前的职位包括高级营销专员，项目经理，Red Hat 知识库维护人员和支持工程师。
+Jason Hibbets - Jason Hibbets 是 Red Hat 企业营销中的高级社区传播者，也是 Opensource.com 的社区经理。 他自2003 年以来一直在 Red Hat，并且是开源城市基金会的创立者。之前的职位包括高级营销专员、项目经理、Red Hat 知识库维护人员和支持工程师。
-----------
via: https://opensource.com/open-organization/17/6/working-open-and-gsd
-作者：[Jason Hibbets ][a]
+作者：[Jason Hibbets][a]
译者：[explosic4](https://github.com/explosic4)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出