On Sat, May 3, 2014 at 3:05 PM, Kevin Walzer <kw / codebykevin.com> wrote:
> On 5/3/14, 3:24 PM, Felipe Contreras wrote:
>>
>> If you lose him because of a disagreement on how "%s %z" should be
>> parsed (and he disagrees with everyone on this), maybe he wasn't worth
>> working with in the first place.
>
> In most open source projects, maintainers of a module/library/component of
> the core library are the final arbiter of what patches are accepted into
> their domain. Patches may be rejected for any reason or no reason.

That is simply not true.

> Speaking as the maintainer of a significant upstream component of Ruby (Tk's
> Mac bindings), I am grateful for patches. The submitter may very well be
> smarter than me about the subject in question and I am happy to commit their
> patch if the use-case is reasonably well-explained, and causes no
> side-effects when applied.
>
> However, sometimes I do not accept patches. This could be because I don't
> understand the use case for the patch, do not agree with the solution to the
> problem, or do not agree that the issue in question *is* a problem. In such
> cases, the only time I would expect to be second-guessed by another member
> of the project would be if their technical expertise were greater than or
> equal to mine.

In most projects when one or more maintainers of other modules might
disagree, and then there's always a leader (e.g. Linus Torvalds) that
makes the final decision. So no, in most projects the module
maintainers are not the final arbiters of what goes in those modules.

> In most cases, the "consensus" you are looking for simply does not exist.

But in this case there is. That's why Time.strptime() got fixed,
Rubinius's Time.strptime() got fixed, and Rubinius DateTime.strptime()
got fixed.

> Patches are not reviewed by a committee, patches are typically reviewed by
> individuals who provide expertise that other members of the project lack. If
> an individual with unique or significant expertise leaves a project, there
> simply may not be anyone to replace him or her. When the maintainer involved
> is the original author of the code, this is especially true. Matz has
> indicated as much with the maintainer in question.

There is a concept know as the "bus factor" that measures how
concentrated is the knowledge shared in the team. If losing a single
developer can cause such big problems, that's not ideal.

> I can also echo others in this thread that the arrogance you have displayed
> in your comments far overshadows any technical merit your arguments might
> have. In my own domain, I welcome constructive disagreement and can even be
> persuaded by it, but if you come at me with the kind of combative attitude
> you have displayed, I will end the discussion quickly and advise you to
> maintain your own fork of the code with your patch applied--that is, after
> all, one of the benefits of open source.

So you don't care what is better for the Ruby project, you just want
to have nice and pleasant discussions. Got it.

[1] http://en.wikipedia.org/wiki/Bus_factor

-- 
Felipe Contreras