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

Re: DPL practicing

On Mon, Mar 12, 2012 at 06:42:29PM +0100, Lucas Nussbaum wrote:
> Could you give some examples of DPL tasks of the last 24 months that you
> could have transferred to someone else?
> Looking through your log, I have the impression that most of the tasks
> are either very short tasks, or tasks that would require the DPL's own
> attention very frequently (unless you will authorize people to talk as
> if they were the DPL).

That is correct. But those are not contraindications for the DPL to work
with others on DPL tasks (not I'm in principle against at authorizing
people to talk on behalf of the DPL --- I've authorized people to attend
events "on behalf of Debian" and represent the Project there, which
boils down to the same principle).

Generally speaking, I work well in teams and I don't have a tendency to
concentrate tasks and responsibilities on myself. My ideal way of
working is splitting tasks among peers and frequently get back to each
other for feedback, even when one of the peers has the final
responsibility and or saying on all matters. That is something I've been
unable to do as DPL, partly due to the non-success of my call for
helpers (see below for an answer to this), and partly because we're
among peers so the DPL really don't have any power to "make" someone
work on something (which is a very good principle). As a net result, I
ended up working alone on a lot of tasks, and I've thus far preferred
that over letting things linger. But I'd now like to try a different way
to make this work, hopefully establishing a structure that might
continue in the long run.

Regarding specific examples, there are aplenty, but let me present them
as categories, because that better gives the idea that there will always
be tasks to share:

- a lot of topics require a substantial amount of research /
  documentation / learning / planning work before even thinking of
  making a decision or propose something to the project: searching the
  info, summarizing them, talking with experts (e.g. lawyers) can all be
  delegated on a case by case basis

- mediation: the DPL often ends up doing mediation, there is no reason
  in the world while it should always be the DPL doing so. Luckily, I've
  had in the past people who helped me out with this, but doing so on a
  regular basis would be a perfect "exercise" about day-to-day DPL

- summarizing discussions and publicly show whether we are close or not
  to reach a decision by consensus. Once more, something everybody could
  do, but which I've ended up doing frequently as DPL

- "pinging": the "DPL ping list" is always full :-) ... of people you
  should contact to check the status of something. And often is not a
  sterile ping, is offering help and even getting your hands dirty with
  the actual work that needs to be done, because doing it a little bit
  my kick-start what has been blocked for long time. Even only keeping
  track of this takes a lot of time and mental energy

- all organization work related to money and sprints: of course I
  wouldn't have delegated to others to say yes/no on money expenditures,
  but there is no reason why one couldn't establish some house rules
  (e.g. all sprints requests below $X are fine) and let someone else
  take care of that. Some goes for documenting sprints, encouraging
  people to communicate about that, etc. I've trying to move part of
  that to the -sprints list, with only moderate success

I stop here, but I could go on with classes of tasks since quite a while
and all have countless instances, in the past and in the future. Of
course reality is much more complex and finding someone with whom you
can work well is not easy at all. But I think trying would be way better
than having to restart from scratch at each DPL change.

> What are the main skills required for a DPL? How will your practicing
> practice them?

I don't think it's a matter of skills and that's not the reason for me
to propose DPL practicing. I think there are thousands of different ways
of being DPL; I don't have the presumption of knowing the best one, let
alone "teaching" it to someone. I just want to offer a chance to anyone
who is interested into the "DPL job" to understand a bit more what it is
about before jumping into it. I had close to no idea when I started.

Of course there are also others way to achieve the same result (as
Gergely as mentioned): I can stay around after the end of my term, and
I've also been thinking at documenting how I've been doing some things
for anyone who wants to pick something up.  But I can't help thinking
that actually _doing_ the job would be way more useful, for the involved
people and for the Project.

> Why do you think that previous attempts of DPL practicing failed?

So, let me give some more details on this. I have actually received
responses to my call for DPL helpers over the year, in the number of 3.
In each case I got back to the applicants with a list of ongoing
sub-tasks which I was happy to hand over. But in the end, and for
different reasons, nothing happened. Maybe it's my fault: I've clearly
scared them away :-) But those tasks were useful for the projects and
have progressed, although most likely more slowly than if I could have
shared them with others.

My impression is that a lot of people who stand up for DPL mostly do
that for the prestige and for the hope of changing the project for the
better. But in addition to do that there are a lot of essential services
offered to the Project and the more we are aware of them, the better.
(This is why the second part of my DPL practicing proposal is about
periodic public meetings.)

Another reason for the failure of past attempts might be that when
people feel someone else is taking care of $things, they are not
particularly motivated to step in. If this is the case, I should be
happy, because people might have felt I was (properly?) taking care of
$things. But that doesn't work well in the long run unfortunately, and
this is why I've made clear in my platform that --- if I get reelected
--- it will be my last term anyhow.

Stefano Zacchiroli     zack@{upsilon.cc,pps.jussieu.fr,debian.org} . o .
Maître de conférences   ......   http://upsilon.cc/zack   ......   . . o
Debian Project Leader    .......   @zack on identi.ca   .......    o o o
« the first rule of tautology club is the first rule of tautology club »

Attachment: signature.asc
Description: Digital signature

Reply to: