agpl限制了开源

by Julien Danjou

通过朱利安·丹乔(Julien Danjou)

不要限制您的开源项目的潜力 (Don’t limit your open source project’s potential)

During the OpenStack summit a few weeks ago, I had the chance to talk to some people about my experience on running open source projects. It turns out that after hanging out in communities and contributing to many projects for years, I may be able to provide some hindsight and an external eye to many of those who are new to it.

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

There are plenty of resource explaining how to run an open source projects out there. Today, I would like to take a different angle and emphasize what you should not socially do in your projects. This list comes from various open source projects I’ve encountered these past years. Let’s explore these bad practices and illustrate them with examples.

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

不要将新的贡献者视为烦恼 (Don’t perceive new contributors as an annoyance)

When software developers and maintainers are busy, there’s one thing they don’t need: more work. To many people, the instinctive reactions to external contribution is: damn, more work. And actually, it is.

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

So some maintainers tend to avoid that surplus of work. They explicitly state that they don’t want contributions, or they passive-aggressively make contributors feel un-welcome. This can take a lot of different forms, from ignoring them to being unpleasant. This allows the project maintainer to avoid coaching new contributors on how they can productively add to the project.

因此，一些维护者倾向于避免过多的工作。 他们明确声明自己不想要贡献，或者他们被动地积极地使贡献者感到不受欢迎。 从忽略它们到令人不快，这可以采取许多不同的形式。 这使项目维护者可以避免指导新的贡献者如何有效地添加到项目中。

This is one of the biggest mistakes you can make in open source. If people are sending you more work, you should do whatever it takes to feel them welcome, so that they will continue working with you. Pretty soon they might become the people doing the work you are doing, instead of you. Just think: retirement!

这是您在开源中可能犯的最大错误之一。 如果人们给您发送了更多工作，则您应该尽一切努力使他们受到欢迎，以便他们继续与您合作。 很快，他们可能会代替您，成为从事您正在做的工作的人。 试想：退休！

Let’s take a look at my friend Gordon, who started as a Ceilometer contributor in 2013. He was doing great code reviews, but he was actually giving me more work by catching bugs in my patches and sending me patches that I had to review. Instead of being a bully so that he would stop making me rework my code and review his patches, I requested that we trust him even more by adding him as a core reviewer.

让我们看一下我的朋友Gordon，他于2013年开始担任Ceilometer的贡献者。他进行了出色的代码审查，但实际上，他通过捕获补丁中的错误并将需要审查的补丁发送给我，为我提供了更多的工作。 我要求自己不再是一个欺负人，以免他停止让我重新编写代码并审阅他的补丁， 而是要求我们将他添加为核心审阅人，从而更加信任他 。

If contributors aren’t able to make their first contribution, they definitely won’t make a second one. They won’t make any. And the project may very well have lost its future maintainers.

如果贡献者无法做出第一笔贡献，那么他们肯定不会做出第二笔贡献。 他们什么都不会做。 这个项目很可能已经失去了未来的维护者。

不要将您的贡献者仅限于艰苦的工作 (Don’t limit your contributors to just grunt work)

When new contributors arrive and want to contribute to a particular project, they bring with them a wide range of motivations. Some of them are users, but some of them are just people looking to see what it’s like contributing to an open source project. They want the thrill of giving back to an ecosystem that they use.

当新的贡献者到达并希望为特定项目做出贡献时，他们就会带来各种各样的动机。 他们中的一些人是用户，但其中一些人只是希望了解对开源项目做出贡献的人们。 他们希望获得回馈他们使用的生态系统的快感。

The usual response from maintainers is to push people into doing grunt work. That means doing jobs that have no interest, little value, and probably have no direct impact on the project.

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

Some people actually don’t mind doing grunt work, but others do. Some people will love it as soon as you give them something — anything — to do and acknowledgment for their efforts. But others will feel offended that you’ve asked them to do low impact work. Be aware of this, and be sure to high-five the people doing your grunt work. That’s the only way to keep them around.

实际上，有些人不介意从事艰苦的工作，而其他人则愿意。 只要您给他们一些东西(任何东西)并感谢他们的努力，有些人就会喜欢它。 但是其他人会感到生气，因为您要求他们进行影响较小的工作。 请注意这一点，并确保有五名从事您的艰苦工作的人。 这是保持它们不动的唯一方法。

别忘了赞美即使很小的贡献 (Don’t forget to praise even small contributions)

When the first pull request a new contributor sends over is just a typo fix, some developers will feel annoyed at the prospect of wasting precious time vetting such a small contribution. And nobody cares about bad English in their documentation anyway, right?

当新贡献者发送的第一个请求只是一个错字修复程序时，一些开发人员会因为浪费宝贵的时间审查如此小的贡献而感到恼火。 无论如何，没人会在意文档中的英语不好，对吧？

My first contributions to home-assistant and Postmodern were me fixing typos in their documentation.

我对家庭助理和后现代主义者的第一个贡献是我在他们的文档中修正了错别字。

I contributed to Org-mode for a few years. My first patch to orgmode was about fixing a docstring. Then, I sent 56 patches, fixing bugs and adding fancy features. I also wrote a few external modules. To this day, I’m still #16 on the top-committer list of Org-mode, which lists 390 contributors. So I ended up being much more than a small contributor to their project. I’m pretty sure in retrospect their community was glad that they didn’t dismiss my documentation fix as a waste of their time.

我为组织模式做出了几年的贡献。 我对orgmode的第一个补丁是关于修复文档字符串。 然后，我发送了56个补丁，修复了错误并添加了精美的功能。 我还写了一些外部模块。 时至今日，我仍然在组织模式的最高提交者列表中排名第16，该列表列出了390个贡献者。 因此，我最终不仅仅是为他们的项目贡献一小笔钱。 我很确定，回想一下他们的社区很高兴他们没有因为浪费时间而忽略了我的文档修订。

不要为新手设置过高的门槛 (Don’t set the bar too high for new comers)

When new contributors arrive, their knowledge about the project, its context, and the technologies can vary largely. One of the mistakes project maintainers often make is to ask contributors to perform a bunch of complicated tasks before they can contribute. This can have the effect of scaring away many contributors who are are relatively shy or introverted. They may just disappear, feeling too stupid to help.

当新的贡献者到达时，他们对项目，其上下文和技术的了解可能会大相径庭。 项目维护人员经常犯的一个错误是，要求贡献者执行一堆复杂的任务，然后才能做出贡献。 这可能会吓跑许多相对害羞或内向的贡献者。 他们可能会消失，感觉太愚蠢而无法帮助。

Before making any comment, you should not have any assumption about their knowledge. You also should be very delicate when assessing contributor skills, as some people might feel vexed if you underestimate them too much.

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

Once their skill level has been properly evaluated (a few exchanges should be enough), you need to mentor your contributor to the right degree so they can blossom. It takes time and experience to master this, and you may likely lose some of them in the process, but it’s a path that every maintainer has to take.

在正确评估了他们的技能水平之后(应该进行几次交流就足够了)，您需要指导贡献者达到正确的程度，这样他们才能成长。 掌握它需要时间和经验，您可能会在此过程中失去其中的一些，但这是每个维护者都必须采取的方法。

Mentoring is a very important aspect of welcoming new contributors to your project, whatever it may be. Mentorship applies nicely outside free software too.

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

不要让别人为了帮助你而牺牲 (Don’t make people to make sacrifices in order to help you)

This is an aspect that varies a lot depending on the project and context, but it’s really important. As a free software project, where most people will contribute on their own good will and sometimes spare time, you must not require them to make big sacrifices. This won’t work.

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

One of the worst things you can do is require contributors to fly 5,000 kilometers to meet in person to discuss the project. This puts contributors in an unfair position, based on their ability to leave their family for a week, take a plane/boat/car/train, rent an hotel, etc. This is not good, and you should do everything in your power to avoid requiring contributors to do this in order to participate in the project and feel included in its community.

您可以做的最糟糕的事情之一就是要求参与者飞行5,000公里，亲自见面讨论该项目。 根据供款人离开家人一周的能力，乘飞机/轮船/汽车/火车，租用酒店等，这会使供款人处于不公平的位置。这不好，您应该尽一切可能避免要求贡献者这样做才能参与该项目，并使其融入社区。

Don’t get me wrong. I’m not saying that social activities should be prohibited. Quite the contrary. Just avoid excluding people when you discuss any project.

不要误会我的意思。 我并不是说应该禁止社交活动。 恰恰相反。 在讨论任何项目时，只要避免排斥他人即可。

The same applies to any other form of discussion that makes it complicated for everyone to participate: IRC meetings (it’s hard for some people to book an hour, especially depending on the timezone they live in), video-conferencing (especially using non-free software), etc.

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

Everything that requires people to basically interact with the project in a synchronous manner for a period of time will put constraints on them that can make them uncomfortable.

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

The best medium is still e-mail and asynchronous derivatives (like bug trackers) which allow people to work at their own pace on their own time.

最好的媒介仍然是电子邮件和异步派生工具(例如错误跟踪器)，使人们可以按自己的节奏按自己的时间工作。

别忘了您有书面或暗示的行为准则 (Don’t forget to that you have a Code of Conduct — written or implied)

Conduct codes seem to be a trendy topic (and a touchy subject), as more and more communities open up to a wilder audience than before — which is great.

行为准则似乎是一个时髦的话题(也是一个敏感的话题)，因为越来越多的社区向比以前更开放的受众开放了，这是很棒的。

Actually, all communities have a code of conduct, whether it’s written with black ink, or being carried in everyone’s mind unconsciously.

实际上，所有社区都有行为准则，无论是用黑色墨水写成的行为准则，还是无意识地带入每个人的头脑中的行为准则。

Now, depending on the size of your community and how you feel comfortable applying it, you may want to write it down in a document, like Debian did.

现在，根据您社区的规模以及您对它的使用感觉如何，您可能想要像Debian一样将其记录在文档中 。

Having a code of conduct does not transform your whole project community magically into a bunch of care bears who follow its guidance. But it does provide an interesting artifact that you can refer to when needed. You can throwing it at some people, to indicate that their behavior is not welcome in the project, and somehow, ease their potential exclusion — even if nobody wants to go that far generally, and that’s it’s rarely that useful.

制定行为准则并不能将整个项目社区神奇地转变为遵循准则指导的一堆护理熊。 但是它确实提供了一个有趣的工件，您可以在需要时引用它。 您可以将其扔给某些人，以表明他们的行为在项目中不受欢迎，并以某种方式减轻了他们潜在的排斥-即使没有人愿意走这么大的距离，这很少那么有用。

I don’t think it’s mandatory to have such a paper on smaller projects. But you have to keep in mind that the implicit code of conduct will be derived from your own behavior. The way your leader(s) communicate with others will set the entire social mood of the project. Do not underestimate that.

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

When we started the Ceilometer project, we implicitly followed the OpenStack Code of Conduct before it even existed, and probably set the bar a little higher. Being nice, welcoming and open-minded, we achieved a decent diversity score, with up to 25% of our core team being women — way above the current ratio in OpenStack and most open source projects!

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

不要让非英语母语者感到局外人 (Don’t make non-native English speakers feel like outsiders)

It’s quite important to be aware of that the vast majority of free software projects out there are using English as the common language of communication. This makes a lot of sense: it’s a commonly spoken language, and it seems to do the job well.

非常重要的是要意识到，那里的绝大多数自由软件项目都使用英语作为交流的通用语言。 这很有道理：这是一种常用的语言，似乎做得很好。

But a large proportion of the hackers out there are not native English speakers. Many are not able to speak English fluently. This means that the rate at which they can have a conversation might be slow, which can frustrate native English speakers.

但是，大部分的黑客不是以英语为母语的。 许多人不能说一口流利的英语。 这意味着他们可以进行交谈的速度可能很慢，这可能会使以英语为母语的人感到沮丧。

The principal demonstration of this phenomena can be seen in social events (e.g. conferences) where people are debating. It can be very hard for people to explain their thoughts in English and to communicate properly at a decent rate, making the conversation and the transmission of ideas slow.

这种现象的主要表现可以在人们辩论的社交活动(例如会议)中看到。 人们很难用英语解释他们的想法，并很难以适当的速度进行适当的交流，从而使对话和思想交流变慢。

The worst thing that one can see in this context is a native English speaker cutting people off and ignoring them, just because they are talking too slowly. I do understand that it can be frustrating, but the problem here is not the non-native English speaking — it’s that the medium being used does not put your fellow coders on an the same even playing field that asynchronous conversation would.

在这种情况下，最糟糕的事情是说英语的母语人士将人们拒之门外而无视他们，只是因为他们的谈话太慢了。 我确实知道这可能会令人沮丧，但是这里的问题不是非母语的英语-这是因为使用的介质不会将您的其他编码人员置于与异步对话相同的竞争环境中。

To a lesser extent, the same applies to IRC meetings, which are relatively synchronous. Completely asynchronous media do not have this flaw, and that’s why they should also be preferred.

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

没有远见，没有授权 (No vision, no delegation)

One of the most common tragedies in the open source world is seeing a maintainer struggling with the growth of their project while other contributors are unsuccessfully trying to help them.

开源世界中最常见的悲剧之一是，维护人员正在为项目的增长而苦苦挣扎，而其他贡献者却没有设法帮助他们。

Indeed, when an influx of new contributor starts asking for new features, feedback, or directions, some maintainers choke and don’t know how to respond. This ends up frustrating contributors, who therefore may simply vanish.

确实，当大量新贡献者开始要求提供新功能，反馈或指示时，一些维护人员会感到ke恼，不知道如何应对。 这最终导致令人沮丧的贡献者，因此他们可能会消失。

It’s important to have a vision for your project and to communicate it. Make it clear to your contributors what you want and don’t want in your project. Transferring that in a clear (and non-aggressive, please) manner, is a good way of lowering the friction between contributors. They’ll pretty soon know whether they want to join your ship or not, and what to expect. So be a good captain.

对项目有远见并进行沟通很重要。 向您的贡献者明确说明您在项目中想要和不想要的东西。 以明确的方式(而不是侵略性的)进行转移是减少贡献者之间摩擦的好方法。 他们很快就会知道他们是否要加入您的船，以及会发生什么。 所以做个好队长。

If they chose to work with you and contribute, you should start trusting them as soon as you can, and delegate some of your responsibilities. These can be any tasks that you used to do yourself: review patches targeting some subsystem, fixing bugs, or writing docs.

如果他们选择与您合作并做出贡献，则应尽快开始信任他们，并委派您的一些职责。 这些可以是您自己执行的任何任务：查看针对某些子系统的补丁程序，修复错误或编写文档。

Let people own an entire part of the project, so they feel responsible and care about it as much as you do. Doing the opposite — being a control-freak — is your best shot at staying alone with your open source software. And no project is going to grow and become successful that way.

让人们拥有项目的整个部分，让他们感到责任心并像您一样关心它。 相反，做个怪胎是与开源软件独处的最佳选择。 而且没有任何项目能够以这种方式发展壮大。

In 2009, when Uli Schlachter sent his first patch to awesome, this was more work for me. I had to review this patch, and I was already pretty busy designing the new versions of awesome and doing my day job! Uli’s work was not perfect, and I had to fix it myself. More work. And what did I do? A few minutes later, I replied to him with a clear plan of what he should do, and what I thought about his work.

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

In response, Uli sent patches and improved the project. Do you know what Uli does today? He manages the awesome window manager project, and has since 2010 instead of me. I managed to transmit my vision, delegate it, and then retire!

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

注意识别各种贡献 (Be careful to recognize all kinds of contributions)

People contribute in different ways, and it’s not always with code. There are a lot of tasks surrounding free software projects: documentation, bug triage, user support, user experience design, communication, translation…

人们以不同的方式做出贡献，而并非总是使用代码。 关于自由软件项目，有很多任务：文档，错误分类，用户支持，用户体验设计，交流，翻译...

For example, it took a while for Debian to recognize that they should grant their translators the status of Debian Developer. OpenStack is working in the same direction by trying to recognize non-technical contributions.

例如， Debian花了一段时间才意识到他们应该授予翻译者Debian Developer的身份。 OpenStack通过尝试识别非技术性贡献而朝着同一个方向努力。

As soon as your project starts attributing badges to some people and creating different classes of members in the community, you should be very careful that you don’t forget anyone. That’s the easiest road to losing contributors along the road.

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

别忘了感恩 (Don’t forget to be thankful)

This whole list has been inspired by many years of open source hacking and free software contributions. Let me know in the comments section if you have anything that has blocked you from contributing to open source projects. Thanks for reading!

整个清单的灵感来自多年的开源黑客和免费软件贡献。 如果您有任何阻碍您参与开源项目的内容，请在评论部分让我知道。 谢谢阅读！

Original article at https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice

原始文章位于https://julien.danjou.info/blog/2016/foss-projects-management-bad-practice

翻译自: https://www.freecodecamp.org/news/the-bad-practice-in-foss-projects-management-32f66c3515f9/

agpl限制了开源