On 16/10/07 at 09:28 +0200, Josip Rodin wrote: > On Tue, Oct 16, 2007 at 06:31:30AM +0200, Lucas Nussbaum wrote: > > > * Infrastructure teams are groups of developers who deal with project > > > infrastructure and have access to resources in ways other than > > > the standard practice of uploading Debian packages. > > > > Which teams do you currently have in mind? That applies to DSA, > > obviously, ftp-master, but also well-functionning teams such as the > > release team? > > But it could also apply to every team that has a unix group, even if > > it's used to maintain a very small part of Debian infrastructure. > > 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). > > > [...] > > > * Intervention by Debian Project Leaders is not a practical solution > > > to resolve issues with infrastructure teams. > > > > Before acknowledging that, it would be great to know the status of the > > discussions between the DPL and DSA members. > > Frankly, no. This is a specific instance of a problem (that may require a > specific solution, too), but that is orthogonal to the general problem we > have, and that is that there are no written guidelines or rules about the > topic, so when things get broken, and fixing them requires non-trivial > action, we get stuck in a limbo. 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? > > > * It is necessary to define a modicum of procedure for how developers > > > can join the infrastructure teams in order to improve them while > > > maintaining fairness towards all. > > > > I'm not sure that fairness towards all is even a good goal here: the old > > team members will have to work with the new team members. We are not > > electing a commitee, where it is good if people disagree because of > > diversity of opinions. I'm OK with some teams being cabal-ish if they > > work properly. > > I am absolutely not OK with that! A promise of fairness of teams towards > the general developer body and vice versa is absolutely essential for each > others to even begin to have respect for each other. > > I'm thinking we may not be thinking of the same definition of the word > 'fairness'... 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. > > > Debian developers resolve the following: > > > > > > [...] > > > > I'm wondering whether we really need all that bureaucracy. Wouldn't it > > be possible to resolve something like: > > > > Debian developers resolve that some teams (pick up at least one > > amongst DSA, ftpmaster, DAM) are not functionning properly, and > > empower the DPL to take all necessary actions to restore normal > > behaviour. > > What will that ad hoc intervention accomplish in the long run? > Does the history of teams persistently losing activity/members > teach us nothing? We know we have a problem with teams losing activity/members. But we don't know what will be the good solutions to that problem, or how to avoid that proactively. Your proposal is just one possible solution: 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? -- | Lucas Nussbaum | [EMAIL PROTECTED] http://www.lucas-nussbaum.net/ | | jabber: [EMAIL PROTECTED] GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
