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

Re: Debian Project Leader Elections 2019: Call for nominations


Disclaimer: I was the DPL between 2013 and 2015. My recollection of that
time might not be entirely correct, and Debian might have changed quite
a bit since then. I must admit that I haven't followed Debian closely
enough to know some details!

(And I hope that other former DPLs will post their own views)

On 13/03/19 at 20:35 +0100, Iustin Pop wrote:
> From my reading of the DPL bits, and if I remember correctly, there are
> a few of what seems to be separate areas:
> - delegations
> - finances (approving BSPs, hardware, sponsoring people with visas,
>   etc.)
> - dealing with external organisations (although not sure exactly what,
>   but press/articles, discussions about copyrights sometimes, maybe
>   conferences?, etc.)
> - dealing with internal escalations/de-escalating issues

So, let's try to describe how I see the DPL's various roles and
responsibilities, and also how those could be transformed (in the
"Debian without a DPL" scenario, or in the "Debian with a DPL-team").

Responsibility #0: Keep Debian fun and functional
First, I think that the most important responsibility for the DPL is to
make sure that Debian remains fun and functional. That requires making
sure that the most important teams are functional (by actively
monitoring them, talking to people, etc.) and by making sure that all
important areas of responsibility are covered. The
"monitoring/detection" part of it is mostly an invisible task, but it
takes a lot of time (mostly reading stuff, talking to people, etc.) When
I was the DPL, I think I had some kind of "Debian health checklist", and
also custom munin plugins to monitor specific parts of the project (like
various queues).

The "monitoring/detection" part can easily be distributed. The most
basic way to contribute to that is to complain to the DPL about
something that looks broken, to ensure that the DPL is aware of it.

But then, there's the "fixing" part.

Technical problems (or problems that are quite technical) are usually
not the DPL problem, and are covered by the Technical Committee, which
has been functional for quite some time. So that's easy (for the DPL).

What remains are mostly "people issues". Again, the Anti-harassment team
covers some of them, but not all them (and, this is still a shared
responsibility between A-H and the DPL). DAM covers some other cases.
What's mainly left for the DPL alone is core teams that become
dysfunctional because of MIA members or bad atmosphere or ...
Those issues are very time-consuming and very difficult, and very
damaging for the project.

The DPL's toolset for those issues is: social/communication/negociation
skills, the authority associated to the position, and the nuclear weapon

Delegations are just the tip of the iceberg. And most of the time,
updating delegations is very easy: a functional team comes to the DPL
and says "A is not active anymore and would like to leave the team. And
we recruited B and C." You review the current delegation's description
of roles and responsibility (which was probably written very well by a
former DPL), maybe discuss some adjustments with the team, and you are

Making new delegations is a bit harder, but you have to to-be-delegated
team to work with you. The hard part is generally to understand what
should be the exact (delegated) powers of the team, to make it fit
properly within Debian. This is usually quite subtle, and where the
problems arise later on.

The "fixing" part is hard to distribute for the difficult cases, and
would require a DPL team that works very closely together. I doubt that
it would work with a board of individually elected people, for example.
What could work is a clear leader for the DPL team that would "delegate"
a case to another team member.

Also, without the DPL as a safeguard, I don't know what would happen.
Debian has been getting more and more "professional", and most teams
have been able to take care of themselves for a long time now (or maybe
the DPLs have gotten better at detecting problems earlier ;) ).
So it's likely that Debian would survive for quite some time. But the
fact of not having any last resort solution is a bit scary.

Responsibility #1: Garbage collection
The constitution says that the DPL may "Make any decision for whom noone
else has responsibility." (5.1.4). It means that the DPL ends up being
in charge of various tasks. They are often in relation with the "outside
world", because we are pretty good at identifying recurring issues
inside Debian, and creating teams to address them.

Something closely in relation is the "point of contact" role. We have
the press team (the publicity team nowadays) that deals with press
inquiries, but the DPL is usually the point of contact for the outside
world, especially for non-technical stuff.

For simple inquiries, we could imagine sharing the load by having a
frontdesk that receives requests that don't require secrecy. But in my
experience, the requests that take a lot of time are those that really
need to go to the DPL anyway.

For the various little projects that the DPL catches as the garbage
collector, we could also imagine a better way to distribute them. In
the worst case, better prioritization could also help: not everything
that arrives in the DPL mailbox needs to be addressed.

Responsibility #2: Handling finances
The DPL is in charge of Debian assets. In practice, it means approving
expenses and handling the relations with the Trusted Organizations.
This is generally fairly easy because:
- we don't have that many expenses
- people are usually very conservative about spending Debian money, so
  requests that need to be discussed in depth or even denied are rare
- we have (or at least used to have) a steady stream of donations that
  cover our needs
- our Trusted Organizations are quite functional
- the budget of the largest annual expense (DebConf) is supposed to
  get a review by the DebConf committee before DPL approval, and again,
  people tend to be reasonable

Things could be improved though. There's a Treasurer team according to
[1] but I don't know if it is active (I couldn't find a "bits" email on
d-d-a). Also, from the DPL POV, it would be very useful to have an annual
report on Debian finances. I don't know if this exists nowadays.

[1] https://www.debian.org/intro/organization

Responsibility #3: Providing a vision, talking/writing about Debian
In the distant past, we used to have DPL elections where visions about
the project were the subject of hot discussions (we even had DPL debates
on IRC!)[1]. It was the annual discussion where the state of the project
was discussed. This was fun and interesting. With the decrease in DPL
candidates, this has been lost and probably replaced somehow by mailing
list discussions or blog posts (or maybe disappeared entirely, which is
probably a very bad thing).

[1] For example, look at
https://lists.debian.org/debian-vote/2005/03/threads.html and notice
that it says "Page 1 of 2"!

I think that the project has grown to adulthood, and that we don't need
the DPL to tell us what to do. It's important to realize that, other
than having a larger floor to advertise your ideas and possibly recruit
people to help you, the DPL role doesn't bring any super-powers that
help with implementing them.
Also, given that many people in Debian are of the "talk is cheap, show
me the code" mindset, it's probably better, if you really have
super-cool ideas for Debian, that you don't run for DPL and instead work
on your ideas and advertise them when there's something to show and get
others to join you to maintain PPAs.

So, that part of the role is really easy to reduce. We just need to
decide that it's possible to give it up, and reduce our expectations
about the DPL.

In my experience, the "give talks" part is not that time-consuming,
because there aren't that many events that either are interesting enough
for Debian to spend money on getting the DPL to travel to them to give a
talk, or are willing to pay travel costs. Also for more local events,
I've always thought that it made more sense to have local DDs give
talks, because that provides more opportunity for create durable links.

Responsibility #4: "Debian Monthly News"
Over time, the DPL somehow has grown the responsibility of distributing
news that are sometimes very loosely related to the DPL role.  That's
probably a bad habit created by the pressure associated with the
position that encourages to write lengthy emails to d-d-a even where
there isn't that much visible stuff to report on, because lots of things
are happening behind the scenes. If we elect another DPL, I would
recommend that the next DPL limits those monthly reports strictly to DPL
stuff (and leave the rest to the publicity team). The frequency could
also be decreased a bit.

Fallacy: being the DPL takes a lot of time
I don't think that's true. Or at least, I don't think that it's worse
than being an active member of a core team. The main differences with
such a role are:
- it's a position where you are often alone, and lack feedback
- the stress level is (I think) much higher than in technical core
  teams. After the end of my terms, I remember thinking about how good
  it felt to be able to spend a week-end without reading  email, and
  to open my mailbox without the fear of finding a big flamewar or a
  super-difficult email.

So where should we go from here?
First, I think that we need someone in charge of the "garbage
collector" and "point of contact" roles, and in charge of activating a
last resort solution when core teams are severely dysfunctional (which
also means making the necessary efforts to solve the problems

But I think that we should deflate the expectations around the DPL and
re-focus the role on responsibilities #0, #1, #2 above. That's already a
lot of work. It could help to change the title to something that sounds
a bit more "management" (something like Debian Executive Director?)

Other than the name change, the constitution is still pretty sane. We
could drop:

> 5.1.2 Lend authority to other Developers.
> The Project Leader may make statements of support for points of view or
> for other members of the project, when asked or otherwise; these
> statements have force if and only if the Leader would be empowered to
> make the decision in question.

maybe also:

> 5.1.5 Propose draft General Resolutions and amendments.

and probably:

> 5.1.9 Lead discussions amongst Developers.
> 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. The Project Leader should not use the
> Leadership position to promote their own personal views.

I'm really not sure about all ideas that involve teams/committees.

What could work is a group of people that are elected together, agree
beforehand on how to share the various areas of responsibility, and
synchronize very frequently to align their views. But it's probably hard
to be efficient in the typical Debian setup, and to determine a split of
responsibilities that would work.

If people want to experiment in that direction, a group of people should
probably come forward, choose one of them as the DPL candidate, and
experiment after they get elected. It will always be time to write
things in stone^Hthe constitution when we have an organization that seem
to work and could be generalized.


Attachment: signature.asc
Description: PGP signature

Reply to: