Hi,
On 13/02/15 at 11:08 +0800, Paul Wise wrote:
> On Fri, Feb 13, 2015 at 4:57 AM, Ana Guerrero Lopez wrote:
>
> > Lucas sent an email asking people to encourage their 'dream DPL' [1].
> > I have already encouraged a few people in the last weeks, but when discussing
> > with them, they all tell me very different things about the DPL role. When
> > I asked: "What are you expecting the DPL to do?", I got a bunch of different
> > replies:
>
> The DPL role is defined in the constitution.
>
> https://www.debian.org/devel/constitution#item-5
Please note that it's very well possible that the constitution is wrong,
or needs to be changed, as Debian changed a lot since that document was
originally written. For example:
The Project Leader should not use the Leadership position to promote
their own personal views.
This has been violated by several DPLs (me included), who pushed forward
things they cared about, or discussed them in interviews, without
necessarily first ensuring that it matched the project's consensus.
My own view on the original question ("What are you expected the DPL to
do?") is that the main thing the DPL must absolutely do is being a good
"garbage collector" (I think the original naming comes from Zack). There
are lots of areas of Debian that suddenly get broken, often in
unexpected ways, or where there's no-one clearly responsible. And
usually, the DPL ends up being the ultimate fallback for those things.
This is also what makes the role particularly hard: the DPL usually get
involved when it's (too) late to find easy solutions, or in areas
that are not covered by the typical expertise of a DD.
It's also the most crucial part of the role because often, there are
people blocked by the lack of progress, being deeply frustrated about
their Debian involvement due to that.
Of course, when there's a recurring flow of requests in the same area of
expertise that end up in the DPL's hands, it makes sense to create a
specific team to work on those issues. That's what was done recently
with the trademark team, and the auditors team (to improve interactions
with TOs, deal with reimbursement requests, etc.). But creating teams
out of nothing is also not particularly easy, especially in
non-technical areas.
Then, with this 'Garbage collector' / 'Facilitator' part is covered,
there are of course lots of other things the DPL can do using the
remaining time, but, IMHO, they mostly fall in the 'Could do' rather
than 'Must do' category. Also, as Paul pointed out, we have teams
covering most of the areas listed in Ana's email, and it is not healthy
when the DPL starts overstepping on those teams' work.
Commenting on some of the list from Ana's email:
> > - Set technical goals for the project
>
> That seems like the responsibility of Debian as a whole.
That's indeed something that is the responsibility of everybody, and of
no-one in particular. In the past, we had 'release goals'. But when I
worked on the release team delegation, it was really hard to include
something about release goals (see thread at http://deb.li/3D9kV).
Do we need an entity in Debian that decides on the technical agenda?
(That's probably a good question for DPL candidates :P)
> > - Be aware of everything that goes on with Debian. E.g. I have the feeling some
> > people expect the DPL to read all the Debian mailing lists.
>
> That is simply not feasible, even though the amount of discussion that
> goes on in Debian feels like it is going down over time.
Interestingly, that is part of the constitution, though:
The Project Leader should attempt to participate in discussions
amongst the Developers in a helpful way which seeks to bring the
discussion to bear on the key issues at hand.
My own take on this is that various other people have been doing that
very well (probably better than what I would have done), so I've
generally decided to focus on things where the DPL was the bottleneck,
rather than things that are already well covered by others.
> > - Debian representation: give talks on behalf of Debian in important conferences
> > or congresses. Also give interviews.
> > - Handle the relationship with the open source ecosystem
>
> I would add here:
> - Handle the relationship with the Free Software ecosystem
>
> There isn't anything in the constitution about interacting with
> external entities. As the "Leader", the DPL is probably better known
> outside Debian than most Debian members due to external press coverage
> etc so it makes sense that they would be contacted more often about
> being a speaker. I think that Debian as a whole should be responsible
> for interacting with external orgs, giving talks/interviews etc. We do
> have a number of folks who have volunteered to be speakers at least:
>
> https://www.debian.org/events/speakers
Regarding talks, my experience is that most event organizers are not
ready to cover travel costs. Which turns the question into: Given the
expected impact of the talk, is it worth spending Debian money to cover
the travel costs? In most cases I've seen, I think that it's better to
spend Debian money on other things, such as sprints.
Regarding relationships with other organizations, it's useful to have a
clear point of contact, but it's also fine if there are specific teams
taking care of various kind of organizations. For example, the
derivatives front desk is doing an awesome job with derivatives.
> > - Make sure delegations are updated and and teams keep functioning properly.
>
> The first part is in the constitution, the latter seems like the
> responsibility of the teams themselves and Debian as a whole.
In many cases, teams are functional and the truth is that adding or
removing members is just paperwork. The 'task description' part of the
delegation is more interesting, because it requires defining what a team
does, which powers it has, and where are its limits, in quite abstract
terms.
In a few ugly cases, unfortunately teams are not functional anymore, and
there's a lot of work needed to restore a working state. If that does
not happen, it means people being frustrated about Debian, etc.
> > This is, globally, people are expecting the DPL to do all of the above and maybe
> > more. I think it's clear this is NOT humanly possible. What are the alternatives?
> > Should we redefine the role of the DPL? Should we maybe split the role of the
> > DPL in a few elected roles? Should we discuss (again) the possibility of
> > replacing the DPL for a board? Sometimes I have felt like the DPL election was
> > a popularity contest, and that's probably not what it should be.
>
> I think the DPL role has expanded beyond what was it initially defined
> as, due to various factors. Probably we just need to re-focus on the
> initial definition and create new teams for the things that the DPL
> has expanded to in the past.
I think there are really two sides about this.
First, yes, it's good to spread the load by creating new teams for the
things that ended up being recurring tasks of the DPL. One specific area
where that could be done is everything legal-related: we could have a
delegated team taking care of interactions with our lawyers at SFLC, and
more generally working on the recurring flaw of legal questions brought
to the DPL. (It would have to be carefully defined, though, to avoid
overstepping on ftpmasters or the trademark team).
But it would also make sense to 'open' the remaining DPL tasks somehow.
First, to spread the load over several people, and avoid the situation
where DPLs usually end up quite tired, frustrated, and desperately
needing vacations from Debian at the end of their term(s). Second (and
more importantly) to enable more DDs to get familiar with the kind of
tasks the DPL does, so that they could maybe become DPL themselves at
some point without jumping in the unknown. In my platform last year, I
proposed to setup some kind of 'rolling board'. I haven't done that
because I felt Debian has had enough meta-discussions about the
organization of the project recently, but I still think that something
along those lines should be explored. Unfortunately, there are not that
many DDs who are interested in 'management' tasks. Many of us contribute
to Debian because it's a way to balance they management-heavy day job
with some more technical work.
I think that it's interesting to look at how Debian is organized
compared to other organizations in the ecosystem. Debian is very heavily
distributed, with autonomous teams taking care of their own areas of
expertise. That's also what enabled us so far to function with a
non-full-time DPL, and without a board. Being a bit extreme, one could
argue that each time the DPL _has to_ do something, it's a sign that we
fail to create a functional team that would take care of such issues.
Lucas
Attachment:
signature.asc
Description: Digital signature