fix broken link to the DM wiki page
[homepage.git] / hacking / debian / dpl-2009 / platform.html
1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
2             "">
3 <HTML>
4 <HEAD>
5 <TITLE>DPL platform
6 </TITLE>
8 <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
9 <META name="GENERATOR" content="hevea 1.10">
10 <STYLE type="text/css">
11 .li-itemize{margin:1ex 0ex;}
12 .li-enumerate{margin:1ex 0ex;}
13 .dd-description{margin:0ex 0ex 1ex 4ex;}
14 .dt-description{margin:0ex;}
15 .toc{list-style:none;}
16 .thefootnotes{text-align:left;margin:0ex;}
17 .dt-thefootnotes{margin:0em;}
18 .dd-thefootnotes{margin:0em 0em 0em 2em;}
19 .footnoterule{margin:1em auto 1em 0px;width:50%;}
20 .caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
21 .title{margin:2ex auto;text-align:center}
22 .center{text-align:center;margin-left:auto;margin-right:auto;}
23 .flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
24 .flushright{text-align:right;margin-left:auto;margin-right:0ex;}
25 DIV TABLE{margin-left:inherit;margin-right:inherit;}
26 PRE{text-align:left;margin-left:0ex;margin-right:auto;}
27 BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
28 TD P{margin:0px;}
29 .boxed{border:1px solid black}
30 .textboxed{border:1px solid black}
31 .vbar{border:none;width:2px;background-color:black;}
32 .hbar{border:none;height:2px;width:100%;background-color:black;}
33 .hfill{border:none;height:1px;width:200%;background-color:black;}
34 .vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
35 .vdcell{white-space:nowrap;padding:0px;width:auto; border:2px solid green;}
36 .display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
37 .dcell{white-space:nowrap;padding:0px;width:auto; border:none;}
38 .dcenter{margin:0ex auto;}
39 .vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
40 .minipage{text-align:left; margin-left:0em; margin-right:auto;}
41 .marginpar{border:solid thin black; width:20%; text-align:left;}
42 .marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
43 .marginparright{float:right; margin-left:1ex; margin-right:0ex;}
44 .theorem{text-align:left;margin:1ex auto 1ex 0ex;}
45 .part{margin:2ex auto;text-align:center}
46 .rfloat{float:right;}
47 body{font-family: sans-serif;
48 font-size: medium;
49 }
50 h1, h2, h3, h4{font-weight: normal;
51 }
52 h1{font-size: 140%;}
53 h2{font-size: 130%;
54 border-bottom: solid 1pt;
55 }
56 h3{font-size: 115%;}
57 h4{font-size: 105%;}
58 .paragraph{font-size: 105%;
59 font-weight: normal;
60 /* text-decoration: underline; */
61 }
62 .alphaenum ol{list-style-type: lower-alpha;
63 }
64 .mantra{border: solid;
65 border-width: 1px;
66 border-color: #aaa;
67 background: #eee;
68 margin: 2pt;
69 margin-left: 8%;
70 margin-right: 8%;
71 padding: 2pt;
72 }
73 .summary{border: solid;
74 border-width: 1px;
75 border-color: #aaa;
76 background: #eee;
77 margin: 2pt;
78 padding: 2pt;
79 }
80 a{text-decoration: none;}
81 a:hover{text-decoration: underline;}
82 </STYLE>
83 </HEAD>
84 <BODY >
85 <!--HEVEA command line is: /usr/bin/hevea -fix platform.tex -->
86 <!--CUT DEF section 1 --><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">DPL platform</H1><H3 CLASS="titlerest">Stefano Zacchiroli<BR>
87  <A HREF=""><TT></TT></A><BR>
88  <A HREF=""><TT></TT></A></H3></TD></TR>
89 </TABLE><DIV CLASS="center">
90 version <TT>1.1</TT>
91 </DIV><P><FONT SIZE=1>[ Other formats available:
92 </FONT><A HREF=""><FONT SIZE=1>.html</FONT></A><FONT SIZE=1>,
93 </FONT><A HREF=""><FONT SIZE=1>.pdf</FONT></A><FONT SIZE=1>,
94 </FONT><A HREF=""><FONT SIZE=1>.txt</FONT></A><FONT SIZE=1>. ]</FONT></P><!--TOC section Executive summary-->
95 <H2 CLASS="section"><!--SEC ANCHOR -->Executive summary</H2><!--SEC END --><P>Hi, I’m <A HREF="">Stefano Zacchiroli</A>—mostly
96 known as <EM>Zack</EM>—and I’m running for DPL.
97 </P><DIV CLASS="summary">
98 The <B>main points</B> of my platform are as follows:
99 <UL CLASS="itemize"><LI CLASS="li-itemize"> <I>I intend to be a </I><I><EM>present</EM></I><I> DPL, both
100 in discussions and as the responsible of the project agenda.</I></LI><LI CLASS="li-itemize"><I>I will provide a constant stream of DPL
101 activity news, to be frozen and posted </I><I><EM>monthly</EM></I><I> to
102 </I><I><TT>d-d-a</TT></I><I>.</I></LI><LI CLASS="li-itemize"><I>To resolve the impasse of vocal
103 minorities, I will apply mechanisms that make rough </I><I><EM>consensus</EM></I><I>
104 emerge when it exists.</I></LI><LI CLASS="li-itemize"><I>I will push for more </I><I><EM>gradual</EM></I><I> and
105 </I><I><EM>rewarding</EM></I><I> access paths to Debian.</I></LI><LI CLASS="li-itemize"><I>I will push to diminish </I><I><EM>strong package
106 ownership</EM></I><I> when it conflicts with package quality.</I></LI><LI CLASS="li-itemize"><I>I will do my best to support, with money
107 and other resources, contributors get-togethers.</I></LI></UL></DIV><P>The reminder of the platform provides background information about me
108 (Section <A HREF="#sec:intro">1</A>), describes the above points in more detail
109 (Section <A HREF="#sec:goals">2</A>), and highlights more specific plans for my
110 term (Section <A HREF="#sec:itches">2.3</A>). Rebuttals can be found in
111 Section <A HREF="#sec:rebuttals">A</A>.</P><!--TOC section Introduction-->
112 <H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc1">1</A>  Introduction</H2><!--SEC END --><P>
113 <A NAME="sec:intro"></A></P><!--TOC subsection Who am I-->
114 <H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc2">1.1</A>  Who am I</H3><!--SEC END --><P>
115 <A NAME="sec:aboutme"></A></P><P>I became a Debian Developer (DD) in March 2001, shortly after the
116 current NM process was introduced. My Debian involvement has been
117 through two distinct phases. In the first one I only cared about my
118 packages, ignoring the community: no IRC, no <TT>-devel</TT>
119 subscription, etc. Then, at LinuxTag 2004, I discovered Debian as a
120 <EM>community</EM> and got fascinated by it, gradually increasing my
121 involvement in the project.</P><P>Technically, my main activities during all these years have been:
122 </P><DL CLASS="description"><DT CLASS="dt-description">
123 <B>PTS</B></DT><DD CLASS="dd-description"> I’ve been co-maintaining the
124 <A HREF="">Package Tracking System (PTS)</A>
125 for the past 3-4 years, contributing day to day maintenance as well
126 as
127 <A HREF="">more</A>
128 <A HREF="">significant</A>
129 <A HREF="">changes</A>. Details
130 are available <A HREF="">on my blog</A>.</DD><DT CLASS="dt-description"><B>Vcs-* fields</B></DT><DD CLASS="dd-description"> I’ve
131 <A HREF="">made</A>
132 <A HREF="">popular</A>
133 the notion of VCS (Version Control System) fields in <TT>debian/control</TT>, and I wrote
134 <A HREF=""><TT>debcheckout</TT></A>.</DD><DT CLASS="dt-description"><B>Quality Assurance</B></DT><DD CLASS="dd-description"> …more generally, I’ve joined the
135 <A HREF="">QA</A> team because I
136 enjoy thinking of the project as a whole and looking for new
137 solutions
138 (e.g. <A HREF="">UDD</A>) to
139 our persisting problems.</DD><DT CLASS="dt-description"><B>OCaml</B></DT><DD CLASS="dd-description"> Better support for the
140 <A HREF="">OCaml</A> programming language was my
141 motivation to join the project. I’ve contributed forming the
142 <A HREF="">Debian OCaml
143 Task Force</A> in which I’ve ranged from the newbie, to leading
144 activities. The team nowadays maintains more than
145 <A HREF="">120
146 source packages</A> with
147 <A HREF="">insanely
148 intricate inter-dependencies</A>, and complex
149 <A HREF="">transition</A>
150 needs.</DD><DT CLASS="dt-description"><B>Packaging</B></DT><DD CLASS="dd-description"> Obviously, I’ve maintained (and continue to maintain)
151 <A HREF="">several
152 packages</A>. Beside OCaml-related packages, I’m proud of
153 contributions to
154 <A HREF=""><TT>devscripts</TT></A>,
155 <A HREF=""><TT>vim</TT></A> (in spite of
156 my recent
157 <A HREF="">betrayal</A>
158 <TT>:-)</TT>, and
159 <A HREF=""><TT>python-debian</TT></A>.</DD></DL><P>Believing in the community as the real strength of Debian, I’m a
160 regular attendee of <A HREF="">DebConf</A> and, time
161 permitting, of any other face to face meetings, like the
162 <A HREF="">Extremadura
163 work ones</A>.</P><P>In real life, I’m <A HREF="">a computer
164 science researcher</A>, currently working as a post-doc in the
165 <A HREF="">PPS</A> laboratory,
166 <A HREF="">University Paris
167 Diderot</A>. This laboratory is somewhat of a Debian contributors nest
168 of the French Debian community; our coffee breaks frequently turn into
169 exciting Debian discussions. I mainly work on the
170 <A HREF="">Mancoosi</A> project, where we apply
171 techniques such as formal methods to the study of FOSS
172 distributions, including but not limited to Debian, and to the
173 improvement of upgrade planning algorithms. Mancoosi is the
174 successor of <A HREF="">EDOS</A>, which was the
175 source of various tools used for Debian QA, like
176 <A HREF=""><TT>edos-debcheck</TT></A>,
177 running periodically at
178 <A HREF=""><TT></TT></A>.</P><!--TOC subsection Why I am running for DPL-->
179 <H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc3">1.2</A>  Why I am running for DPL</H3><!--SEC END --><P>
180 <A NAME="sec:whyrunning"></A></P><P>Being the DPL is about two distinct aspects: the institutional role
181 and a set of extra goals the prospective DPL wants to pursue during
182 the term. This distinction matters.</P><P>The institutional role is
183 <A HREF="">described in our
184 constitution</A> and is about three tasks: ordinary and extraordinary
185 decision making, public relations with the outside world, and leading
186 discussions inside the project.</P><P>My personal view of why we need a DPL builds on the observation that
187 we operate as a do-ocracy: anyone willing to do things can decide what
188 and how they are done, and no one can be forced to do anything. Given
189 our size, we have the irresistible tendency of turning into an
190 <EM>imperfect</EM> do-ocracy:
191 </P><DIV CLASS="alphaenum">
192 <OL CLASS="enumerate" type=1><LI CLASS="li-enumerate"> 
193 access restrictions get added to inhibit people doing
194 potentially dangerous actions;
195 </LI><LI CLASS="li-enumerate">non-exciting tasks can rot because nobody is motivated enough to
196 take care of them;
197 </LI><LI CLASS="li-enumerate">those in acquired positions may neglect their duties and lower
198 the quality of the service they offer, because they do not admit
199 they are no longer fit for the task.
200 </LI></OL>
201 </DIV><P>
202 The DPL has the duty, for a <EM>limited amount of time</EM>, to mitigate
203 the imperfections of our do-ocracy:
204 </P><DIV CLASS="alphaenum">
205 <OL CLASS="enumerate" type=1><LI CLASS="li-enumerate"> 
206 spot overly constraining access restrictions which inhibit
207 capable people to work, inducing inefficiencies and frustration;
208 </LI><LI CLASS="li-enumerate">find people willing to do non-exciting tasks for the project’s
209 global good (making sure they get credit for it);
210 </LI><LI CLASS="li-enumerate">assign people to key positions to improve service quality inside
211 and outside the project.
212 </LI></OL>
213 </DIV><P>
214 The reward is the occasion to push for project-wide improvements by
215 the only virtue of occupying the DPL position.</P><P>I want to challenge myself to be a transparent and present DPL, and to
216 improve the mechanisms of our project. That is why I’m running for
217 DPL. (Actually, I’ve also been <EM>asked</EM> by some of you to
218 run, so the blame for bothering you in reading all this does not
219 fall exclusively on me <TT>:-)</TT></P><!--TOC section My goals-->
220 <H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc4">2</A>  My goals</H2><!--SEC END --><P>
221 <A NAME="sec:goals"></A></P><P>DPL institutional tasks deal with decision-making in situations that
222 are, in general, unknown <EM>a priori</EM>. Hence, I present my goals as
223 follows.
224 </P><UL CLASS="itemize"><LI CLASS="li-itemize">
225 First I give my <EM>vision</EM> encompassing key themes of Debian
226 “politics”. This, I believe, is the only way to give a rough idea
227 of how I can react to unforeseeable scenarios.</LI><LI CLASS="li-itemize">Then I present the <EM>approach</EM> I intend to apply in carrying
228 on DPL institutional tasks.</LI><LI CLASS="li-itemize">Finally I list some specific projects I intend to pursue as DPL.
229 </LI></UL><!--TOC subsection Vision-->
230 <H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc5">2.1</A>  Vision</H3><!--SEC END --><P>
231 <A NAME="sec:vision"></A></P><!--TOC paragraph Non-DD contributors-->
232 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Non-DD contributors</H5><!--SEC END --><P>
233 The introduction of <A HREF="">DMs</A>
234 (Debian Maintainers) has been a fortunate event for Debian. Some
235 people argue that it has opened up our archive to packages of
236 sub-standard quality. That might be true, but we also have (plenty of)
237 sub-standard packages maintained by full-fledged maintainers who have
238 lost their interest in Debian. The solution to both is <EM>more QA</EM>.</P><P>Through the DM process, many enthusiastic people have found their way
239 into Debian, increasing our work force. In addition, the DM process
240 induces a <EM>more controlled process</EM> to become a full-fledged DD,
241 with greater insurance of serious commitment to Debian, and experience
242 levels. All in all, the DM process is a more fine-grained access path
243 to Debian than what we had before it, which enables us to give back to
244 our contributors <EM>gradually</EM> through recognition. Contributing to
245 Debian is no longer all-or-nothing, it is now way less frustrating for
246 packagers, who previously might have turned their efforts to other
247 projects.</P><P>We need to generalize the lessons learned from the DM process. We have
248 a lot of potential valuable contributors out there. They just need
249 better documentation about <EM>how</EM> to join. They simply demand
250 something in exchange, to be proud of, that acknowledges their
251 efforts. I do not have preconceptions on the different ways of
252 achieving this (e.g., ACLs vs linearly increasing privileges), but we
253 need to go in that direction. In doing so, we should also relax our
254 implicit assumptions that <EM>only</EM> technical abilities matter in
255 Debian. The truly “Universal Operating System” is <EM>mainly</EM>, not
256 only, made of software; it is also made of translations, graphics,
257 musics, etc.</P><DIV CLASS="mantra">
258 <DIV CLASS="center"><I>I will push for more </I><I><EM>gradual</EM></I><I> and
259 </I><I><EM>rewarding</EM></I><I> access paths to Debian.</I></DIV>
260 </DIV><!--TOC paragraph Collaborative maintenance-->
261 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Collaborative maintenance</H5><!--SEC END --><P>
262 The introduction of the <TT>Uploaders:</TT> field is another example of
263 a fortunate development in Debian. While it can, in principle, form
264 teams of people with no clear responsibility for specific tasks, on
265 average it works very well. It creates efficient technical spaces for
266 collaboration on specific topics, and it also scales through
267 (re)creating organizational structures with specific position and
268 task-assignments.</P><P>Collaborative maintenance should not be mandatory (we do have several
269 very efficient one-man-band developers), but should be our
270 default. Packaging newbies should start in collaborative maintenance
271 teams and gain experience there. Team member feedback can then be
272 useful to take some of the weight off the shoulders of the AMs
273 (Application Managers). Similarly, we should not accept one-man-band
274 maintenance when it comes with de facto unmaintained packages (to be
275 identified with
276 <A HREF="">suitable QA
277 activities</A>). In those cases, we should suggest—or even force if
278 needed—collaborative maintenance. It can provide a more acceptable
279 exit strategy than public, yet useless, shaming.</P><DIV CLASS="mantra">
280 <DIV CLASS="center"><I>I will push to diminish </I><I><EM>strong package
281 ownership</EM></I><I> when it conflicts with package quality.</I></DIV>
282 </DIV><!--TOC paragraph Vocal minorities-->
283 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Vocal minorities</H5><!--SEC END --><P>
284 Our mailing lists have substantially improved over the last 5
285 years. Every now and then though, they get polluted by (apparently)
286 very vocal minorities capable of polarizing discussions, which is
287 neither productive, nor fun. Given how we are attached to our
288 community, we sometime take part in such discussions, inevitably
289 burning out (how frequent are temporary VAC messages due to this? Too
290 much). My take: </P><BLOCKQUOTE CLASS="quote"> <I>Freedom of speech: good.<BR>
291 Vocal
292 minorities holding hostage the silent majorities: bad.</I></BLOCKQUOTE><P>While we should consider—and have actually applied in the
293 past—moderation measures to counter repeated community disrupting
294 behaviors, we cannot take the risk of applying them only on the
295 <EM>assumption</EM> that the posters actually are a vocal minority.
296 Even though there are no optimal solutions for this kind of problems,
297 technical devices can help. One such device I want to put into use are
298 <A HREF="">polls</A>, as proposed by
299 Jeroen van Wolffelaar and other years ago. The intention is to enable
300 every DD to start mail-based, authenticated polls <EM>à la</EM>
301 <TT>devotee</TT>.</P><P>Polls can give a reasonable idea where the community stands, without
302 having to engage the whole GR (General Resolution) machinery. A poll
303 can either make it clear to participants in discussions (or flame
304 fests) that they are in disagreement with the rest of the project and
305 better stop beating the dying horse, or indicate that they are on the
306 right path.</P><DIV CLASS="mantra">
307 <DIV CLASS="center"><I>To resolve the impasse of vocal
308 minorities, I will apply mechanisms that make rough </I><I><EM>consensus</EM></I><I>
309 emerge when it exists.</I></DIV>
310 </DIV><!--TOC paragraph Face-to-face meetings-->
311 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Face-to-face meetings</H5><!--SEC END --><P>
312 Meetings are essential to improve the quality of collaboration within
313 the project, no matter how good we are in communicating digitally. Get
314 together face to face, hack for hours, do stuff together, and get back
315 home. The day after, your remote collaboration will be better.</P><P>Helping the organization of meetings is a wonderful way of spending
316 Debian money or other investing resources, such as specifically
317 appointed people. Luckily we do have
318 <A HREF="">DebConf</A>, which is organized by a very
319 efficient specific team. Nevertheless it should not be the only
320 get-together, and we should push more for local meetings, employing
321 our resources for that. I see as perfectly reasonable supporting
322 economically the trips of active contributors when that will make
323 possible joining others to work on specific topics.</P><P>A simple metric for deciding when to do that and when not, beside the
324 required amount of money, can be the number <I>x</I> of other developers
325 asking for that. If and <EM>when</EM> money will become an issue, I do
326 not see any showstopper in organizing specific sponsoring campaigns.</P><DIV CLASS="mantra">
327 <DIV CLASS="center"><I>I will do my best to support, with money
328 and other resources, contributors get-togethers.</I></DIV>
329 </DIV><!--TOC paragraph Derivatives-->
330 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Derivatives</H5><!--SEC END --><P>
331 We are part of the FOSS ecosystem, in which patches flow both
332 downstream and upstream. We
333 <A HREF="">have promised</A> to give
334 back to the free software community, yet sometimes we fail to do
335 so. Initiatives like the recent
336 <A HREF="">patch tracker</A> by Sean Finney
337 are a way to ensure that all our changes are visible both to downstream and
338 upstream.</P><P>Our derived distributions (AKA <EM>derivatives</EM>) have us as theirs
339 upstream, and are in a similar situation. We cannot <EM>force</EM> them
340 to give back to us, because our promises are not necessarily theirs,
341 still we should:
342 </P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
343 be exemplar in our giving back practices, for example by
344 tracking publicly our efforts in sending patches upstream;</LI><LI CLASS="li-enumerate">make as easy as possible to give back to us, for example by
345 participating in cross-distribution initiatives which make
346 maintainers know each other and share distributed VCSs.
347 </LI></OL><P>
348 Doing both will strengthen our give back <EM>requests</EM> to
349 derivatives that we should not stop posing.</P><!--TOC subsection DPL ↔ project interaction-->
350 <H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">2.2</A>  DPL ↔ project interaction</H3><!--SEC END --><P>
351 <A NAME="sec:dpl-project"></A></P><!--TOC subsubsection Being present-->
352 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc7">2.2.1</A>  Being present</H4><!--SEC END --><P>
353 <A NAME="sec:presence"></A></P><P>As a DD, I have often suffered from a perceived DPL “absence”.
354 Maybe it was just me not being pro-active enough to ping the DPL on
355 IRC or email and ask, but I consider it a DPL duty to communicate his
356 or her presence. That comes in two forms: one is to <B>lead
357 discussions</B> among developers, as
358 <A HREF="">prescribed in the
359 constitution</A>, something I have rarely seen. While we do not want
360 that by default (no need for a “post-in-every-thread” DPL), I will
361 try to be present in “hot” discussions (vague on purpose) which
362 concern the organization and the big picture of the project. I will
363 also encourage seeking the DPL opinion on specific topics, by pinging
364 me explicitly.</P><P>The DPL opinion can also be a reasonable first attempt to solve a
365 conflict; if it fails, we do have other mechanisms to settle it. In
366 this respect, I believe my personal qualities can be useful for the
367 project: I am thoughtful, listen to others, and open to be convinced
368 by good arguments.</P><P>More generally, managing the <B>project agenda</B> is something that
369 should be expected from the DPL. Managing the agenda means having a
370 road map of topics the project should <EM>consider</EM> with in some
371 time frame. The
372 <A HREF="">DiscussionsAfterLenny</A>
373 page is an example of such need. The DPL should ensure the project has
374 similar agendas to avoid forgetting about important topics to remember
375 them, say, just before a release.</P><P>Management also means keeping track of what happened. The
376 <A HREF="">DEP proposal</A>—started by
377 myself, <A HREF="">Adeodato Simó</A>,
378 and <A HREF="">Lars Wirzenius</A>—was an attempt to
379 deliver a device to achieve that: no excessive extra burden induced,
380 but a workflow to remember what is the status of “large”
381 project-changing proposals.</P><P>We should expect the DPL to take care of “orphaned” DEPs by
382 reassigning or driving them in first person. DEPs have not taken off
383 due to the lack of some technical bits and of representative
384 examples. I will ensure that we give a try to DEPs, or similar
385 devices, to check whether we can finally have a sane choice between
386 hyper-formal decisions by the mean of GRs and folklore decisions which
387 too often resemble no decisions at all.</P><DIV CLASS="mantra">
388 <DIV CLASS="center"><I>I intend to be a </I><I><EM>present</EM></I><I> DPL, both
389 in discussions and as the responsible of the project agenda.</I></DIV>
390 </DIV><!--TOC subsubsection Transparency-->
391 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc8">2.2.2</A>  Transparency</H4><!--SEC END --><P>
392 <A NAME="sec:transparency"></A></P><P>Another way for a DPL to be present is to disclose <EM>periodically</EM>
393 what she or he is doing; let’s call it “transparency”. Recently we
394 have got better, but only 4 or 5 “bits from …” mails during a
395 DPL term is still too little for a role which is meant to represent
396 such a big and diverse project.</P><P>I’m sure that a given number of DPL activities are not suitable for
397 disclosure, whether they are personal to some, plain boring, or
398 otherwise should not be archived forever on the Web. I’m also aware
399 that writing from scratch a “bits from DPL” mail can be time
400 consuming and possibly intimidating.</P><P>The solution I will implement is to have some constant <B>feed of
401 DPL activity news</B>. “Feed” as a concept, the implementation can
402 vary: an IRC channel, blogging or micro-blogging, a wiki page
403 <TT>BitsFromTheDPL</TT> handled <EM>à la</EM>
404 <A HREF=""><TT>DeveloperNews</TT></A>,
405 posts to <TT>-private</TT> for sensitive material, etc. No feed
406 activity will mean no DPL activity and the right for DDs to complain
407 and demand explanation. I believe that activities which are not yet
408 ready to be disclosed <EM>at all</EM>, not even by censoring or
409 rewording details, are scarce enough <EM>not</EM> to imply empty feeds.</P><P>The resulting feed will then be frozen each month and posted to
410 <TT>d-d-a</TT>. If I fail to post and freeze twice, I will admit my
411 failure by explaining the reasons and seeking opinions on how to
412 continue the term (e.g., using a poll, which can also contain an
413 option “resign, you do not communicate enough”).</P><DIV CLASS="mantra">
414 <DIV CLASS="center"><I>I will provide a constant stream of DPL
415 activity news, to be frozen and posted </I><I><EM>monthly</EM></I><I> to
416 </I><I><TT>d-d-a</TT></I><I>.</I></DIV>
417 </DIV><!--TOC subsubsection (no) DPL board-->
418 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc9">2.2.3</A>  (no) DPL board</H4><!--SEC END --><P>
419 <A NAME="sec:dpl-board"></A></P><P>According to past DPLs, carrying over the DPL burden all alone
420 <EM>is</EM> daunting. To counter that, I will be constantly seeking
421 advice from others, on the basis of their project expertise. I do not
422 however believe in the utility of a <B>DPL board</B>: the DPL term
423 is too short to spend time with extra coordination hops, so I will not
424 have a DPL board. For more specific task assignment we do have
425 delegates, which is more than enough.</P><P>However, as life goes, the DPL is in this sense a single point of
426 failure, and I will be looking for a <B>2IC</B> (second in charge,
427 vice-leader). The duties of the 2IC will be: DPL backup (in case of
428 unexpected absences), and help in communicating outside and inside the
429 project (e.g., for the news feed). The 2IC will be appointed with an
430 ordinary, term-limited, delegation. As the DPL, I will take full
431 responsibility for 2IC actions.</P><DIV CLASS="mantra">
432 <DIV CLASS="center"><I>I will not have a DPL board; I will rather look for a 2IC for
433 backup and communication.</I></DIV>
434 </DIV><!--TOC subsection Specific plans-->
435 <H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc10">2.3</A>  Specific plans</H3><!--SEC END --><P>
436 <A NAME="sec:itches"></A></P><!--TOC subsubsection Clarify delegates-->
437 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc11">2.3.1</A>  Clarify delegates</H4><!--SEC END --><P>
438 <A NAME="sec:delegates"></A></P><P>Remember: TINC (there is no cabal). Good news. Then:
439 </P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
440 all current
441 <A HREF="">delegates</A> should
442 be clearly stated at
443 <A HREF="">our organization
444 page</A> with reference to the delegation mail;</LI><LI CLASS="li-enumerate">all people in core teams which predate widespread use of
445 delegation should be officially delegated. This will avoid
446 disparities between “young” team members who are delegates and
447 “old” team members who live in an unclear limbo.
448 </LI></OL><!--TOC subsubsection The website issue-->
449 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc12">2.3.2</A>  The website issue</H4><!--SEC END --><P>
450 <A NAME="sec:website"></A></P><P>We all want a
451 <A HREF="">sexier website</A>,
452 i.e., a website where people can find what they look for, and which
453 does not make us look like Debian is an operating system of the
454 1980s. While work on the issue
455 <A HREF="">has been going
456 on</A> in the WWW team, we have not delivered visible improvements yet.</P><P>I intend to help the WWW team in order to solve the main issues within
457 the term. While it will be pointless to set the precise technical
458 goals in a platform, my intended course of actions will be as
459 follows. All steps are meant to be performed in agreement with the WWW
460 team.
461 </P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
462 Establish the minimal requirements for an improved website in
463 terms of: accessibility, site structure, team work flow. Make those
464 requirements <EM>public</EM> as well as a detailed plan of the work
465 that needs to be done to implement them: we will not hide problems.</LI><LI CLASS="li-enumerate">Send out a call for help to our community, looking for people
466 willing to take over the job and complete it in a given time
467 frame. (Yes, I know we are all volunteers, but we do take
468 responsibilities and aim for deadlines, this issue is relevant
469 enough to ask for it.)<SUP><A NAME="text1" HREF="#note1">1</A></SUP></LI><LI CLASS="li-enumerate">Make sure the takers, if any, have access to the needed
470 resources and that they get credit for their attempt and, hopefully,
471 success.</LI></OL><P>If all this fails, we will have an emergency plan. For instance, we
472 can consider an external bounty (i.e. nobody involved in Debian can
473 take it) to realize what is missing, under the supervision of the WWW
474 team. We regularly pay for services we are unable to produce by
475 ourselves, the website should be no difference.</P><!--TOC subsubsection Core teams-->
476 <H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc13">2.3.3</A>  Core teams</H4><!--SEC END --><P>
477 <A NAME="sec:core-teams"></A></P><P>Our core teams have recently improved a lot, in terms of manpower and
478 communication. Kudos for that go to Steve McIntyre and Sam Hocevar
479 (the last two DPLs) and of course to the team themselves.
480 Nevertheless some teams are still short, or so it seems from the
481 outside. Adding members makes a team more tolerant to absences, and
482 also helps to prepare the next generation of contributors. The
483 distinction between assistants and regulars in several teams seems to
484 work very well in that respect.</P><P>My naive intention would be to bring all core teams to at least three
485 members and to push for campaigning for assistants when there are no
486 well-established procedures for team joining. Also, by looking at our
487 <A HREF="">organization page</A> it
488 looks as if several teams are either not active anymore, or are very
489 bad in communicating what they are doing. For their own good, involved
490 people should be encouraged to replacement and something to work on
491 that is more fun for them.</P><P>All these changes however should be attempted first with team
492 agreement, to not bother potentially understaffed yet very efficient
493 teams. I will start from the precious
494 <A HREF="">team
495 reviews</A> gathered by Steve McIntyre last year<SUP><A NAME="text2" HREF="#note2">2</A></SUP> to drive re-staffing and procedural changes
496 in order not to bother properly working teams.</P><!--TOC section Additional info-->
497 <H2 CLASS="section"><!--SEC ANCHOR -->Additional info</H2><!--SEC END --><P>
498 <A NAME="sec:extra"></A></P><!--TOC subsection Time commitment-->
499 <H3 CLASS="subsection"><!--SEC ANCHOR -->Time commitment</H3><!--SEC END --><P>
500 <A NAME="sec:time-commit"></A></P><P>Being DPL is challenging ; for it to succeed the job must be taken
501 seriously. For the duration of the mandate I will therefore put on
502 hold my other Debian tasks; it is an obligation towards habitual
503 co-workers and a fair deal to avoid burning out. I’m not the only
504 responsible person in most of my current Debian duties and I will leave
505 behind efficient teams, so I’m confident the tasks will not remain
506 unattended. The remaining parts are a handful of packages which will
507 need new maintainers.</P><P>On the same topic and for the sake of clarity: some DPL candidates
508 have in the past declared their ability to act as DPL full-time. I
509 cannot grant that. What I offer is my Debian time, to be diverted to
510 DPL tasks. Luckily though, I work at a university where I have a very
511 FOSS-sensitive boss. I have the freedom to reorganize and possibly
512 shrink my schedule both for emergencies, and for longer activities
513 such as traveling to deliver Debian talks. Like most of us, I’m
514 generally available on IRC, phone, etc.</P><!--TOC subsection Live platform-->
515 <H3 CLASS="subsection"><!--SEC ANCHOR -->Live platform</H3><!--SEC END --><P>
516 <A NAME="sec:live-platform"></A></P><P>Beside rebuttals, the DPL platform is fixed once and for all at the
517 end of the nomination period. While that makes perfect sense in the
518 context of a vote, it makes it hard for candidates to communicate
519 their positions on important topics, because of the volume of
520 information the vote process generates. Hence, if noteworthy topics
521 will come up during the campaigning, I will summarize my positions
522 about them at
523 <A HREF=""><TT></TT></A>.</P><!--TOC section Rebuttals-->
524 <H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc14">A</A>  Rebuttals</H2><!--SEC END --><P>
525 <A NAME="sec:rebuttals"></A></P><!--TOC paragraph Steve McIntyre (<TT>93sam</TT>) &amp; Luk Claes (<TT>luk</TT>)-->
526 <H5 CLASS="paragraph"><!--SEC ANCHOR -->Steve McIntyre (<TT>93sam</TT>) &amp; Luk Claes (<TT>luk</TT>)</H5><!--SEC END --><P>I have known Steve and Luk for quite a while now and I deeply respect
527 what they both did for Debian in all these years. I acknowledge all
528 the problems they (yup, “they”, because they are de facto running in
529 tandem) mention in their platform: communication, humbleness and
530 asking for help, ... In fact most of them are general problems of all
531 free software projects.</P><P>That notwithstanding, their platform lacks hints and strategies that
532 explain <EM>how</EM> they are going to attack those problems: it is not
533 enough to say, e.g., </P><BLOCKQUOTE CLASS="quote">I want to see improvements made
534 where they are clearly needed</BLOCKQUOTE><P> to actually deploy the
535 improvements. Also, I’m missing the vision of the two candidates on
536 relevant topics such as Debian membership, mailing list discussion
537 quality, derivatives, ...</P><P>All in all I found that the main contribution to the decision of
538 voting for Steve and Luk is the example set by Steve in the current
539 DPL term. The platform, which is what a rebuttal is meant to comment
540 upon, does not have much more to offer.</P><P>I acknowledge that Steve did some great work during the current DPL
541 term, but most of his practical tasks are approaching completion. It
542 would have been great to know what, if elected, he plans to work on
543 <EM>additionally</EM>. Presenting such a “diff” is, in my opinion, the
544 duty of the DPL currently in charge, when standing for re-election.</P><!--BEGIN NOTES document-->
545 <HR CLASS="footnoterule"><DL CLASS="thefootnotes"><DT CLASS="dt-thefootnotes">
546 <A NAME="note1" HREF="#text1">1</A></DT><DD CLASS="dd-thefootnotes">FWIW, even though it was way
547 simpler, but my experience with the
548 <A HREF="">PTS
549 face lift</A> is that our community is responsive to our
550 deficiencies in Web presence. I asked for a new PTS CSS layout,
551 got several replies, and chose one of them. It required some back
552 and forth round trips, but is nothing different from the usual
553 patch work flow.
554 </DD><DT CLASS="dt-thefootnotes"><A NAME="note2" HREF="#text2">2</A></DT><DD CLASS="dd-thefootnotes">with specific
555 exceptions, if interviewed people do not feel like sharing the
556 actual content with me
557 </DD></DL>
558 <!--END NOTES-->
559 <!--CUT END -->
560 <!--HTMLFOOT-->
561 <!--ENDHTML-->
562 <!--FOOTER-->
563 <HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
564 </EM><A HREF=""><EM>H</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>V</EM><EM><FONT SIZE=2><sup>E</sup></FONT></EM><EM>A</EM></A><EM>.</EM></BLOCKQUOTE></BODY>
565 </HTML>