On Thu, Mar 04, 2004 at 09:03:17AM +0100, Marc Haber wrote: > Hi, > > Andreas has asked a lot of the questions that I intended to ask as > well, so I only need to amend one question he asked. Sorry for the delay in replying. Your amended question was a doozy! :) > 2a. Do you see the concentration of many important roles on a few > people as a problem? As example, I'd like to name DAM, keyring > maintenance, release management, ftpmaster, listmaster and buildd > coordination. While some of these roles are indeed officially > shared among a team, practice shows that usually there is only one > member of the teams acting publicly, with the others more or less > acting as backup. Potentially, yes, I see it as a problem, but as has been pointed out, most of these roles appear to have delegates and/or backup personnel in place, even keyring maintainer. It could hurt to update what most people would probably think is our official documentation[1] to reflect this. > Additionally, these teams don't seem to communicate well > internally. I don't think that's true for all of them. I think it might be helpful if all mail to and from these role addresses (see [1]) were routed through a privately-archived list (much as debian-private is archived). We might then be able to more seriously assess whether this is true for a given team, and if so how bad the problem is. Do you agree, or does archiving pose a danger I do not anticipate? > Do you see a problem when a request posed to a team is rejected > along the lines of "try again with another member"? Yes and no. I don't have a problem with a request being bounced if it's flat-out inappropriate for that team. But I don't think that's quite the scenario you're talking about. If a team member feels the need to recuse himself from handling an apropos request, for whatever reason, he or she should probably communicate that fact to the rest of the team him- or herself. If the request came to a role address as it should, then that team member need do nothing more, as the entire team should be aware of the request. In this case, a system like RT would be a better fit than a mailing list, because every ticket is "owned" by someone. If the ticket is owned by "Nobody" or just a generic role address, then it's easy for observers to tell that no team member has accepted responsibility for it. It might be to tell when something's fallen on the floor that way than with a mailing list -- on the other, it's not *that* hard to send a one-line mail that says "I'm on this." Hopefully one strategy or the other is palatable to most teams. > The situation might be influenced as well by the fact that there > are people on multiple important roles in Debian, and these people are > notoriously overworked. Wouldn't it be better to allow only one or two > important roles per person? If there's not a problem getting delegates or fallbacks appointed, no -- unless you can point out some sort of inherent potential conflict of interest between any two positions. > What would you define an "important role"? That's a followup to your previous question, and I'd rather identify pairs of "conflicting" roles than by awarding the term "important" to some roles. After all, that implies the other roles aren't. > Will you try to improve this situation during your term of office? > What do you intend to do? I'm going to have to point you to my reply to Martin Schulze[2], though the answer is a little broad. If you perceive a strong conflict-of-interest between any of the roles listed on our organization page[1], I urge you to waste no time bringing it to the attention of the -project list. Note that the Constituion already forbids the same person from holding some offices, such as Project Secretary and Project Leader. General Rule 2.1.2 is: A person may hold several posts, except that the Project Leader, Project Secretary and the Chairman of the Technical Committee must be distinct, and that the Leader cannot appoint themselves as their own Delegate.[3] > How will you answer if somebody asks you about your opinion on > "Debian being actually run by a cabal of at most six people"? I'd say, "Actually, it's run by a cabal of 908!"[4] :) I think the term "cabal" is too loaded for serious use, and is best reserved or wry or humorous discussion. And in my experience, that's pretty much how it's used. > What would be your answer if somebody would suggest amending the > constitution to move some of the "important roles" from being > delegates of the DPL to being elected by the body of the > developers? I'd say, "Propose an RFC to debian-project, and see if you can come up with a proposal that's worth floating as a General Resolution on debian-vote". I don't think your suggestion has been really seriously discussed before, at least not since the Constituion was first drafted, and I wouldn't want to pre-judge or bias the discussion by speaking ex cathedra as the DPL, or even as a candidate. > I am asking these questions because I am deeply disappointed with the > way technical, procedural and communicative problems are handled by > the project, and the DPL vote is the only way a mere mortal developer > can influence the distribution of important roles in the Debian > project. Thus, we need your answers to be able to choose the DPL who > will try to solve the problems outlined above, and I surely hope that > the three of you will answer differently ;) . I hope my answer has not disappointed, and that you have found the answers you seek from all three of us. [1] http://www.debian.org/intro/organization [2] http://lists.debian.org/debian-vote/2004/debian-vote-200403/msg00157.html [3] http://www.debian.org/devel/constitution [4] http://www.debian.org/vote/2004/vote_001.quorum.log -- G. Branden Robinson | The National Security Agency is Debian GNU/Linux | working on the Fourth Amendment branden@debian.org | thing. http://people.debian.org/~branden/ | -- Phil Lago, Deputy XD, CIA
Attachment:
signature.asc
Description: Digital signature