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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
