[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Questions for all candidates

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

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

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

Reply to: