Hi, 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). 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 done. 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 beforehand). 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. Lucas
Attachment:
signature.asc
Description: PGP signature