近两年来，我一直在组织 波士顿 DevOps 聚会 。当组织者的位置打开时，我抓住了这个机会。我在较小的组织中进行 DevOps 的经历让我对这场运动有了非常狭隘的看法，我想自学。我也想在公开演讲方面做得更好（仍在努力）。
我与很多人交谈过，他们在不同的组织中学习、努力并最终在 DevOps 方面取得进展。我们在波士顿和剑桥的多个场所举办了演讲、座谈会和开放空间。我们与其他本地聚会合作，讨论了从招聘到可穿戴设备的方方面面。
一如既往，YMMV，但这里有一些我在为我们的社区组织活动时学到的东西，这些东西在我开始时并不明显。
1. 待人接物需要持之以恒的努力
这确实适用于任何社区，但欢迎新成员不仅仅是提供一个很酷的场所和比萨饼。你真的必须花时间鼓励新人。由于我们不同意 DevOps 的定义，大多数人开始感到不安，不确定他们如何做出贡献。
不是每个工程师都是内向的，也不是每个营销人员都是外向的。 根据工作职能将人们分组为原型并不是开始新关系的好方法。这是我们的人性在挫败我们——我们试图通过模式匹配来节省时间和精力。它不起作用。聚会的目的是进行真正的人际互动，而不是让每个人都简单地扮演自己的角色。
那你 应该 怎么办？
- 花点时间迎接新成员。让他们在第一次见面时站起来做介绍。吓人，我知道，但是把名字写在脸上是关键。
- 加倍努力邀请和欢迎非工程师。
- 将每一次互动都视为独一无二的。在人群中，错误的做法是与少数人进行真正的对话，而不是与许多人说一句话。 当人们与您交谈时，不要扫视房间。
- 更喜欢遵循学习曲线的演示文稿。从基础开始，最后深入学习。 “X for beginners”对于整个房间来说不是一个很好的展示 - 将它分成一个开放空间。
2. 不要对话题谨慎行事
这是我看到很多聚会掉入的陷阱。对不起组织者，但这是真的。 为您拥有的组而不是您想要的组定制您的内容会创建一个回音室 。当我接管波士顿 DevOps 时，我们是运营人员谈论工具。我们有意识地决定开始更多地谈论对齐。现在我们拥有来自组织所有角色的活跃成员。
如果没有人在您的活动中争论，这是一个不好的迹象。 尤其是在 DevOps 中，我们试图弄清不同群体面临的动机和限制。辩论很精彩。我们瞥见了现实世界，那里并非一切都是非黑即白、0 或 1。为此，组织者应该鼓励相互尊重的辩论。这也意味着当有人越界时要处理它。
如果您生活在回音室中，这里有一些建议：
- 喜欢不切题的话题。 Docker 教程很好，但是关于部署 Docker 的圆桌会议更好。
- 邀请您所在领域以外的人在您的活动中发言。他们的观点很有价值。
- 以创造性的方式交叉推广您的活动。去参加一个项目管理或物联网聚会，和那里的人谈谈参加你的下一个活动。
- 改变你的格式。很容易进入舒适的模式。举行一些小组讨论和开放空间讨论。
3.供应商：信任但验证
有很多伟大的公司生产软件来简化协作。聚会需要赞助商，这些公司是天作之合。我们有很多代表在我们的聚会上做演讲。有时这很好——他们就如何思考我们面临的问题提出了新的想法。有时它不是那么好 - 一个无耻的产品插件。
我认为这里最有趣的要点是 无耻的产品插件不会让您受到 DevOps 人群的喜爱 。它们可能弊大于利。在这些听众中，声誉为王——如果你背叛了给予你的信任，聚会的成员和组织者 将会 记住。
我学会了一些避免这种情况的方法：
- 在您的第一次谈话中设定期望，例如，不允许供应商推销，并与您交谈的每个人保持一致。无特殊处理。
- 除非他们谈论的是销售/营销在 DevOps 中的作用，否则演示者应该是从业者。
- 邮件列表是神圣的。不要交出它，即使是暂时的。尽早制定这条规则并坚持下去。
我写这篇文章的目的不是挑剔其他聚会组织者。这更像是我对技术社区如何从内部演变的描述。我真的很感激成为 DevOps 社区的一员。关于我们面临的难题的坦诚对话是 DevOps 活动中最精彩的部分。
当然，我自己无法做到这一切。我有一个很棒的共同组织者 Dave Fredricks ( @dfreddy76 )，他非常了解高管的观点并且擅长物流。我也有很多人帮助我确定要谈论的有用话题。谢谢大家！
