Debian Voting Information / 2010 / Platforms for Project Leader Candidates / Platform for Stefano Zacchiroli

Executive summary

Hi, I'm Stefano Zacchiroli--mostly known as Zack--and I'm running for DPL.

The remainder 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 Appendix A. If you have read my 2009 platform, you might want to have a look at the changelog (Appendix B).

1  Introduction

1.1  Who am I

I became a Debian Developer (DD) in March 2001, shortly after the NM process was introduced. My Debian involvement has been through two distinct phases. Initially 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. My most noteworthy activities during all these years have been:

PTS

I've been co-maintaining the Package Tracking System (PTS) for the past 4-5 years, contributing day to day maintenance as well as more significant changes; details are available on my blog. (My initial interest in the PTS came from the desire to make the Vcs-* fields popular, which has eventually led me to write debcheckout.)

QA

more generally, I'm a long time member of the Quality Assurance team: I enjoy thinking of the project as a whole and looking for new solutions (e.g. UDD, DD expiry/WAT, etc.) to persisting problems.

OCaml

Proper support for the OCaml language was my motivation to join the project. I've contributed forming the Debian OCaml Task Force where I've ranged from the newbie, to leading activities. The team currently takes care of about 150 source packages with insanely intricate inter-dependencies, and complex transition needs.

RCBW

Since September 2009, I've been contributing to fix one RC bug per day by starting the Release Critical Bugs of the Week initiative; see the RCBW page for motivations and details.

AM

I've joined the New Maintainer Committee in 2009, becoming an Application Manager. I've been processing 4 new maintainers, 2 of which have become Debian Developers in the meantime.

Packaging

I also maintain some packages. Beside OCaml-related packages, I'm proud of various contributions to devscripts, vim, python-debian, and turbogears2.

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 BSPs and Extremadura sessions.

In real life, I'm a computer science researcher, currently working as a post-doc in the PPS laboratory, University Paris Diderot. The laboratory is somewhat of a Debian Developer nest, where coffee breaks frequently turn into exciting Debian discussions. I mainly work on the Mancoosi project, where we apply formal methods to the study of FOSS distributions; the project regularly contributes back tools to the community such as edos-debcheck, edos.debian.net, and other QA services used daily by Debian and other distros.

1.2  Why I am running for DPL

Being the DPL is about two distinct aspects: the institutional role and some 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 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 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.

2  My goals

DPL institutional tasks deal with decision-making in situations that are, in general, unknown a priori. Hence, I present my goals as follows.

1. First I give my vision encompassing key themes of Debian "politics". This, I believe, is the only way to give an idea of how I can react to unforeseeable scenarios.
2. Then I present the approach I intend to apply in carrying on DPL institutional tasks.
3. Finally I list some specific projects I intend to pursue if elected DPL.

2.1  Vision

Non-DD contributors

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.

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 "best operating system" is mainly, not only, made of software; it is also made of translations, graphics, musics, etc.

Collaborative maintenance

The introduction of the Uploaders: field has been another 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 is useful to take some weight off the shoulders of the NM process. Similarly, we should not accept one-man-band maintenance when it comes with de facto unmaintained packages (to be identified with suitable QA metrics, e.g. cross-checking MIA, WAT, bapase, etc.). 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.

Vocal minorities

Our mailing lists have substantially improved over the last 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 (VAC messages due to this are way too frequent). 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 others 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.

Face-to-face meetings

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 one of the best way to use Debian money and other resources, such as specifically appointed management people. Luckily we do have DebConf, organized by a very efficient team. Nevertheless DebConf 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 financially 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.

Derivatives

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 patch tracker 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:

1. be exemplar in our giving back practices, for example by tracking publicly our efforts in sending patches upstream;
2. make as easy as possible to give back to us, for example by participating in cross-distribution initiatives and by NMU-ing packages when important downstream patches lay unattended in the BTS.

Doing both will strengthen our give back requests to derivatives that we should not stop posing.

In particular, we should not ignore the fact that Ubuntu is the most popular among our derivatives and seems to have a larger community than ours. (i) Technically, we should exploit that to benefit our users, by integrating good changes and ditching the rest. To that end I will welcome technical mechanisms that enable DDs to better interact with the Ubuntu community (bug, patches, ...) about their packages. (ii) Politically, we have the asset that Ubuntu releases contain about 70% of unmodified Debian packages.¹ That asset should be used to communicate more incisively our desire that Ubuntu behaves as a proper FOSS downstream: giving credit and contributing back. (iii) Finally we should communicate why we are better (see Section 2.3.1) and don't forget that we are better.

2.2  Interaction with the project

2.2.1  Being present

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.

The second expression of presence that should be expected from the DPL is the management of the project agenda, as well as the communication of our vision. Managing the agenda means having a road map of topics the project should consider within some time frame. The DiscussionsAfterLenny page--and how we did(n't) use it--is an example of such need. The DPL should ensure the project has similar agendas to avoid forgetting about important topics to later remember them, say, just before a release.

Management also means keeping track of what happened. The DEP proposal, which I've contributed to start, is an attempt to achieve that: no excessive extra burden induced, but a work-flow to remember what is the status of "large" project-changing proposals. The DPL should take care of "orphaned" DEPs by reassigning, closing or driving them in first person. I will ensure that we give a try to 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.

2.2.2  Transparency

Another way for a DPL to be present is to disclose periodically what she or he is doing; let's call it "transparency". In that respect, the standard of a few "bits from the DPL" mails a term is unacceptable for a role which is meant to represent such a big and diverse project. If faced with the dilemma, I will favor ditching some DPL tasks and communicating about the others, over the other way around.

It is likely 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 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.

Money

I believe we need transparency improvements also on money management: both DDs and contributors should be able to check how money flows in/out our bank accounts. I will investigate with the respective treasurers the possibility of having such a public report. We do have quite some money (more than 60K$ only in SPI account), having a clear view of how they are used might encourage the whole project to use them in more proficuous manners (e.g. dedicated machines or other resources for specific packaging needs).

2.2.3  No DPL board

According to past DPLs, carrying over the DPL burden all alone can be daunting. To counter that, I will be constantly seeking advice from others, on the basis of their project expertise. I do not believe in the utility of a DPL board, so I will not have one; nor I will have a second in charge (2IC). All in all, I haven't found evidence that either device can affect significantly the outcome of a DPL term.

For more specific task assignments we have delegates, which is more than enough. In particular, I would like to investigate the usage of time-based delegations to carry on specific tasks which are considered crucial to proceed along the project agenda. Time-based delegation--implemented as normal delegations with a statement that they will be undone, e.g. at DPL term end-- avoid concentration of powers and will give delegates a time frame in which focus their efforts. I will welcome DDs to propose themselves for term delegations on specific tasks they care about (as long as the actual "delegation hat" is really needed).

2.3  Specific plans

2.3.1  The website

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.

As time passes, the drawbacks of the website status quo are becoming more and more relevant. In particular we now need to clearly explain to our (potential) community why we are better than other Debian-based distributions. We need to explain that we are free from the bottom up (including all pieces of our infrastructure) and that we are a truly democratic project where decisions are taken by volunteers and not by money. In other words, we need to promote our vision to the FOSS world and the website should be the primary medium to convey it.

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.

1. Establish the minimal requirements for an improved website in terms of: message, structure, accessibility, work-flow. Make those requirements public as well as a detailed plan of the work that needs to be done to implement them: we will not hide problems.
2. Send out a call for help to our community, looking for people willing to take over the job and complete it in a given time frame. (Yes, I know we are all volunteers, but we do take responsibilities and aim for deadlines, this issue is relevant enough to ask for it.)²
3. Make sure the takers have access to the needed resources and that they get credit for their attempt and, hopefully, success.

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.

2.3.2  Clarify delegates

Remember: TINC (there is no cabal). Good. Then:

1. all current delegates should be clearly stated at our organization page with reference to the delegation mail;
2. all people in core teams which predate widespread use of delegation should be officially delegated. This will avoid disparities between "young" team members who are delegates and "old" team members who live in an unclear limbo.

2.3.3  Core teams

Our core teams have recently improved a lot, in terms of manpower and communication. Kudos for that go to 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 inactive, or are very bad in communicating what they are doing. For their own good, involved people should be encouraged to either move to work on subjects which are more fun for them, or to communicate periodically what they are doing.

All these changes however should be attempted first with team agreement, to not bother potentially understaffed yet very efficient teams. The 2-year old initiative of team reviews by Steve McIntyre has been in the right direction, though it will obviously need revamping, as time passes for everybody.

Additional info

Time commitment

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. Most of my current Debian duties happen within efficient teams, I'm confident the tasks will not remain unattended; the rest consists in 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. Still, I have a very FOSS-sensitive boss: I have the freedom to reorganize and possibly shrink my schedule for emergencies and longer activities, such as traveling for Debian-related reasons. Like most of us, I'm generally available on IRC, phone, etc.

A  Rebuttals

Wouter Verhelst

I agree with several points of Wouter's "vision" on Debian and, in particular, with the fact that we badly need to attract more developers to remain technical excellent.

What is not clear to me reading his platform is how to actually achieve that. For once, the idea of talking more with "Debian people" other than DDs/DMs is wonderful--assuming that by that Wouter imagines the DPL attending several events other than our "classical" developer-oriented events. That however is not enough, because the big public of our potential contributors is not (only) there. To that end, I found striking that our Web presence is not mentioned in the platform as an important strategic area to attract more developers.

Finally, I think that to achieve technical excellence attracting more developers is needed, but is not enough. In the current Debian ecosystem, with the success of some of our derivatives, technical excellence also passes through exploiting synergies among all our derivatives. In that respect, I miss in Wouter's platform his vision on topics like our relationships with derivatives distribution.

Charles Plessy

Essentially, I think I don't share Charles' premises on Debian growth crisis. Currently, I don't see Debian as having a problem of scale in the number of packages, contributors, etc. Quite the contrary: I've rather the impression that the available (relative) manpower is decreasing, and our quality is suffering as a consequence. To counter that, we need to grow more, especially in the number of Debian contributors.

I have mixed agreements and disagreements with other proposals advanced by Charles. For instance I like the idea of delegate pings, whereas I don't like the idea of flexible releases which--in Charles' keywords--seems to push the balance too far away from coordination. Furthermore, I like the idea of having the DPL managing "leftover" discussions (in fact, it is part of my platform where I state that the DPL should take care of the project agenda, see Section 2.2.1).

As a final minor point, I'm not particularly at ease with the idea of a DPL not being able to travel to attend meetings worldwide, as that is one of the most typical among DPL duties.

Margarita Manterola

Margarita's platform is inspiring about how we should all behave within the Debian community. Still, I'm not sure that just stating how we should all behave--or having the DPL behaving that way, as it has been pointed out on -vote--is enough to actually have a significant change. The "Debian appreciation day" is a nice idea too, but it doesn't look like it needs DPL support to become a reality.

I also like the idea of promoting Debian with web campaigns et al. but, as I've observed in response to Wouter's platform, I found striking to put emphasis on those aspects which I consider minor glitches in the overall context of our capacity to attract more people (which includes web presence, communication of our distinguishing values, etc.).

Thanks and good luck!

Thus far, campaigning this year has been truly fun and exciting for me. The merit goes not only to all contributors of intriguing questions on -vote, but also to the fact that we are several active candidates running. Thanks, candidates, and good luck for the election!

B  Changelog

My 2009 platform and this one are very much alike. For those who have read the latter, here is a brief summary of significant changes:

• Revamp the section on derivatives, detail relationships with Ubuntu (see Section 2.1).
• I will not be looking for a 2IC, rather I plan to use normal delegations, possibly constraining their duration (see Section 2.2.3).
• Realize the role of the website in communicating our vistion (see Section 2.3.1).
• Minor changes pretty much everywhere :-)

1

that includes the universe, but the universe is nevertheless an important selling point for them

2

even though it was way simpler, my experience with the PTS face lift shows that our community is responsive to our deficiencies in Web presence: i asked for a new PTS CSS layout, got several replies, and chose one of them. It required some back and forth round trips, but is nothing different from the usual patch work-flow.

This document was translated from L^AT_EX by H^EV^EA.

Back to the Debian Project homepage.