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

Re: Q to all candidates: about advancing Debian (as organisation) while not being DPL



[no need to CC me; I'm subscribed to -vote]

Dear Jonathan et al.,

> > - the elected person gets so squeezed that after their service they just
> > prefer to focus in other tasks,
> 
> I agree that an overloaded DPL role can be harmful to both Debian and
> the individual in the role. I think it's important for a DPL to take a
> step back every now and again and look at the various properties of the
> role and ask "Is this working?". If elected, I do plan on filing bugs
> against the DPL role if I feel that something can do with improvement.

I'd be very interested if you and the other candidates could elaborate
on their thoughts in this approximate area.

As a bit of background, I've actually written this reply twice before
(or, admittedly ones somewhat similar) but it was difficult for it to
come across as not appearing churlish or otherwise grumbling about my
experiences. However, I hope with this paragraph, readers will read
it in its intended context regardless. :)

So, in general, I fear that the candidates may be over-estimating how
much of the DPL's tasks can be delegated to teams or other individuals.

A lot of teams have entirely-legitimate questions before acting (for
example, checking over some document) and often check-in with the DPL,
asking for advice, guidance or whether the Leader's experience or
contacts mean they have been exposed to a novel angle or approach to
what they are trying to achieve. This is, of course, eminently sensible
and healthy IMHO.

More importantly however the majority of tasks that land on a DPLs
plate may technically and «prima facie» be delegatable but the total
time and energy required to forward it, ensure it is correctly
followed-up on, context switch, ping later, forward any replies, etc.
etc. etc. regretfully exceed said time/energy of just "getting it
done" yourself to begin with.

I suppose part of the solution here might be to ensure and promote an
atmosphere where teams feel more empowered to push ahead without
quasi-approval (as well as ensuring some requests reach the "right"
place in the first place) but these are really far harder, long-term
goals that would require supreme dedication to even start to move the
needle on. I'm afraid I would be somewhat skeptical of any candidate
who thought they possess any sort of magic bullet to any of this
before being truly exposed to it outside of the abstract concepts I've
outlined above. :)

Indeed, some of these issues are not /really/ solvable in the sense
that I'm not sure I, as a member of the Debian community, would want
to be without the option of being able to ask the Project Leader for
their connections, experience or plain-old sanity checking before
doing something especially if that action might affect the reputation
or image of the Project.

So, reading this back I am not entirely sure what I'm asking here but
I would be interested if our candidates had any thoughts about this.


Best wishes,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org 🍥 chris-lamb.co.uk
       `-


Reply to: