Re: infrastructure team rules
On Tue, 16 Oct 2007, Lucas Nussbaum wrote:
> > Yes. They should all have a mechanism to stop them from calcifying.
>
> I really don't think that the qa group, the webwml group, the list
> admins, etc need such bureaucracy ... According to your definition, your
> proposal apply to them too (they have a unix group, and have access to
> resources in ways other than the standard practice).
As long as the bureaucracy is just the fallback that people use when there
are problems, I'm fine with that. And really it's not much bureaucracy,
it's mainly about adding good members when there are some and rejecting
the other with a proper explanation so that they can learn and improve
over time.
> So your proposal aims at solving the problem at the meta level, which
> might (or might not) help to solve the DSA problem ? Wouldn't it be
> better to solve the DSA problem first, learn from that, and then make
> sure that this doesn't happen again?
Honestly, what do you expect to learn from the DSA problem? There's not
much to be generalized IMO and you won't have many more information
disclosed than what you already know.
> I'm talking about fairness in the choice of new members: teams are
> likely to work better when people inside them aren't ennemies. Of
> course, the "service" should be provided in the same way to all
> developers.
For me, the minimum level of fairness in the choice of new members is
explaining why people are not taken. The reason itself doesn't need to
be motivated only on fair criterion, interpersonal relationships
definitely are part of the criterion...
> maybe not the best one, and maybe it won't even work. What leads you to
> think that your proposal will work better than another one?
As usual, I can't see how it can hurt and I prefer trying something to
doing nothing.
And we can discuss those guidelines and have a DSA-related GR at the same
time too. :-)
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: