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

I’m Stefano Zacchiroli—mostly known as Zack. I’ve been serving as DPL during the 2010–2012 period (2 terms) and I’m seeking re-election for the next term.

If you are familiar with my past work as DPL, this platform can be summarized as follows:

1. I’m ready to serve as DPL in the same way and style as before for another, and last, term
2. since the very beginning of the term, I will work to ensure a smooth transition to the future DPL inviting interested developers to participate in DPL activities, and periodically/publicly review the state of the DPL agenda

If you are not familiar with my past work as DPL or if you simply want to know more, the rest of this platform: provides background information about me (Section 1), describes my main goals as DPL (Section 2), and highlights more specific plans for the next term (Section 2.3). Rebuttals can be found in Appendix A.

1  Introduction

1.1  About me

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. 3 years later at LinuxTag 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 past two terms since April 2010. Since then, I’ve reported about all my DPL activities monthly and daily in various forms of “bits from DPL” and on 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 (via NMUs) by starting the Release Critical Bugs of the Week initiative. See the RCBW page for motivations and details. Since then, the initiative has been picked up by others people and I’m immensely proud of it.

AM

I’ve joined the New Members Committee in 2009, becoming an Application Manager. I’ve mentored 6 applicants, 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 (and sometimes little helper of the organization team) of DebConf and of other face to face meetings like BSPs and sprints.

In real life, I’m an assistant professor of computer science at University Paris Diderot (PPS lab) as well as a researcher at IRILL, that regularly sponsors and organizes Debian-related events. Both places are Debian Developer nests, where coffee breaks frequently turn into exciting Debian discussions. I mainly work on the applications of formal methods to the study of component-based systems such as FOSS distributions. As part of the work of my research team, we 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 distributions. I also teach classes to computer science undergraduate, often getting the chance to introduce students to the practices and tools of Free Software development.

1.2  Why I am seeking re-election

My original motivations for running for DPL are well explained in a former platform of mine. They are all still valid and motivating reasons for me to serve as DPL for another year.

But this time is special in its own way, and I have three more reasons for seeking reelection:

1. Serving as DPL is mostly about, well, serving the Debian Project in specific areas: relationship with others, helping discussions, decision making in areas where no one else has responsibility, etc. I think I have managed to offer a decent service in those areas to the Project for the past two terms and I have the energy to do so for one more year.
2. With two years experience as DPL, I have got to discover what I believe to be the intrinsic limits of the institution as it is run today, most notably in terms of transparency of what the DPL “job” is about and of “training” of future DPLs. I have tried to mitigate those limitations by (i) thoroughly documenting my DPL activities and by (ii) periodically calling for helpers who wanted to learn more about the DPL job by actually working on DPL-ish tasks. That has not worked as well as I expected; in particular (ii) doesn’t seem to have worked at all.

   If you want me to lead Debian for another year, I will work from day one to set up mechanisms that ensure more permeability in DPL activities. The goal will be to allow prospective DPLs to gain some experience on DPL activities, and to show their potential abilities in that capacity well before the next DPL elections. Ultimately, I think that is what is needed to guarantee the long term sustainability of the DPL institution. Some ideas on how this could be achieved are discussed in Section 2.3.1.

3. We have discussed in the past arguments in favor and against extending the 1 year duration of DPL terms. I have had the opportunity to serve as DPL for 2 years and that has allowed me to see to the end of tasks that have spanned more than one year (e.g. most of the legal tasks). But there are also tasks on which I have worked since 2010, that I have guided up to here, and that are close to completion (e.g. periodic budget reports, relationships with other important actors of the Free Software ecosystem, etc.). With your permission, I would love to conclude my DPL “career” bringing them to completion.

2  My goals

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

1. First I give my vision encompassing key themes of Debian “politics”. I believe that this, in conjunction with my track record as DPL, might give you 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 reelected 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 past two terms 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 actor of 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 dozens talks I’ve given on the subject as DPL or, for a summary, the blog post “Who the bloody hell cares about Debian”.

Contributing to Debian

I’ve campaigned in the past on the topic of more gradual and rewarding access paths to Debian. During the past years, we marked significant advancements on that topic by first welcoming non-packaging contributors in our Project and then renaming the process to join Debian to New Member process. 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 faithful to our vocation of universality. Even though technically non-packaging DD have existed before, we are now communicating clearly that Debian values all kind of contributions equally, and that we permanently invite all potential contributors to join our Project. Several applicants have already answered to that invitation.

More generally, we need to make it easier to contribute to Debian with all kind of contributions. Talking with potential contributions, I still have the impression that our ability to retain a potential contributor depends too much on whether or not she will be lucky enough to talk with the “right person”. Other projects have gone through similar problems and have implemented working solutions. For instance many other distributions offer “how to contribute” documentation on a per-profile basis (see #608400); other projects has successfully exploited lists of “easy hacks” as ways to guide newbies through their processes and cultures. We should learn from our neighbors, not fear change on the basis that “it has always been this way”, and check which among now established solutions work for us.

Collaborative maintenance and NMUs

I’ve been a fan of teams and collaborative maintenance since their introduction in Debian. I haven’t changed my mind on these matters since my 2010 platforms. In fact, I’ve radicalized my position 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 is the best tool we have to fight inertia and counter the negative effects of excessive package 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

Two years ago 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 them during the past two year. Hopefully we won’t feel the need of them in the near future either. Rather, several people—including myself—have often 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

I’ve campaigned in the past for face-to-face meetings and I’ve worked to establish and document a sprint process that ensure transparency on how Debian money are used. I’ve also moved the process to a public mailing list, allowing whoever is interested to help out with sprint organization. Finally, I’ve presented a report of all recent sprints in a DebConf11 talk. This is a trend we should continue to encourage and increase.

Derivatives

We have worked quite a bit with derivatives during the past 2 years, with initiatives like the derivatives front desk, the derivatives census, and DEX. I’ve took good care of being 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 (upstream/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). Whether I’ve delivered or not, and whether you liked it or not, is up to you to judge. On my part, I hereby reiterated my intention to do so for the next term.

2.2.2  Transparency

I’ve also repeatedly engaged myself to periodically disclose DPL activities. During the past two terms, I’ve ended up implementing a specific scheme for doing that, which has worked well for me and I plan to reiterate. 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 quite some 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 firmly believe the DPL should do so and I intend to keep on doing the same during the next term.

2.3  Specific plans

2.3.1  DPL practicing

If elected again, the next term will be my last term as DPL, because I have different plans for my long term Debian future. Having that in mind, I will work since the very beginning of the term to ensure a smooth transition to the next DPL. The DPL is an elective charge so I don’t get to pick a successor (luckily!). Rather, what I intend to do is work to setup an environment where prospective candidates can practice with DPL activities. Calling for volunteers didn’t work in the past, but might work this time thanks to the certainty—which I’ve just given above—that this will be my last term.

If that will still not work, I plan to contact people I feel like working with, and invite them to participate in DPL activities. Either way, I hope to be able to form a group of people who are motivated enough to, at the same time, help out with DPL tasks for the next term, and get a glimpse of what the DPL job is about. Whether it will actually happen or not is not up to me, but to the actual interest of people to step in and work with me to practice on DPL tasks. If that will work, I intend to hold monthly public IRC meetings with the people helping out, where outstanding tasks on the DPL agenda can be reviewed and new one discussed in a more transparent way than by mailing leader@d.o.

2.3.2  Money

(This is one of the tasks on which I’ve been working since my first term, but are still ongoing.)

As I have discussed in a recent blog post, publishing periodic and comprehensive Debian money reports has proven to be surprisingly challenging, due to the disperse nature of Debian finances. I have worked with the Debian auditors to clarify the status of existing Trusted Organization and set up procedures that work for both the auditors and the DPL, to track expenses and query the current state of Debian finances (which is not an entirely trivial exercise due to the perennial different between pledged and spent money). The auditors have in the meantime checked in a shared ledger (textual) database a good deal of the money transactions of the past 2-3 years. We are, in essence, as close to the goal of sustainable periodic money reporting as we have ever been.

I will work to complete this, because I don’t think it is acceptable to solicit donations and not publishing periodic reports about what we do with donated money.

2.3.3  Delegations and core teams

I’ve campaigned in the past 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.

I’ve also campaigned about restaffing core teams so that at least three members plus assistants are part of each of them. Work has been done on this front, but this is an always running task on which I plan to keep on working.

2.3.4  Companies

Last year, I’ve campaigned about the need of allowing companies with an interest in Debian to flock together and get in touch with us. Quoting myself from a recent interview:

[…] I do realize that for Free Software to succeed companies, employees, and salaries should all have a role. I admire projects that strike a good balance between volunteer and paid work. The Linux kernel is emblematic in that respect: many developers are paid by companies that have a commercial or strategic interest in Linux. Nevertheless volunteers contributions are aplenty and the Linux community gives a convincing impression that choices are driven by the community itself (or by its benevolent dictator) without money-driven impositions.

Such an ecosystem does not exist around Debian. We do have a partner program that allows for it to happen, but we have very few partners with an interest in doing distribution development work. […] I’m worried by this state of affairs, because it de facto means we lag behind in terms of available people power. In a community of volunteers, that might frustrate people and that is not good.

I have worked on that front and as a result we now have a -companies mailing list ready to accept subscriptions from representatives of companies with a strong strategic interest and commitment to Debian. That is only part of the picture, though. On the one hand, we need to invite companies to join the initiative; I will get to that before the end of the present term. On the other hand, we need to bootstrap activities of this particular “user group” and listen to their needs, without undermining Debian independence. I intend to work on that part during the next term.

2.3.5  User surveys

Last year, I’ve campaigned to establish periodic user surveys to answer user questions that we are unable to answer ourselves. Unfortunately, I didn’t get a chance to work on it during the present term and nobody stepped in to pick up the task. I still consider periodic user surveys a worthwhile goal and I’ll give it a chance next term.

2.3.6  Communication and publicity

I am proud of having actively participated to the activities of the Debian Press and Publicity teams since I became DPL in 2010.

Thanks to members of both teams, I have the impression we are at an all time high in our communication about Debian. For instance, after having sent out more announcement in 2010 than in previous years since quite a while, 2011 has been even better on that front. We have also kept on using Free Software friendly social media such as identi.ca. I think we should continue this trend. We still lack an official Debian blog, but work on that front is progressing these very same days thanks to DSA and members of the Press and Publicity team, with my participation.

I intend to remain involved in the publicity team as I’ve been for the past two terms.

2.3.7  Local teams

(This is another task on which I’ve been working during the last term, but which is not completed yet.)

Debian lacks a structured network of local teams / Debian user groups. I’ve come to realize this during the past two terms, 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, which I have recently summarized in a panel at FOSDEM 2012, 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 for the past two terms: 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. My work position has changed since the last DPL elections though. Starting September 2011 I have become a French public servant. I can still enjoy a flexible schedule that allows me to reorganize part of my duties in case of need. However, I’m now also more constrained by teaching calendars that wouldn’t always allow me to, say, take a week off for an overseas Debian-related trip. It will depend on when during the year the need will arise. This hasn’t been a problem for the past 6 months and I don’t expect it to be one during the next term.

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

A  Rebuttals

A.1  Wouter Verhelst

One of the main point of Wouter’s platform—at least according to my reading of it—is the fact that a DPL should formulate a vision; he says: “As the DPL, I think it would be my job to formulate a vision”. I wholeheartedly agree with that. In fact, this is the reason why I have routinely started my DPL platforms with my general “political vision” of Debian and its surroundings. This is also why I have, since the very beginning of my DPL-ship, distilled a list of reasons why the Debian Project is a fundamental actor of the Free Software world and went around the world presenting that “vision”. I therefore consider myself quite attached to that idea.

But when it comes to explain his own vision of the Debian Project, I find Wouter’s platform lacking. He mentions that Debian should be a “welcoming place to work on free software” (which is a desiderata of about all Free Software projects out there) and that he will “work on the issue” of Debian having a reputation of being “somewhat oldfashioned and stale”. Those are legitimate intentions, but I think that a vision for the Project should be much more articulated than that.

Another important point of Wouter’s platform is about having a DPL that is more “leader-y” and push for changes. As part of that, a significant part of the platform reviews my tenure as DPL—an entirely legitimate things to do, with an incumbent DPL who is also candidate—focusing on two aspects: i. reluctance to change, and ii. administrative tasks and procedures. Unsurprisingly, I completely disagree with his impression that I have been reluctant to changes. In fact, I have the converse impression of having pushed for changes at many levels: including important political, vision, and cultural changes. But ultimately this is for Project Members to judge. I have two comments about (ii). The first is that administrative tasks are, like it or not, an important part of the DPL job that should not be neglected, lest creating disservices to the Project. The second is about procedures: I have discussed elsewhere how they are means to specific ends, i.e. possible implementations of changes that one wants to push.

A.2  Gergely Nagy

I find Gergely platform quite interesting, … and surely not only for the entertaining style it is written in! To start with, his figurative representation of running for DPL as walking the plank is quite true and, in my experience, it also extends faithfully to being DPL. From what the platforms tells, Gergely also seems to have been through a Project history quite similar to mine, where the inspiration of the community (and DebConf in particular) has played a very important role.

I agree with both his assessment of the need of attracting to Debian core teams “passionate talent from within the project, or from outside”, and with the proposal of using communication as a mean to achieve that. But that is much easier said than done. A first problem is that the set of talents we have in the Project are very diverse: we have very talented hackers and very talented communicators, but the intersection tend to be small. I agree with Gergely we have improved a lot (and opening up project membership to all kind of contributions was instrumental to that), but right now we simply cannot expect all of us to be willing, or good, at communicating in a way that will attract contributors. What we have to do is rather set incentives that encourage communication to happen, and I am a bit disappointed by the lack of examples of such incentives in Gergely’s platform. I suspect he wants to lead by example on that, which is great. But according to my experience—of someone who has been “chasing” several teams several times to periodically communicate about $this and $that—such an approach does not scale.

Regarding recruitment, Gergely says that “our attempts at recruitment are - I believe - lacking”. I agree, but only because we can always do better. For one thing, we are doing good at attracting developers from derivative distributions. Presenting a view of upstream-downstream relationships that encourages giving back and contributing “as much upstream as possible” seems to be working (and in fact, attracting developers was one of my motivating reasons to start doing so). Similarly, I miss in Gergely’s platform mention of other important vehicles for attracting and retaining contributors, like our website, documentation, and ongoing -publicity activities.

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

Back to the Debian Project homepage.