增强以 github 为中心的工作流程，并将更多事情搬到 github 来。

[hax]

参看此文：http://wiredcraft.com/blog/github-for-everything/

摘录下此文的总结：

This actually had a couple interesting effects on the team:

• We've significantly increased participation. Our staff (engineers, designers et al) are already working on Github. There's virtually no friction when engaging them on discussions not related to their day-to-day responsibilities.
• We've drastically raised transparency. Everything is done on Github, available for all to see and comment on. Processes like employee termination or tax payment are in the Wiki, for every new staff to check (and even collaborate to).

第一点是有利于协作参与。

注意我们比此文讨论的前提状况还要差。他讲的是工程师和设计师已经都在github上，所以在github上也能让他们更顺畅的参与非日常性的其他事务。我们的情况是绝大部分工程师都在github上（但收notification这样的事情还要不断强调），但设计师和pm都没完全在github上。

历史上我们曾经做过的：PM&Dev在Github上的开发流程【试行稿】

但是执行得不好，真的变成只是“试行”。现在各团队各用各的，如Trello、Tower、Slack或其他协作工具。

这个可能有许多原因。 除了dev这里总结，也需要找PM去得到反馈。

我个人觉得当团队变大和分部门之后，issue都堆在一起可能是一个问题。但是也不是完全无解，比如借用milestone来拆解，或者建立独立的repo来记录issue。（另外当时github的PR还会被列在issues里而显得混乱也许是个原因。现在这个问题已经不存在了。）

抛开haojing不讲，与此相关的是 #2 ，允许以小团队为单位在单独的repo上工作，也利于以团队为接口的讨论。

第二点是增强透明度（指代码以外的其他事务）。公司内完全的open和信任是我们的核心文化之一，在公司不断扩张的情况下，如何保持此核心文化是一个挑战。我不是说现在我们的机制本身变得不透明了，而是在现有和将来的规模上，原来保持透明的方式（比如群英会上沟通各种事情比如某人为什么离职）无法保持原有效果。将一些flow搬到github上可以保持透明并允许沟通，我认为至少是一种可以考虑的方案。

[hax]

cc @baixing/tech-leaders @yorkliang @xipan
不知道还应该 @ 谁， @jianshuo 会收notification么？

[xu-yanfei]

我猜建硕会更喜欢trello。

让非技术人员用markdown来写东西，多数会疯了吧。前天我跟花花介绍用马克飞象工具来写evernote，然后我们的聊天就无法继续了……连站一旁的飞哥都认为用markdown写notes是怪胎……

再有就是工具支持。York等同学很喜欢手机办公，不清楚github手机端app似乎能找到一些但都是第三方开发的，不清楚功能、易用性如何。要想大家都用github，手机上的操作一定得方便。

个人觉得在一家技术人员并不是占overwhelming比重的公司，用github包揽所有的效率不一定会提高。我个人会更倾向与trello/tower/slack里只保留一个用作多方人员合作的平台，然后用ifttt的方式把平台上的事情自动创建出github issue。

提到的第二点增强透明度我很认可。trello还好，板块可以设成org visible，tower似乎就没这个选项，以至于必须加入项目组才能看到。

最近先理事情，然后再来理流程吧。确实很多流程不顺，阻碍了效率呢。

[amio]

markdown 入门我觉得只需要知道两个：标题用#，列表用-
可以满足绝大多数文档的需求了，除非有人想要在文档里写凡客体。

手机办公需求，可以考察下第三方 App，有很多，用 Android 的话还有 官方的客户端
另外 Github 本身的移动版做的还不错，官方以前出过 Issue for iOS，后来做了移动版 WebApp 之后应用就下架了（官方对 WebApp 信心十足 or 目标满满）。

目前的状况是开发人员喜欢 Github，非技术人员喜欢 Trello, Tower 等，我们希望大家尽量统一在一个平台，为什么倾向让非技术人员用 github 而不是让技术人员用 Trello？因为 github 能同时满足文档、沟通、代码需求，trello 则只能做任务管理。就具体领域来可以假设 trello 在任务管理上更优秀，github 在代码协作上更NB，也许我们应该用最好的工具做最好的具体事情，但就我看来让不同的环节能关联互通的好处，要远远大过 “trello 对 pm 而言在任务管理上比 github 好用一些” 的好处。

[xu-yanfei]

关键不在于markdown语法有多简单易学，而在于非技术同学习惯的写作方式就是移动鼠标所见所得。规则的制定是容易的，但让人改变长期以来的行为甚至思维方式，代价会很高。

@amio 你可以在你和PM配合的项目中先尝试一下，看是否能让与你合作的PM顺畅的使用github。如果使用下来不错，再尝试一点点推广。

所有流程的东西，统一确实可能提升效率；但想当然的根据自己的习惯来强推一些流程，那对效率大概只会是伤害。

[amio]

我们以前不是还要求PM写SQL过朝歌……我觉得那段时间的百姓太牛逼了。
我肯定不敢对PM要求这么高，不过 markdown 比这些都简单很多，应该好多了。

[hax]

@xu-yanfei 确实如 @amio 所说，我们其实有更苛刻的要求。pm是不用写chaoge的，但是sql是必须会的，否则没法用bi工具。

且我们不需要精通markdown。从直接写纯文本开始就可以（链接是自动识别的，图片拖进去自动就上传了，不用特意学）。然后如大炜所说，略进阶就是用标题#和列表-。这些已经满足95%的场景了。

关于习惯这个，怎么说呢。我相信确实有人必须看到word界面才能写出东西，尽管他可能并不用任何高级word功能——完全是跟用一个纯文本编辑器没啥差别。但是我觉得这类问题是可以克服也应该克服的。我不认为这个代价“很高”，或者说这个代价纯粹是个心理问题。

需要注意的是，实际上markdown的流行并不是在程序员中开始的。因为程序员群体可能用各种格式，比如textile、asciidoc等，特别是一些语言社区里有其自己的doc标准比如reStructureText（python）、POD（Perl）等，以程序员的尿性哪愿意用别人的文档格式。所以在那么多轻量级标记语言中，最后markdown大流行，绝对不是起于程序员，而是来自博客、wiki之类的以写作（而不是编程）为主的群体的推广和传播。比较起来，PM应该比程序员更接近这个人群。

当然我们需要一些尝试的方式。比如是不是可以试着把pm blog移到github上？当前的pm blog有一个巨大的问题就是搜索实在太烂了，至少这点上github issue方式的blog比现有要强太多了。

[xu-yanfei]

好吧我带错头了，讨论的焦点根本不应该在markdown上。我其实也打算再给花花介绍一下马克飞象。

我还和大炜聊到trello是一个比github issue直观好用得多的日常工作管理工具（虽然管它管不了代码）。它的纵横两列、带色彩label、头像、deadline、完成度的直观界面，（注意，重点在纵横两列所有信息都在一个页面上以非常科学的组织呈现在眼前）对我来说是github issue无法比拟的。我需要的，是为不同目的而建的不同的专业工具，以及一套ifttt的方法。

咱们不浪费时间讨论了。

在接下来各位与公司其它同事合作的项目中，你们可以自由尝试各种形式。如果在几个小项目中你们说服PM、设计师转移到github上来并且确实体现了高效，我们再来继续这个话题。