On Wed, Feb 26, 2003 at 03:02:29PM +0100, Marcelo E. Magallon wrote: > Hi, > > > > 4. The DAM is : > > > > > > [x] a critical part of our infrastructure > > > [ ] guilty of not rejecting people when they deserve to be > > > > That's possible, but I'm not sure it should really be the DAMs job to > > exercise a veto on an NM candidate that has otherwise passed the > > process. > > Can you elaborate on what you mean by "exercising a veto"? That means refusing the applicant's account creation despite the applicant being approved at all other stages of the NM process. > Does that have any concrete implications or specific actions > associated with it? Sure; it means not creating the account, telling the applicant that he's been rejected by the DAM, and why. > In your opinion, is it ok for an application to take a year before it's > fully processed, meaning, the applicant is either rejected or he gets > his account? Where do you draw the line? Half a year is not ok but > three months is? What do you think is or could be the role of the DPL > in this? My first strategy as DPL would be to find out from the DAM what *he* thinks a reasonable time frame is, and to do what he can to help the DAM to meet the standard he sets for himself. This is a volunteer project -- I'm not going to make much headway as a DPL if I stomp up to the DAM and say "I want all applicants who reach the DAM stage to have their accounts created within 24 hours; got it?" That approach may have an emotional appeal to people who are frustrated with the status quo, but I honestly don't think it will really solve the problem. Likewise, making my first official act as DPL the removal of the DAM is likely to make things worse, not better. My goal is to try to find solutions for our problems, not satisfy angry people's thirst for revenge. That means I have to be constructive, I have to be willing to listen, and I have to be able to stand behind the decisions of the delegates when they're made in a sound way. It may be that the DAM tells me "sorry, but with everything else I have to do I can't promise to have NMs accounts created in less than three months after they get to me". If no one else can share the workload of the DAM, then my inclination is to say "all right then, that's what I'll be telling everyone -- we'll document this prominently, and try to ensure that NM applicant's expectations reflect it". I think what drives a lot of NM applicants up the wall is the long period of not knowing what the heck's going on, and not knowing how much longer they'll have to wait to find out. (I'm hardly the first person to make this observation.) If we can give them some concrete expectations along those lines, and live up to them, I think they'll be a lot more satisfied -- even if not as happy as if there were a 24-hour turnaround. The latter may simply not be feasible, at least not without restructuring the NM process. > During the last week or so, a bunch of people have gotten their > accounts created, after some months of stall. This is not the first > time the process has stalled. In your opinion, is there a way to > prevent this from happening in the future? Yes, see above. I'd like to help delegates in general with their processes of interfacing with the rest of the Project; this means working with them to establish the nature of their role, the scope of their responsibilities, and what can reasonably be expected from them. Next, the DPL and delegate must communicate this information to the public. Then, the DPL and delegate must arrange some kind of mechanism for people to find out on a regular basis what that delegate has been doing. I am not wedded to a particular mechanism; what I care about are results. So, some delegates might want to keep a blog on the Debian website, where they post free-form updates on a frequent basis. Other delegates might prefer a highly-structured message that they can fill out in email once per month. There are all kinds of possibilities. While it might be nice in theory to have a highly standardized interface to such information, I'm not sure it's possible to pour all the delegates into the same mould. Again, they're volunteers. The DPL's role is to accommodate the needs of the membership *and* of the delegates. Ultimately, I think as long as people have a way to find out what's going on with a delegate, we can place a hyperlink on a "Delegates" page, and as long as there is reasonably up-to-date information on the other end of that hyperlink, the primary goal will be satisfied. > What do you think about the fact that for all visible purposes there's > a single person acting as Developer Account Manager? Is that a model > that you agree with? I am uncomfortable with single points of failure on principle. I would like to better understand why we appear to have only one, and what problems there would be with making the DAM team effectively larger, even if only with a a "backup" person who can take over in the event the primary DAM gets hit by a bus. These are questions I will be asking of the DAM team if and when I take office. Ultimately, the DAM team needs to be large enough that it can accommodate a reasonable balance between the expectations of the NM applicants (and Developers) and the workload placed on the DAM team members. It may be that that balance can be achieved with only one "active" member; I'd still be interested in having a backup member in that event, though. > My impression is that the question went along the lines of "should > ftpmaster have the power to veto packages based on criteria other than > DFSG-complainness" Yes. A 100GB package would place some strain on the mirror network, for example. You listed some others. > You can of course take the example to the extreme and ask if the > ftpmasters should veto rm-rf (Description: upon installation this > package with call 'rm -rf /' as root) from entering to the archive. > I think the answer is obvious in that case (yes). The question > applies to more realistic cases: what happens if someone decides to > upload glibc-cvs... oh, bad example ;-) but I think you get the idea. The decisions of the archive admin team need to be subject to review. That's different from taking away their discretion. > I think the general point is that the organization page lists a lot of > people in specific teams, but it doesn't say what these teams can > actually do or can't do. Take for example the Security Team. Where > does it say that the Security Team can make NMU without contacting the > maintainer beforehand? The question is _not_ if you agree or don't > agree with that policy. I'm also _not_ saying that there should be a > listing of these teams' "powers", a list that can be thrown at them > when they don't stick to it. The question is what do you think about > that. If you wish, the question is how much bureaucratization do _you_ > think is too much bureaucratization. I think a definition of each job is needed. How specific the list of enumerated powers needs to be depends, I think, on 1) how narrowly the delegates are willing to construe their own powers; and 2) how must dissent those delegates stir up with the exercise of their powers. In other words, a fairly loose description may serve for positions where the "power level" is low, or the delegates are very good at not angering people or usurping other people's prerogatives. Where the power level is high, it may be necessary to define the delegate's position more rigidly. I'm not opposed to an iterative process -- the description of a delegate's task may need to be revised over time. I think that's better than trying to anticipate every possible problem, and taking a highly legislative approach to the problem. If nothing else, that's time-consuming. So, basically, I think we should have only as much "bureaucratization" as we need for people to understand what it is the delegates are empowered to do. Right now, that amount would appear to be too little, given the widespread *lack* of knowledge about delegates, and the ambiguous status of people with delegate-type jobs who've never actually been delegated those jobs by any DPL under the Constitution. -- G. Branden Robinson | Psychology is really biology. Debian GNU/Linux | Biology is really chemistry. branden@debian.org | Chemistry is really physics. http://people.debian.org/~branden/ | Physics is really math.
Attachment:
pgpps_je9_gcn.pgp
Description: PGP signature