经过每个工程团队都有自己遵循的流程，以最适合自己的方式完成工作。无论是在某人的头脑中，还是在正式的文档中，都必须进行沟通和共享，因为它们是团队文化的实现。但是对于一个公司和它的工程团队来说，要在成长过程中保持它的文化，比这些过程是什么或者它们是如何被记录的更重要的是它们是如何经历变化的。
在New Relic，我们珍视我们的开放和包容文化，所以我们找到了一种利用GitHub pull-request流程的方法，我们在构建软件时使用它来协作，同时也管理我们的工程团队如何工作。这包括讨论和修改各种各样的内容，从各种工程角色的标题，到技术架构指导方针，成功参加会议的技巧，以及为我们的团队雇佣合适的人的实践。其理念是将“文化视为代码”，并尝试“开放我们的文化”，以便我们对团队使用与代码相同的工作流。
当速度会议几个月前，我在加州的圣克拉拉做了一个关于“用Pull request改变工程规律。“此博文帖子从该演示文稿进行调整（您可以在本帖子底部单击我的幻灯片。
从中学习和离开，维基
像许多其他组织一样，New Relic依赖于许多不同的工具来管理我们的工程团队的变更和最佳实践，包括会议、电子邮件和全能的wiki。当我们还是一个小得多的公司时，我们意识到我们需要写下我们使用的流程，但我们也意识到我们需要一种方法来摆脱我们以前的方法，并引入新的方法。流程可能会很快失去与原始目的的联系，有时最终只会浪费时间和产生开销，而不是增加价值。更糟糕的是，拥有描述那些现在已经过时的流程的文档(wiki)会削弱人们对系统的信任，并阻止人们在流程中投入精力。
我们的维基被视为官方的“经理工具”，很大程度上是因为对它的修改是立即发生的——任何编辑它的人都代表整个团队说话。除非你在会议上或通过电子邮件，否则没有评审或评论，这不利于工程师成功参与。
尽管多年来，尽管多年来，我们从来没有能够满足我们的愿望，以确定和捕获我们工程组织的流程和政策。也许这是因为，对于我们来说，与文件一样重要，我们如何应对网站中断，软件开发流程，安全，旅行，培训和人事政策和决策是如何创建这些事情的过程。
为了解决这一问题，我们列出了一系列总体目标:
- 流程体现文化
- 流程是可重复的、有效的和公平的
- 透明度
- 包容性
- 可发现性
- 单一的真理来源，写下来
- 轻松更新/删除
- 偏见的行动
- 自治
- 文化>过程
以及一些具体要求:
- 一种自然适合工程师的工作流程
- 在像会议这样的排他性的场合，更少的讨论
- 在一个地方记录的每个变化的“为什么”
在GitHub上全力以赴
因此，在2014年7月，我们在2014年7月，我们抛弃了Wiki并开始使用Github拉出请求来管理我们的工程团队的变化。我们将我们的文化文档存储在Git Repo中作为Markdown和HTML，并使用jekyll把它变成一个简单的网站。从那时起，我们的整个工程团队，以及公司中与我们合作的其他人，已经成为实时塑造我们流程的贡献者。我们正在缩小我们的文化和我们的流程之间的差距，因为工程师和经理们都提议和辩论改变。
当然，我们的业务不是民主的，我们不能让任何人改变流程，特别是那些影响金钱或私人信息的流程，比如如何确定工资。但重要的是要明白，开源也不是民主。虽然每个人都是贡献者，但我们只有几个提交者，他们是经理。每个人都有发言权，但不一定有投票权。
结果
到开发Velocity的时候，我们已经收到了来自64位评论者的1054条评论——大约是我们工程人员的三分之一。我们合并了187个拉请求(并关闭了30多个)，其中超过25个工程师合并了变更。这是一种更具包容性的合作方式，以前只有经理们直接参与。
但也许最大的好处是，我们现在捕获了决策过程中涉及的过程。为什么我们认为做某事是一个好主意?我们当时知道什么?什么是重要的?哪些假设没有受到挑战?
它曾经是，当我们雇用新经理时，我们会手动挖掘来自旧电子邮件的“为什么”，并在船上讨论新雇用。现在，拉请求知道为什么（更不用说谁和时间），而工程中的每个人都可以随时阅读它。
我们学到了什么
虽然我们在新的变更过程中达到了最初的目标，但当然仍然存在一些问题。对于不太熟悉GitHub的非技术人员来说，它并不能完美地工作，而且用于更改文档的UI也可能更容易。
我们正在努力提高我们的进程的包容性与培训，就像他的速度谈话中描述的亚伦太议会“GitHub for Poets”。并且我们正在使用成对编程技术来处理文档。为了使早期想法成为一个安全的地方，我们正在向主要文化回购的福克斯的福克斯转变为少数人的重点对话，进入值得分享和转向拉动请求的提案。
我们还学会了积极劝阻电子邮件讨论，将带有BCC的线程与BCC粘贴到拉动请求中。我们尝试构建我们的Repos和Orgs，因此人们可以使用GitHub通知来保持通知。在合并后保持评论也有助于保持评论，因为我们已经看到了一半讨论后发生的情况。最后，使用GitHub快速拉动请求真的有助于降低贡献障碍。
希望这篇文章激发了你对自己的组织的工程文化和过程思考，如何让他们保持一步，而且，大多数情况下，为什么这样做是很重要的。
请看下面我最初的演示文稿中的幻灯片:
经过