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

Re: All DPL candidates: level of team management


On 11/03/14 at 20:49 +0000, Lars Wirzenius wrote:
> For all DPL candidates:
> We have a number of delegated teams. How detailed should the
> delegations be?

I think that delegations are a good tool to provide a clear status of
teams, in terms of active people, of powers that are delegated, and of
tasks they are responsible for.

During his terms, Stefano abused the delegation process by using them to
document (in collaboration with the team) how teams work internally (in
terms of processes) and how the project was supposed to interact with the
teams.  I think that this was a great way to abuse this process, as
growing the understanding of the teams' inner workings and expectations
helps a lot with smoothing interactions with the project.

But then, at the same time, delegations must not be explicit as to the
process that the delegates are expected to follow.[0] Unfortunately, this
prevents delegations that document processes, and, resulting in
delegations that might be a bit more vague, causes other problems, as
shown by the discussion following this update[1] of the policy editors

I think that the best solution here is a compromise solution: continue to
document the team's tasks, processes and interactions in the delegation
emails, but do this outside of the delegation stricto-sensu, making sure
that there's a clear separation between the part that describes which
powers are being delegated, and to whom [the binding/official part of the
delegation], and the part that describes the current implementation of
processes by the team [the documentation/unofficial part of the delegation
email, that should also be available on the team's wiki page].

[0] https://lists.debian.org/debian-project/2014/01/msg00054.html
[1] https://lists.debian.org/debian-devel-announce/2014/02/msg00003.html

> What is the appropriate level of oversight,
> management, and control that the DPL and the project in general should
> have for deciding what the teams work on, and how they do their job?

Debian is a volunteer-based project. Developers are free to decide what
they should work on, or what they should not work on. Outside of strict
constitutionally-defined processes, the project and the DPL cannot force
anybody to do work. (And I think that, good or bad, this is a feature of
Debian, that we are not changing anytime soon)

Also, Debian is inherently bottom-up. When something is blocking,
Developers usually try to work around it. That works, of course. But I
think that, in the event of blocking issues, the DPL has the
responsibility to seek solutions that work for everybody, by working with
the affected teams to understand to root blockers, find out how to help
them, etc. That's much harder than working around problems, but that's
also the best way to make Debian move forward as a project.


Attachment: signature.asc
Description: Digital signature

Reply to: