开源管理项目管理

在奥斯汀的OpenStack峰会期间，我有机会与一些人谈论了我在运行开源项目方面的经验。 事实证明，在社区中闲逛并为许多项目做出了多年贡献之后，我也许可以为许多新手提供一些后见之明和外在的眼光。

有大量资源说明如何在那里运行开源项目。 今天，我想换一个角度，强调在项目中不应该在社交上做的事情。 这份清单来自我过去几年遇到的各种开源项目。 我将随机列举一些我发现的不良做法，并通过一些具体示例进行说明。

将贡献者视为烦恼

当软件开发人员和维护人员忙碌时，他们不需要做一件事：更多的工作。 对许多人来说，对外部贡献的本能React是“该死，更多的工作”。 实际上是这样。

因此，一些维护者倾向于避免工作量过多：他们声明自己不希望贡献，或者使贡献者感到不受欢迎。 这可以采取许多不同的形式，从忽略它们到令人不快。 实际上，它避免了立即处理维护者肩上所增加的工作的需要。

这是开源的最大错误和误解之一。 如果有人给您发送更多工作，您应该尽一切努力使他们受到欢迎，以便他们继续与您合作。 他们可能很快就会成为代替您自己从事工作的人。 考虑退休！

让我们看一下我的朋友Gordon，我从2013年开始担任Ceilometer的贡献者。他的代码审查很棒，但是实际上他通过捕获补丁中的错误并发送我必须审查的补丁而为我提供了更多工作。 与其成为一个欺负者，不如让他停止让我重新编写代码并审阅他的补丁，我要求我们将他添加为核心审阅者，从而更加信任他 。

如果他们不做这一次的贡献，他们就不会做两次。 他们什么都不会做。 这些项目可能刚刚失去了新的维护者。

让人们只做艰苦的工作

当新的贡献者到达并希望为特定项目做出贡献时，他们的动机可能会大不相同。 他们中的一些人是用户，但其中一些人只是希望看到它如何做出贡献的人。 作为一种锻炼或一种愿意学习并愿意为他们所使用的生态系统做出贡献的意愿而获得贡献的快感。

维护人员通常的React是促使人们从事艰苦的工作。 这意味着所做的工作没有兴趣，几乎没有价值，并且可能对项目没有直接影响。

实际上有些人对此没有问题，有些则有。 当您给予他们某种认可后，有些人会感到生气来从事低影响的工作，而有些人会喜欢它。 注意它，并确保有五个人来做。 这是保持它们存在的唯一方法。

不重视小额捐款

当新贡献者提供的第一个补丁是拼写错误修复程序时，开发人员会怎么想？ 他们不在乎，您是在浪费自己的宝贵时间，而您的捐款却很少。 而且没有人关心文档中的英语不好，是吗？

错了 请参阅我对家庭辅助和后现代的最初贡献：我修复了文档中的错别字。

我为组织模式贡献了几年。 我对组织模式的第一个补丁是关于修复文档字符串的。 然后，我发送了56个补丁，修复了错误并添加了精美的功能，还编写了一些外部模块。 时至今日，我仍然在组织模式的最高提交者列表中排名第16，该列表包含390个贡献者。 因此，我不会称其为小贡献者。 我确信社区很高兴他们没有鄙视我的文档修订。

为新手设置过高的标准

当新的贡献者到达时，他们对项目，其上下文和技术的了解可能会大相径庭。 人们经常犯的错误之一是向贡献者提出他们无法意识到的过于复杂的事情。 这使他们感到害怕（许多人会变得害羞或内向），他们可能会消失，感到愚蠢而无法帮助。

在发表评论之前，您不应对他们的知识有任何假设。 那应该避免这种情况。 在评估他们的技能时，您也应该非常谨慎，因为如果您低估了他们，有些人可能会感到烦恼。

一旦正确评估了该级别（应该进行几次交流就足够了），您需要指导您的贡献者正确的程度，以便他或她能够开花。 掌握它需要时间和经验，您可能会在此过程中失去其中的一些，但这是每个维护者都必须采取的方法。

无论是什么项目，指导都是欢迎新的项目参与者的一个非常重要的方面。 我敢肯定，它也可以很好地适用于外部免费软件。

要求人们牺牲自己的生命

这是一个因项目和上下文而异的方面，但确实很重要。 作为一个自由软件项目，大多数人将以自己的善意做出贡献，有时还会腾出空余时间，您不得要求他们做出重大牺牲。 这行不通。

最糟糕的实现之一是要求人们飞行5,000公里才能在某个地方见面讨论该项目。 基于供款人离家一周的能力，乘飞机/轮船/汽车/火车，租用旅馆等，这使供款人处于不公平的位置。这不好，应避免一切都要求人们这样做是为了参与并感到自己参与了该项目，并融入了您的社区。 不要误会我的意思：相反，这并不意味着应该禁止社交活动。 在讨论任何项目时，只要避免排斥他人即可。

这同样适用于任何其他形式的讨论，使所有人都难以参与：IRC会议（某些人很难预定一个小时，尤其是取决于他们所居住的时区），视频会议（尤其是使用非免费会议）软件）等

要求人们在一段时间内基本与项目进行交互的所有内容都会给他们带来约束，使他们感到不舒服。

最好的媒体仍然是电子邮件和异步派生工具（错误跟踪器等），因为它们是异步的，并允许人们按自己的节奏按自己的时间工作。

没有（暗示的）行为准则

行为准则似乎是一个时髦的话题（也是一个棘手的话题），因为越来越多的社区向比以往更多的受众开放，这很棒。

实际上，所有社区都有行为准则，用黑墨水书写，或者在每个人的意识中不自觉地携带。 它的形式取决于社区的规模和文化。

现在，根据您社区的规模以及您对使用它的感觉如何，您可能希望像在Debian中那样将其包含在文档中 。

遵循行为准则，行为守则并不能将整个项目社区神奇地转变为一群照料者。 但这提供了一个有趣的观点，您可以在需要时立即参考。 它可以帮助把它扔给某些人，以表明他们的行为在项目中不受欢迎，并以某种方式缓解了他们潜在的排斥，即使没有人愿意走这么大的距离，而且这种行为很少有用。

我认为在较小的项目上写这样的论文不是强制性的。 但是您必须记住，隐式的行为准则将源于您自己的行为。 您的领导者与他人沟通的方式将设定项目的整个社交氛围。 不要小看。

当我们开始Ceilometer项目时，我们甚至在《 OpenStack行为准则》还没有出现之前就暗中遵循了它，并且可能将门槛提高了一点。 我们态度友善，热情，开放，在多元化方面取得了不错的成绩，我们核心团队中有25％是女性，远远超过了OpenStack和大多数开源项目中的现有比例！

使不讲英语的人感觉像局外人

非常重要的一点是要意识到，那里的绝大多数自由软件项目都使用英语作为交流的通用语言。 这很有意义：它是一种常见的语言，似乎可以正确完成工作。

但是，那里的大部分黑客都不以英语为母语。 许多人不能说一口流利的英语。 这意味着他们交流和进行对话的速度可能很低，这会使某些人感到沮丧，尤其是说英语的人。

这种现象的主要表现可以在人们辩论的社交活动（例如会议）中看到。 人们很难用英语解释他们的想法，并很难以适当的速度进行适当的交流，从而使对话和思想交流变慢。 在这种情况下，最糟糕的事情是说英语的母语人士将人们拒之门外而无视他们，只是因为他们说话太慢。 我确实知道这可能令人沮丧，但是这里的问题不是非母语的英语，而是所使用的媒介无法通过口头交谈来使您的同伴与所有人处于同一水平。

在较小程度上，这也适用于相对同步的IRC会议。 完全异步的媒体没有此缺陷，这就是我认为它们也应被首选的原因。

没有远见，没有授权

开源项目中最常遇到的两个错误：看到维护者在项目的发展过程中苦苦挣扎，而又有人在寻求帮助。

确实，当贡献者开始涌现，添加新功能，征求反馈和指示时，一些维护人员会感到cho恼，不知道如何应对。 最终导致令人沮丧的贡献者，因此他们可能会消失。

对项目有远见并进行沟通很重要。 向贡献者明确说明您在项目中想要或不需要的东西。 以明确的方式（而不是侵略性的）进行转移是减少贡献者之间摩擦的好方法。 他们很快就会知道是否要加入您的船，以及期望如何。 所以当个好队长。

如果他们选择与您合作并做出贡献，则应尽快开始信任他们并委派您的一些职责。 这可以是您曾经做过的任何事情：查看补丁，针对某些子系统，修复错误，编写文档。 让人们拥有项目的整个部分，让他们感到责任心并像您一样关心它。 相反，这是一个控制狂，是与开源软件独处的最佳选择。

而且没有一个项目能够以这种方式发展壮大。

2009年，当Uli Schlachter将他的第一个补丁发送给awesome时 ，这对我来说是更多的工作。 我必须审查此补丁，并且我已经非常忙于设计awesome的新版本并完成我的日常工作！ Uli的工作并不完美，我必须自己修复。 更多的工作。 那我做了什么？ 几分钟后，我以清晰的计划回答了他应该做什么以及我对他的工作的想法。

作为回应，Uli发送了补丁并改进了该项目。 你知道乌里今天做什么吗？ 自2010年以来，他代替我管理着很棒的窗口管理器项目。 我设法传达了我的愿景，委托，然后退休了！

不承认捐款

人们以不同的方式做出贡献，但它并不总是代码。 自由软件项目周围有很多东西：文档，错误分类，用户支持，用户体验设计，交流，翻译……

例如， Debian花费了一段时间才意识到他们的翻译人员可能具有Debian Developer的身份。 OpenStack通过尝试识别非技术性贡献而朝着同一个方向努力。

一旦您的项目开始将徽章分配给某些人并在社区中创建不同成员的类，您应该非常小心，以免忘记任何人。 这是沿途失去贡献者的最简单方法。

别忘了感恩

整个清单的灵感来自多年的开源黑客和免费软件贡献。 每个人的经历和感受可能有所不同，或者可能以不同的形式看到了渎职行为。 让我知道您是否遇到其他阻碍您参与开源项目的事情！

翻译自: https://opensource.com/business/16/6/bad-practice-foss-projects-management

开源管理项目管理