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.

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 cases, the "consensus" you are looking for simply does not 
exist. 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.

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.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com