是什么阻止您在开放环境中工作？
我在一家开源公司从事一个开源项目，但每天仍然遇到这样的情况：从事开源软件的人员更喜欢私下工作（有时是这样）。他们不在公共邮件列表中讨论技术问题，正常的聊天发生在内部聊天室而不是公共 IRC 中，新功能宁愿在私人视频会议频道上演示，也不像例如 Hangout on Air 那样公开演示。
当然，有些情况下沟通必须是私密的：如果涉及到客户或客户数据，那么（特别是对于上市公司而言）就需要私下对话。销售额或其他财务方面也是如此。但现实情况是，工程师们大多数时候听不到任何销售额方面的信息。而且大多数客户案例都只是通用的软件问题，在不提及客户姓名的情况下，可以公开讨论。这就引出了一个问题，为什么人们不公开协作——尤其是在最终的源代码发布到像 GitHub 这样的公共仓库时。
害怕泄露
当您与客户合作时，总会有像客户支持这样的部门无法在开放环境中工作，这意味着他们不会加入公共 IRC 频道，而是加入私人频道，以保持客户数据的私密性。从事此类客户案例的工程师可能始终潜在地担心，讨论案例细节可能会泄露客户数据，因此无论是否讨论任何客户特定问题，都始终在内部频道上进行讨论。这就引出了下一个问题。
选择和切换的麻烦
当您在内部频道处理客户相关数据时（并且因为相应的同事只能通过这种方式联系），您必须不断思考和决定某个消息是否可以发布到公共频道。可以理解的是，此类案例评论是在内部频道上进行的，为了获得连贯的思路，仍然应该留在内部频道。关于其他非客户相关问题的讨论则应该转到公共频道，这意味着需要不断切换频道。这种选择和切换频道无疑是一种麻烦，人们会尽量避免。
不确定性
可能也存在这样的情况：工程师正在处理客户的功能请求或错误，但这些请求或错误并非任何客户特有。但仍然存在不确定性，不知道这项工作是否可以公开讨论。因此，在有疑问的情况下，讨论再次发生在私下。
害怕分心
虽然社区贡献（据称）总是受欢迎的，但它也可能被视为一种分心来源。项目的核心成员可能不得不中断她的工作，开始思考社区成员的观点，然后再回到原来的工作。这有时可能会让人分心，尤其是在您有时间限制的版本发布时，因此这可能不受欢迎。
感知不到好处
我们的项目社区相当小，这可能会引出一个问题：如果似乎没有人感兴趣，为什么要公开讨论事情？为什么要经历上述所有麻烦？如果没有观察者，树真的会在森林里倒下吗？
缺乏自信
另一个可能的原因可能是害怕承担责任和可追溯性。乍一听可能觉得可笑，因为源代码最终会出现在公共仓库中。这里更深层的原因可能是缺乏自信。公开的讨论会被记录为聊天记录、功能演示视频或博客文章，这使得其他人可以提出批评性反馈，并可能使当事人感到不自信。
我坚信在开放环境中工作是好的。即使社区很小。在开放环境中工作可以让您从社区成员那里获得输入，从而丰富对问题领域的了解。其他人会给出完全不同的视角，并可能列出您从未想到的用例。此外，如果社区成员被纳入整个社区，他们会感觉更好，并开始做出更多贡献。有关如何以代码以外的方式做出贡献的想法，请参阅我的文章：不编写代码为开源项目做贡献的 10 种方式。
我与社区成员的相遇经历非常好，因为每个人都很友好，并且与社区成员亲自见面总是很有趣。那么，我们能做些什么来克服我上面列出的障碍呢？
- 首先，制定一项政策，规定除非有充分的理由反对，否则所有沟通都必须默认在公共频道上进行。
- 提醒自己从公共频道开始新的一天。当您从那里开始时，它会为自己设定某种默认设置。它也鼓励其他人在那里聊天，从而建立起足够的规模，让对话进行下去。
- 不时提醒人们注意上述政策。
- 尽快将客户信息与技术信息分离。也许直接在支持人员层面进行分离。NullPointerException 就是 NPE，无论是由付费客户还是社区成员报告的。
- 记录公共频道，以便社区成员可以重读讨论的内容。
- 如果您需要安静地工作，那么不要只将外部社区拒之门外。关闭外部通信，完成您的工作，然后再回来——分心就是分心，无论来自其他社区人员还是同事。
- 如果您觉得编写（例如，解释您的工作或新功能的博客文章）感到不舒服，请先将其交给您信任的另一个人。除非您甚至没有尝试交付好的结果，否则不会有糟糕的文章。更广大的社区总是会感谢任何额外的信息。
1 条评论