和谐平等_并非所有观点都是平等的

和谐平等

This blog post is a reaction to this blog post by David Hansson. If you have the time, I highly recommend reading it. If you don’t, I’ll summarise the most relevant bits as I go.

这篇博客文章是David Hansson对这篇博客文章的回应。如果您有时间，我强烈建议您阅读。如果您不这样做，我将在总结过程中总结最相关的内容。

随心所欲 (Having Things Your Way)

David Hansson has recently written a blog post about Rails, and in particular about how Rails is an opinionated piece of software. Rails, much like Django in the Python world, is very much a ‘batteries included’ framework. It makes a series of design choices based on what its maintainers consider to be its primary use cases, which often include which ORM to use, or which templating language/engine they’ll use.

大卫·汉森（David Hansson）最近写了一篇有关Rails的博客文章，尤其是有关Rails如何成为自以为是的软件的博客。 Rails就像Python世界中的Django一样，是一个非常“包含电池”的框架。它根据其维护者认为是其主要用例的情况做出一系列设计选择，通常包括要使用的ORM或要使用的模板语言/引擎。

Hansson’s post was inspired by the regular requests to change some of the ‘batteries’ in Rails. One of his off-the-cuff examples is the inclusion of CoffeeScript in Rails. His point is that, despite it being a setting that’s possible to override, some people get annoyed about its inclusion at all.

Hansson的帖子的灵感来自经常要求更改Rails中某些“电池”的请求。他的即时示例之一是将CoffeeScript包含在Rails中。他的观点是，尽管它是可以覆盖的设置，但仍有一些人为它的包含而烦恼。

This is understandable: everyone has opinions, and its natural to want to voice them. You and I will probably not see eye-to-eye on some things (maybe even most things). This is great, and us hashing out our opinions is almost always going to be a good thing.

这是可以理解的：每个人都有自己的见解，很自然地想发表意见。您和我可能不会在某些事情上（甚至是大多数事情）保持一致。这太好了，我们散布意见几乎总是一件好事。

However, while you’re entitled to have your opinion, I’m not required to listen to it.

但是，尽管您有权发表自己的意见，但我无须听取意见。

这个问题很普遍 (This Problem Is Common)

Open source software development is communal. Most projects of any value are sufficiently large that it’s hard to manage them on your own, and so its important to have people to help, even if they only do the easy stuff.

开源软件开发是公共的。大多数具有任何价值的项目都足够大，以至于很难独自管理它们，因此，即使他们只做简单的事情，也需要人们的帮助很重要。

This means that third-party contributions are encouraged: maintainers want your ideas and your code! But, when you do this, it’s important to remember the following things:

这意味着鼓励第三方做出贡献：维护者希望您的想法和代码！但是，执行此操作时，请记住以下几点很重要：

Ideas are cheap.
‘Good’ is often subjective.
All opinions are not equal.

想法很便宜。
“好”通常是主观的。
所有观点都不平等 。

The first two points have been covered to death, but the third is interesting. To illustrate it, I want to take an example from Python Requests.

前两点已被提及，但第三点很有趣。为了说明这一点，我想以Python Requests为例。

Recently, Requests went v1.0. This was a major code change, and along with it came a change in the API. Mostly the changes were fairly mild, with the commonly-used paths being almost identical, but there was at least one significant change in the API used for Requests sessions.

最近， Requests进入了v1.0 。这是一个重大的代码更改，并且随之而来的是API的更改。大多数情况下，更改是相当温和的，常用路径几乎相同，但用于请求会话的API至少有一项重大更改。

Previously, it was possible to write code that looked like this:

以前，可以编写如下代码：

import import requests
requests
params params = = {{ 'hello''hello' : : 'world''world' }
}
s s = = requestsrequests .. sessionsession (( paramsparams == paramsparams ))

Essentially, the common configuration you wanted in the session could be passed in on the constructor. V1.0 of Requests changed the API such that you could no longer do that. Instead, the equivalent code now read:

本质上，您在会话中想要的通用配置可以在构造函数中传递。 V1.0的Requests更改了API，使您无法再这样做。现在，等效代码改为：

This change was not universally popular. In fact, in the time between the API change and the documentation update, at least six issues were opened. To be clear, this is fine: reporting a bug or inconsistency in documentation is a great thing.

这种变化并不是普遍流行的。事实上，在API的变化和文档更新之间的时间，在至少 6个问题进行打开。明确地说，这很好：报告错误或文档不一致是一件好事。

However, if you go through those issues, you’ll begin to see a common theme. In particular, one user who had not previously contributed to the project became insistent about reverting the API, despite Kenneth making it clear that the API would not be changed back.

但是，如果您经历了这些问题，就会开始看到一个共同的主题。特别是，尽管肯尼斯（Kenneth）明确表示不会改回该API，但以前从未为该项目做出过贡献的一位用户仍然坚持还原API。

This is the point I want to highlight. If you have an idea, please say it. This user did, and that was the right thing to do. He then went one step further and provided the code to implement his idea, which was also good. Up to this point, he had done everything right, and his contribution would have been well-regarded, even if ultimately rejected.

这是我要强调的重点。如果您有想法，请说出来。该用户做到了，那是正确的事情。然后，他又走了一步，并提供了实现他的想法的代码，这也很好。到现在为止，他做对了所有事情，即使最终遭到拒绝，他的贡献也将得到充分的重视。

However, when Kenneth said he did not want to change the API, that should have been the end of the discussion. This is because of reason number 3: not all opinions are equal. Fundamentally, with an open-source project, the buck stops with the maintainer. It doesn’t matter how good your idea or how well you advance it, if the maintainer doesn’t like it you should either let it go or fork the project. It is nothing short of rude to repeatedly complain about how your obviously better idea isn’t being implemented.

但是，当肯尼斯（Kenneth）说他不想更改API时，讨论应该已经结束了。这是由于原因3：并非所有观点都是平等的。从根本上讲，对于一个开源项目，维护者要承担责任。无论您的想法有多好或进展有多好，如果维护人员不喜欢它，您都可以放开它或分叉项目。反复抱怨您的更好的主意没有得到实施是不礼貌的。

The reason for this is simple: if you’ve come out of nowhere, there are loads of things about the project you don’t know. You don’t know its philosophy, its priorities, its ideals. These things come from exposure to the project, and that comes from contributing over time. For instance, I know that, for Kenneth, Requests’ API is sacrosanct. The API must be as intuitive and as simple as possible, and anything that gets in the way of this will never, ever be accepted. I also know that Kenneth’s definition of ‘simple’ is not necessarily ‘fewest lines of code’.

这样做的原因很简单：如果您无所事事，那么该项目会有很多未知的事情。您不知道它的理念，优先事项和理想。这些都是来自项目的曝光，是随着时间的推移而做出的贡献。例如，我知道，对于肯尼思（Kenneth），Requests的API是神圣不可侵犯的。该API必须尽可能直观和简单，并且任何妨碍这种方式的事情都将永远不会被接受。我也知道，肯尼思（Kenneth）对“简单”的定义不一定是“最少的代码行”。

This means that I, along with the other regular Requests contributors, don’t propose changing the API very much, and any code change we make that might affect the API gets Kenneth’s sign off before we even open a Pull Request. In turn, these learned behaviours mean that when (if) we do propose an API change, Kenneth takes it way more seriously than when someone less familiar with the project does.

这意味着我和其他常规的Requests贡献者并没有提议太多更改API，并且我们所做的任何可能影响API的代码更改都会在我们打开Pull Request之前得到Kenneth的同意。反过来，这些习得的行为意味着（如果）我们确实提出了API更改的建议，那么Kenneth会比不熟悉该项目的人更认真地对待它。

一劳永逸 (You Get One Go)

David Hansson puts it more succinctly than I do:

大卫·汉森（David Hansson）比我更简洁地说：

The less time you’ve spent in our establishment, the further away you are from helping out in the kitchen, the less weight your opinion will carry. Especially if it’s expressed in a loud, obnoxious fashion.

您在我们机构中花费的时间越少，您在厨房里提供帮助的距离就越远，那么您的意见就会越少。特别是当它以响亮，令人讨厌的方式表达时。