The two are not mutually exclusive. There's no reason why people cannot be
civil AND improve the community. Pretending it's a non-issue is only doing
yourself a disservice. If anything I feel you should apologize for your
rudeness to the core committers, it's completely unwarranted.


On Sat, May 3, 2014 at 3:33 PM, Felipe Contreras <felipe.contreras / gmail.com
> wrote:

> 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
>