[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Social Committee proposal



On Fri, 26 Jan 2007 02:25:40 +0100, Josip Rodin <joy@debian.org> said: 

> On Thu, Jan 25, 2007 at 07:06:33PM -0600, Manoj Srivastava wrote:
>> > I should also note that we have this sort of an effect already -
>> > if someone wishes to impose their ideas on others, for example to
>> > modify a certain package in a way that they think is right, they
>> > can usually achieve it by working hard enough and being patient
>> > enough to take over the package.
>> 
>> > Yet, we also have a tyranny of the minority effect, when e.g. a
>> > person with an uncommon opinion maintains a package in a way that
>> > contradicts with the wishes of others.
>> 
>> In both these cases, those that do the work make the decisions.
>> People who do not like it, and are willing to do the work, can fork
>> and offer alternatives.
>> 
>> We don't generally let the majority decude how the working minority
>> does its work.

> Er, that's not a technically sound argument. Just because someone is
> more diligent in making uploads and more vocal in trying to explain
> why they should maintain a package, that doesn't in any way imply
> that what they are doing is better than what a person less intent on
> racing uploads and mailing list posts would be doing.

        I was not defending the practice; I was pointing out that the
 proposed soc ctte thing is different from what we do with packages.
 There are vast amounts of leeway a package maintainer exercises over
 their package, but they do not have the power to block a fork.

        So, if your hypothetical more effective maintainer can't
 convince the incumbent about how to do things better, can't file bugs
 about th deficiencies and provide patches (and perhaps NMU's for the
 more egregious flaws), they can offer alternatives, either on p.d.o,
 or as a forked package, or, finally, as a last resort, go to the tech
 ctte; but only with legitimate non-subjective technical grievances.

        While this might not provide the best maintainer-package
 mapping, nor the most efficient one -- it is a model that has worked
 for us.

        I do pay far more attention to packages that are mine; there
 is a sense of ownership, and hos the packages are maintained reflects
 on me.  I, personally, take greater care of my packages than I would
 of anything I am merely part of a team; I would not push off sleep or
 work tasks in order to maintain the latter (let the rest of the team
 deal with it in my crunch time); but since it is my responsibility, I
 go the extra mile.

        I am rambling.

        OK, so we do carve out little fiefdoms on the packaging side;
 but I think it does have a benefit of added incentive. That is the
 rationale.

        manoj
-- 
He that would govern others, first should be the master of himself.
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: