DPL platformStefano Zacchiroli |
[ Other formats available: .html, .pdf, .txt. ]
Hi, I’m Stefano Zacchiroli—mostly known as Zack—and I’m running for DPL.
The reminder of the platform provides background information about me (Section 1), describes the above points in more detail (Section 2), and highlights more specific plans for my term (Section 2.3). Rebuttals can be found in Section A.
I became a Debian Developer (DD) in March 2001, shortly after the current NM process was introduced. My Debian involvement has been through two distinct phases. In the first one I only cared about my packages, ignoring the community: no IRC, no -devel subscription, etc. Then, at LinuxTag 2004, I discovered Debian as a community and got fascinated by it, gradually increasing my involvement in the project.
Technically, my main activities during all these years have been:
Believing in the community as the real strength of Debian, I’m a regular attendee of DebConf and, time permitting, of any other face to face meetings, like the Extremadura work ones.
In real life, I’m a computer science researcher, currently working as a post-doc in the PPS laboratory, University Paris Diderot. This laboratory is somewhat of a Debian contributors nest of the French Debian community; our coffee breaks frequently turn into exciting Debian discussions. I mainly work on the Mancoosi project, where we apply techniques such as formal methods to the study of FOSS distributions, including but not limited to Debian, and to the improvement of upgrade planning algorithms. Mancoosi is the successor of EDOS, which was the source of various tools used for Debian QA, like edos-debcheck, running periodically at edos.debian.net.
Being the DPL is about two distinct aspects: the institutional role and a set of extra goals the prospective DPL wants to pursue during the term. This distinction matters.
The institutional role is described in our constitution and is about three tasks: ordinary and extraordinary decision making, public relations with the outside world, and leading discussions inside the project.
My personal view of why we need a DPL builds on the observation that we operate as a do-ocracy: anyone willing to do things can decide what and how they are done, and no one can be forced to do anything. Given our size, we have the irresistible tendency of turning into an imperfect do-ocracy:
The DPL has the duty, for a limited amount of time, to mitigate the imperfections of our do-ocracy:
The reward is the occasion to push for project-wide improvements by the only virtue of occupying the DPL position.
I want to challenge myself to be a transparent and present DPL, and to improve the mechanisms of our project. That is why I’m running for DPL. (Actually, I’ve also been asked by some of you to run, so the blame for bothering you in reading all this does not fall exclusively on me :-)
DPL institutional tasks deal with decision-making in situations that are, in general, unknown a priori. Hence, I present my goals as follows.
The introduction of DMs (Debian Maintainers) has been a fortunate event for Debian. Some people argue that it has opened up our archive to packages of sub-standard quality. That might be true, but we also have (plenty of) sub-standard packages maintained by full-fledged maintainers who have lost their interest in Debian. The solution to both is more QA.
Through the DM process, many enthusiastic people have found their way into Debian, increasing our work force. In addition, the DM process induces a more controlled process to become a full-fledged DD, with greater insurance of serious commitment to Debian, and experience levels. All in all, the DM process is a more fine-grained access path to Debian than what we had before it, which enables us to give back to our contributors gradually through recognition. Contributing to Debian is no longer all-or-nothing, it is now way less frustrating for packagers, who previously might have turned their efforts to other projects.
We need to generalize the lessons learned from the DM process. We have a lot of potential valuable contributors out there. They just need better documentation about how to join. They simply demand something in exchange, to be proud of, that acknowledges their efforts. I do not have preconceptions on the different ways of achieving this (e.g., ACLs vs linearly increasing privileges), but we need to go in that direction. In doing so, we should also relax our implicit assumptions that only technical abilities matter in Debian. The truly “Universal Operating System” is mainly, not only, made of software; it is also made of translations, graphics, musics, etc.
The introduction of the Uploaders: field is another example of a fortunate development in Debian. While it can, in principle, form teams of people with no clear responsibility for specific tasks, on average it works very well. It creates efficient technical spaces for collaboration on specific topics, and it also scales through (re)creating organizational structures with specific position and task-assignments.
Collaborative maintenance should not be mandatory (we do have several very efficient one-man-band developers), but should be our default. Packaging newbies should start in collaborative maintenance teams and gain experience there. Team member feedback can then be useful to take some of the weight off the shoulders of the AMs (Application Managers). Similarly, we should not accept one-man-band maintenance when it comes with de facto unmaintained packages (to be identified with suitable QA activities). In those cases, we should suggest—or even force if needed—collaborative maintenance. It can provide a more acceptable exit strategy than public, yet useless, shaming.
Our mailing lists have substantially improved over the last 5 years. Every now and then though, they get polluted by (apparently) very vocal minorities capable of polarizing discussions, which is neither productive, nor fun. Given how we are attached to our community, we sometime take part in such discussions, inevitably burning out (how frequent are temporary VAC messages due to this? Too much). My take:
Freedom of speech: good.
Vocal minorities holding hostage the silent majorities: bad.
While we should consider—and have actually applied in the past—moderation measures to counter repeated community disrupting behaviors, we cannot take the risk of applying them only on the assumption that the posters actually are a vocal minority. Even though there are no optimal solutions for this kind of problems, technical devices can help. One such device I want to put into use are polls, as proposed by Jeroen van Wolffelaar and other years ago. The intention is to enable every DD to start mail-based, authenticated polls à la devotee.
Polls can give a reasonable idea where the community stands, without having to engage the whole GR (General Resolution) machinery. A poll can either make it clear to participants in discussions (or flame fests) that they are in disagreement with the rest of the project and better stop beating the dying horse, or indicate that they are on the right path.
Meetings are essential to improve the quality of collaboration within the project, no matter how good we are in communicating digitally. Get together face to face, hack for hours, do stuff together, and get back home. The day after, your remote collaboration will be better.
Helping the organization of meetings is a wonderful way of spending Debian money or other investing resources, such as specifically appointed people. Luckily we do have DebConf, which is organized by a very efficient specific team. Nevertheless it should not be the only get-together, and we should push more for local meetings, employing our resources for that. I see as perfectly reasonable supporting economically the trips of active contributors when that will make possible joining others to work on specific topics.
A simple metric for deciding when to do that and when not, beside the required amount of money, can be the number x of other developers asking for that. If and when money will become an issue, I do not see any showstopper in organizing specific sponsoring campaigns.
We are part of the FOSS ecosystem, in which patches flow both downstream and upstream. We have promised to give back to the free software community, yet sometimes we fail to do so. Initiatives like the recent patch tracker by Sean Finney are a way to ensure that all our changes are visible both to downstream and upstream.
Our derived distributions (AKA derivatives) have us as theirs upstream, and are in a similar situation. We cannot force them to give back to us, because our promises are not necessarily theirs, still we should:
Doing both will strengthen our give back requests to derivatives that we should not stop posing.
As a DD, I have often suffered from a perceived DPL “absence”. Maybe it was just me not being pro-active enough to ping the DPL on IRC or email and ask, but I consider it a DPL duty to communicate his or her presence. That comes in two forms: one is to lead discussions among developers, as prescribed in the constitution, something I have rarely seen. While we do not want that by default (no need for a “post-in-every-thread” DPL), I will try to be present in “hot” discussions (vague on purpose) which concern the organization and the big picture of the project. I will also encourage seeking the DPL opinion on specific topics, by pinging me explicitly.
The DPL opinion can also be a reasonable first attempt to solve a conflict; if it fails, we do have other mechanisms to settle it. In this respect, I believe my personal qualities can be useful for the project: I am thoughtful, listen to others, and open to be convinced by good arguments.
More generally, managing the project agenda is something that should be expected from the DPL. Managing the agenda means having a road map of topics the project should consider with in some time frame. The DiscussionsAfterLenny page is an example of such need. The DPL should ensure the project has similar agendas to avoid forgetting about important topics to remember them, say, just before a release.
Management also means keeping track of what happened. The DEP proposal—started by myself, Adeodato Simó, and Lars Wirzenius—was an attempt to deliver a device to achieve that: no excessive extra burden induced, but a workflow to remember what is the status of “large” project-changing proposals.
We should expect the DPL to take care of “orphaned” DEPs by reassigning or driving them in first person. DEPs have not taken off due to the lack of some technical bits and of representative examples. I will ensure that we give a try to DEPs, or similar devices, to check whether we can finally have a sane choice between hyper-formal decisions by the mean of GRs and folklore decisions which too often resemble no decisions at all.
Another way for a DPL to be present is to disclose periodically what she or he is doing; let’s call it “transparency”. Recently we have got better, but only 4 or 5 “bits from …” mails during a DPL term is still too little for a role which is meant to represent such a big and diverse project.
I’m sure that a given number of DPL activities are not suitable for disclosure, whether they are personal to some, plain boring, or otherwise should not be archived forever on the Web. I’m also aware that writing from scratch a “bits from DPL” mail can be time consuming and possibly intimidating.
The solution I will implement is to have some constant feed of DPL activity news. “Feed” as a concept, the implementation can vary: an IRC channel, blogging or micro-blogging, a wiki page BitsFromTheDPL handled à la DeveloperNews, posts to -private for sensitive material, etc. No feed activity will mean no DPL activity and the right for DDs to complain and demand explanation. I believe that activities which are not yet ready to be disclosed at all, not even by censoring or rewording details, are scarce enough not to imply empty feeds.
The resulting feed will then be frozen each month and posted to d-d-a. If I fail to post and freeze twice, I will admit my failure by explaining the reasons and seeking opinions on how to continue the term (e.g., using a poll, which can also contain an option “resign, you do not communicate enough”).
According to past DPLs, carrying over the DPL burden all alone is daunting. To counter that, I will be constantly seeking advice from others, on the basis of their project expertise. I do not however believe in the utility of a DPL board: the DPL term is too short to spend time with extra coordination hops, so I will not have a DPL board. For more specific task assignment we do have delegates, which is more than enough.
However, as life goes, the DPL is in this sense a single point of failure, and I will be looking for a 2IC (second in charge, vice-leader). The duties of the 2IC will be: DPL backup (in case of unexpected absences), and help in communicating outside and inside the project (e.g., for the news feed). The 2IC will be appointed with an ordinary, term-limited, delegation. As the DPL, I will take full responsibility for 2IC actions.
Remember: TINC (there is no cabal). Good news. Then:
We all want a sexier website, i.e., a website where people can find what they look for, and which does not make us look like Debian is an operating system of the 1980s. While work on the issue has been going on in the WWW team, we have not delivered visible improvements yet.
I intend to help the WWW team in order to solve the main issues within the term. While it will be pointless to set the precise technical goals in a platform, my intended course of actions will be as follows. All steps are meant to be performed in agreement with the WWW team.
If all this fails, we will have an emergency plan. For instance, we can consider an external bounty (i.e. nobody involved in Debian can take it) to realize what is missing, under the supervision of the WWW team. We regularly pay for services we are unable to produce by ourselves, the website should be no difference.
Our core teams have recently improved a lot, in terms of manpower and communication. Kudos for that go to Steve McIntyre and Sam Hocevar (the last two DPLs) and of course to the team themselves. Nevertheless some teams are still short, or so it seems from the outside. Adding members makes a team more tolerant to absences, and also helps to prepare the next generation of contributors. The distinction between assistants and regulars in several teams seems to work very well in that respect.
My naive intention would be to bring all core teams to at least three members and to push for campaigning for assistants when there are no well-established procedures for team joining. Also, by looking at our organization page it looks as if several teams are either not active anymore, or are very bad in communicating what they are doing. For their own good, involved people should be encouraged to replacement and something to work on that is more fun for them.
All these changes however should be attempted first with team agreement, to not bother potentially understaffed yet very efficient teams. I will start from the precious team reviews gathered by Steve McIntyre last year2 to drive re-staffing and procedural changes in order not to bother properly working teams.
Being DPL is challenging ; for it to succeed the job must be taken seriously. For the duration of the mandate I will therefore put on hold my other Debian tasks; it is an obligation towards habitual co-workers and a fair deal to avoid burning out. I’m not the only responsible person in most of my current Debian duties and I will leave behind efficient teams, so I’m confident the tasks will not remain unattended. The remaining parts are a handful of packages which will need new maintainers.
On the same topic and for the sake of clarity: some DPL candidates have in the past declared their ability to act as DPL full-time. I cannot grant that. What I offer is my Debian time, to be diverted to DPL tasks. Luckily though, I work at a university where I have a very FOSS-sensitive boss. I have the freedom to reorganize and possibly shrink my schedule both for emergencies, and for longer activities such as traveling to deliver Debian talks. Like most of us, I’m generally available on IRC, phone, etc.
Beside rebuttals, the DPL platform is fixed once and for all at the end of the nomination period. While that makes perfect sense in the context of a vote, it makes it hard for candidates to communicate their positions on important topics, because of the volume of information the vote process generates. Hence, if noteworthy topics will come up during the campaigning, I will summarize my positions about them at http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/.
I have known Steve and Luk for quite a while now and I deeply respect what they both did for Debian in all these years. I acknowledge all the problems they (yup, “they”, because they are de facto running in tandem) mention in their platform: communication, humbleness and asking for help, ... In fact most of them are general problems of all free software projects.
That notwithstanding, their platform lacks hints and strategies that explain how they are going to attack those problems: it is not enough to say, e.g.,
I want to see improvements made where they are clearly needed
to actually deploy the improvements. Also, I’m missing the vision of the two candidates on relevant topics such as Debian membership, mailing list discussion quality, derivatives, ...
All in all I found that the main contribution to the decision of voting for Steve and Luk is the example set by Steve in the current DPL term. The platform, which is what a rebuttal is meant to comment upon, does not have much more to offer.
I acknowledge that Steve did some great work during the current DPL term, but most of his practical tasks are approaching completion. It would have been great to know what, if elected, he plans to work on additionally. Presenting such a “diff” is, in my opinion, the duty of the DPL currently in charge, when standing for re-election.
This document was translated from LATEX by HEVEA.