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

I'm Stefano Zacchiroli — mostly known as Zack. I'm serving as DPL for the 2010-2011 term and I'm seeking re-election for the next term. This platform provides background information about me (Section 1), describes my main goals as DPL (Section 2), and highlights more specific plans for my term (Section 2.3).

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:

DPL

I've been serving as DPL for the present term since April 2010. Reports of my DPL activities since then can be found in various bits from DPL incarnations as well as on my blog.

PTS

I've been co-maintaining the Package Tracking System (PTS) in 2006-2010, 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've been 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

From September 2009 to April 2010, 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 mentored 5 new maintainers, all of which have become Debian Developers.

Packaging

I've maintained several dozens packages during my Debian involvement. Beside OCaml-related packages, I'm proud of various contributions to devscripts, vim, and python-debian.

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 sprints.

In real life, I'm a computer science researcher, currently working as a post-doc in the PPS laboratory and IRILL research center. Both places are Debian Developer nests, 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 component-based systems such as FOSS distributions; the project regularly contributes back tools to the community such as edos-distcheck, edos.debian.net, and other quality assurance services used daily by Debian and other distros.

1.2  Why I am seeking re-election

My general motivations for running for DPL are well explained in my platform from last year. They are all still valid and motivating reasons for me to serve as DPL for another year.

Further more, I've experienced that serving as DPL is a task with a rather long bootstrap time. At the beginning of the term one needs to find the right balance among several tasks, like following what's happening in the community, document and communicate about DPL whereabouts, decide when to intervene and when to stay put, as well as getting to know a whole lot of external people (representatives of other distributions and companies, non-profit organizations, lawyers, public administrations, journalists, etc.) and vice-versa let all these people know you. The bootstrap time is useful to learn the job but can last several months. For the next term, I'd like to build upon the experience I've accumulated to be more effective in helping the Debian community from day 1.

I'm also seeking re-election because, while I'm happy of several changes that have happened in Debian in the last year (thanks not to me, but to way more people than I could possibly list here), I've also accumulated more TODO items on my DPL agenda than what could be possibly addressed in the remainder of this term.

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

The role of Debian

The ecosystem of Free Software is vast and growing. Every active distribution in there should be well aware of its own purpose and distinguishing traits. During the present term I've communicated about the role of Debian observing that we offer a set of pretty rare, if not unique, features among mainstream FOSS distributions. Those features consist of a mix of technical and political aspects: (1) a focus on package quality, with no distinction among first and second class packages; (2) a strong culture of software freedom, which refuses to offer non-free software by default to users and distribution developers (as parts of the infrastructure used to make Debian); (3) independence from commercial interests, with no single company or entity that could claim to babysit Debian; and (4) a decision making model based on a weighted sum of do-ocracy and democracy, which implies that by doing (rather than talking) everyone has a chance to have an impact on Debian.

I believe the above traits turn Debian into a rather unique and fundamental contributor to Free Software and I intend to continue to present the Project that way, both to the Debian community and to external stakeholders. For more information on this aspect, you might want to check the blog post Who the bloody hell cares about Debian and my FOSDEM 2011 talk, which carries the same title.

Contributing to Debian

Last year, I've campaigned on the topic of more gradual and rewarding access paths to Debian. During the past year, we marked a significant advancement on that topic by welcoming non-packaging contributors in our Project. I'm convinced that in the long run that will prove to be a more important change than what we realize at present; it has the potential of turning the monoculture we used to be into the massively varied culture we need to be to be faithful to our vocation of universality. Even though technically non-packaging DD have existed before, voting on that change we have not only communicated to the world that Debian values all kind of contributions equally, but we have also invited all potential contributors to join our do-ocracy with their contributions. I've been glad to discover that several applicants have already answered to that invitation.

More generally, we need to make it easier to contribute to Debian with non-packaging contributions such as documentation, bug triaging, testing, translations, etc. Talking with potential contributions, I still have the impression that whether we are able or not to retain a potential contributor, depends too much on whether or not she will be lucky enough to talk with the right person. If it is the rule, such a scenario is highly suboptimal. One way to ease contribution is learning some tricks from other distributions which, for instance, have since a while decided to present how to contribute documentation on a per-profile basis (see #608400).

Collaborative maintenance and NMUs

I've been a fan of teams and collaborative maintenance since the very beginning. Rest assured that I haven't changed my mind about that since last year. In fact, I'm becoming a bit more radical and I've been campaigning more and more for (properly done!) NMUs, as documented in the motivations of the RCBW initiative. I believe that (properly done!) NMUs are the best tools we have to fight inertia and counter the negative effects of excessive code ownership. Our current guidelines for NMUs are in fact quite liberal and permit to cover up for MIA or negligent maintainers, provided they are put in the best possible conditions to catch up with NMU work later on. I'll keep on advertising for NMU practices whenever needed.

Vocal minorities

Last year I've campaigned about polls as a mean to solve issues with vocal minorities on Debian mailing list. I still believe polls are a potentially useful tool, but I haven't seen the need of using it during the past year. Rather, several people — including myself — have chimed in relevant threads to point out that non-constructive comments from people who are not in charge of specific project areas are useless according to our Constitution. We have also amended our mailing list code of conduct accordingly (see #610262).

Face-to-face meetings

Last year I've also campaigned for face-to-face meetings. I'm glad to report that we now have an informal process and documentation in place for sprints and that we have had 10 sprints in this term, with 2 more forthcoming before its end.

Derivatives

We have worked quite a bit with derivatives during the past year, with initiatives like the derivatives front desk and census. I've also been present as a Debian representative at several meetings of derivatives distribution. There, I've campaigned for a vision of upstream-downstream relationships which is no longer composed by only two actors (one upstream, one downstream), but rather by a long chain of software vendors where every vendor has: direct users, benefits from upstreams, and acts as a platform for several downstreams. In order to pursue the interests of Free Software — for those who, like us, care about that — every actor should give credit to their upstreams and make efforts to push patches back to them. In the specific case of Debian 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.

2.2  Interaction with the project

2.2.1  Being present

As promised, I've done my best to be a present DPL on mailing list discussions, chiming in where I thought it was needed (to solve a conflict, drive a discussion to its conclusion, monitor the project agenda, etc.). I hereby reiterate my intention to do the same for the next term.

2.2.2  Transparency

Last year I've also engaged myself to periodically disclose DPL activities. During the term, I've ended up implementing a specific scheme for doing that; it has worked well for me and I plan to reiterate it. In short, daily bits are taken about my DPL activities and made available to Debian Developers via a project machine, usually on a weekly basis. Monthly, those bits are summarized in a bits from the DPL mail sent to d-d-a. For formal stuff like delegations or other noteworthy activities separate mails are sent to d-d-a as well.

Doing the above takes time which is taken away from other DPL activities. When faced with the dilemma, I've favored ditching some DPL tasks and communicating or taking notes about the others, instead of the other way around. I intend to do the same during the next term.

2.2.3  Money

Since last year we have got better in our transparency in money management (for instance we now have an index of Debian trusted organizations with pointers to their reports), but we still have a long way to go to be properly accountable to our donors. As an ideal goal, we should aim for a quarterly report about our finances, which includes assets from all Debian trusted organizations and all money flows since the last reporting period. I've also come to realize that for the DPL, dealing with cash-based accounting is a pain, since it comes in conjunction with a multitude of organizations to monitor. Switching to cross-organization, accrual-based accounting is a much needed feature to ease expense planning and transitions from one DPL to the next.

On both aspects — quarterly reports and accrual-based accounting — I've been hearing about progress from the auditors and I'll do my best to help them out in delivering.

2.3  Specific plans

2.3.1  Clarify delegates

Last year I've campaigned about clarifying delegations. There has been quite some progress on that: all delegations I've made and/or clarified have corresponding pages under https://wiki.debian.org/Teams/ that include pointers to the current delegation text. Some more delegations are still to be clarified and they should still be documented properly in the organization page on our website.

2.3.2  Core teams

Last year I've also campaigned about restaffing core teams so that at least three members plus assistants are part of each of them (modulo the fact that we have no clear definition of what a core team is...). Some progress has been made there as well and hopefully more will come before the end of this term.

2.3.3  Companies

During this term I've heard too often complains from small/medium companies with Debian expertise, often employing Debian Developers, who are unable to propose Debian to their customers for (silly) reasons such as: (proprietary) application $foo is not certified for Debian or we can't rely only on you as you're too small, we want a labeled support network.

I intend to investigate ways to help those companies to get in touch with each other to see if they can join forces to address some of those issues. On the same topic, I'd like to investigate if we can — without undermining Debian independence — provide incentives for those companies to contribute to Debian even more than what they are already doing.

2.3.4  User surveys

We often stumble upon questions that we are unable to answer ourselves, such as would user like to have a more reliable/eye-candy/long-term-support/bleeding-edge/...distro? I've been collecting some of those questions in the past month and I plan to synthesize (some of) them into a Debian user poll to be run yearly, as many other Free Software projects are doing to gather actual feedback from their users. Similar spontaneous initiatives have been proposed in the past, but they have been either quite narrow (e.g. without coordination with Debian official communication channels which can reach out to a large public) or not suitable for fully automated analysis (and hence doomed to failure at the growth of the target sample).

2.3.5  Communication and publicity

In my humble opinion, project communication has worked really well this year, mainly thanks to the work of the press and publicity teams. We have sent out more announcements in 2010 than in previous years since quite a while, we have started to use a quite followed @debian account on identi.ca, and several news feeds from our website have been made RSS-able, ... not to mention the amazing achievement of the webmaster team in revamping the layout of the Debian website together with the release of Squeeze.

We need to continue this trend and use social communications, where it is compatible with our Free Software principles, to reach out to our potential public. For instance, Debian still lacks an official blog to be used as a communication channel to our community in less formal terms than press releases. Recently the closest approximation we had of it — http://news.debian.net — has been closed down. From a communication point of view that is a pity, given that the other communication channels we have do not enable users to easily give feedback on news items by means of comments, trackbacks, and the like. I intend to work on fixing this and, more generally, to remain involved in the publicity team as I've been during this term.

2.3.6  Local teams

Debian lacks a structured network of local teams / Debian user groups. I've come to realize this during the present term pretty quickly, as soon as people started asking me questions like who should we contact for an event in $city? or do you know about periodic Debian-related meetings in $city we can attend?. We have some answers about that, like the debian-events-* mailing lists and the recently revamped event teams, but they are no substitute for a network of local teams.

Other distributions have established similar networks and their experiences seem to show that they are useful not only as local contact points for events, but also as starting circles that help users becoming gradually more and more involved with the distribution. I think we should consider something similar for Debian. I've mentioned the idea from time to time to the local communities I've visited for talks and generally the feedback has been very positive.

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 keep on hold my other Debian tasks, as I've done in the present term: it is an obligation towards former co-workers and a fair deal to avoid burning out.

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 as a volunteer, to be fully dedicated to DPL tasks. Luckily, I have at present a very FOSS-sensitive boss who has been very supportive of my DPL activities during this term. I have been able to enjoy the freedom to reorganize my schedule for urgencies and/or longer activities, such as traveling for Debian-related reasons.

I can count on similar arrangements for the first 6 months of the forthcoming term. For the remaining 6 months I still don't know yet, as it's not clear yet who will be my employer by then. Nonetheless, in all possible employment scenarios I can imagine at the time of writing, I'm confident that I will be able to find the time needed to carry on my DPL duties. If at any time I will realize that is no longer the case, I will immediately resign from DPL.

Like most of us, I'm generally available not only via email, but also on IRC, phone, etc.

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

Back to the Debian Project homepage.