prepare DPL 2010 candidacy page
authorStefano Zacchiroli <zack@upsilon.cc>
Tue, 16 Mar 2010 09:28:01 +0000 (10:28 +0100)
committerStefano Zacchiroli <zack@upsilon.cc>
Tue, 16 Mar 2010 09:32:05 +0000 (10:32 +0100)
hacking/debian/dpl-2010.mdwn
hacking/debian/dpl-2010/platform.html [new file with mode: 0644]
hacking/debian/dpl-2010/platform.pdf [new file with mode: 0644]

index eb7c110..3d773ae 100644 (file)
@@ -10,12 +10,54 @@ candidate as <acronym title="Debian Project Leader">DPL</acronym> in the
 This page collects information about my candidacy.
 
 * [**nomination** mail](http://lists.debian.org/debian-vote/2010/03/msg00001.html)
-  <small>(with a nice typo towards its end)</small>
+  <small>(with a nice typo towards the end)</small>
+
 * my [[DPL **platform**|platform.html]]:
   [[`.html`|platform.html]],
-  [[`.pdf`|platform.pdf]],
-  [[`.txt`|platform.txt]]. (**coming soon**)
-* my **blog posts** on the subject are reported below (in reverse
-  chronological order):
+  [[`.pdf`|platform.pdf]]
+
+* some pointers to **campaigning discussions** happened on
+  [`-vote`](http://lists.debian.org/debian-vote/2010/03/), and my positions on
+  the raised topics <small>(reverse chronological order)</small>:
+
+  1. [will you have a 2IC?](http://lists.debian.org/debian-vote/2010/03/msg00023.html),
+    [no](http://lists.debian.org/debian-vote/2010/03/msg00027.html)
+  1. on
+    [project funds and donations](http://lists.debian.org/debian-vote/2010/03/msg00032.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00064.html)
+  1. on the
+    [time that will be devoted to DPL tasks](http://lists.debian.org/debian-vote/2010/03/msg00038.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00049.html)
+  1. on
+    [financing development](http://lists.debian.org/debian-vote/2010/03/msg00041.html)
+    (and some Dunc-Tank drifts),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00052.html)
+  1. [in 10 years ...](http://lists.debian.org/debian-vote/2010/03/msg00057.html),
+    how
+    [I'd like Debian to be](http://lists.debian.org/debian-vote/2010/03/msg00075.html)
+  1. on
+    [heated discussions](http://lists.debian.org/debian-vote/2010/03/msg00058.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00072.html)
+  1. on the followed
+    [Debian communication media](http://lists.debian.org/debian-vote/2010/03/msg00059.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00074.html)
+  1. on the
+    [social impact of the release process](http://lists.debian.org/debian-vote/2010/03/msg00071.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00106.html)
+  1. on the
+    [Squeeze freeze process and some of its incidents](http://lists.debian.org/debian-vote/2010/03/msg00084.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00109.html)
+  1. on
+    [withdrawing delegations due to bad community behaviour](http://lists.debian.org/debian-vote/2010/03/msg00085.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00099.html)
+  1. on how to
+    [care for the core infrastructure](http://lists.debian.org/debian-vote/2010/03/msg00086.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00104.html)
+  1. on how to
+    [avoid becoming a "disappearing DPL"](http://lists.debian.org/debian-vote/2010/03/msg00133.html),
+    [my take](http://lists.debian.org/debian-vote/2010/03/msg00136.html)
+
+* my **blog posts** on the subject are reported below <small>(reverse
+  chronological order)</small>:
   
   [[!inline archive="yes" pages="blog/posts/2010/*/* and !blog/posts/*/*/*/* and link(tags/dpl)"]]
diff --git a/hacking/debian/dpl-2010/platform.html b/hacking/debian/dpl-2010/platform.html
new file mode 100644 (file)
index 0000000..bbc33b1
--- /dev/null
@@ -0,0 +1,539 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
+            "http://www.w3.org/TR/REC-html40/loose.dtd">
+<HTML>
+<HEAD>
+<TITLE>DPL platform
+</TITLE>
+
+<META http-equiv="Content-Type" content="text/html; charset=UTF-8">
+<META name="GENERATOR" content="hevea 1.10">
+<STYLE type="text/css">
+.li-itemize{margin:1ex 0ex;}
+.li-enumerate{margin:1ex 0ex;}
+.dd-description{margin:0ex 0ex 1ex 4ex;}
+.dt-description{margin:0ex;}
+.toc{list-style:none;}
+.thefootnotes{text-align:left;margin:0ex;}
+.dt-thefootnotes{margin:0em;}
+.dd-thefootnotes{margin:0em 0em 0em 2em;}
+.footnoterule{margin:1em auto 1em 0px;width:50%;}
+.caption{padding-left:2ex; padding-right:2ex; margin-left:auto; margin-right:auto}
+.title{margin:2ex auto;text-align:center}
+.center{text-align:center;margin-left:auto;margin-right:auto;}
+.flushleft{text-align:left;margin-left:0ex;margin-right:auto;}
+.flushright{text-align:right;margin-left:auto;margin-right:0ex;}
+DIV TABLE{margin-left:inherit;margin-right:inherit;}
+PRE{text-align:left;margin-left:0ex;margin-right:auto;}
+BLOCKQUOTE{margin-left:4ex;margin-right:4ex;text-align:left;}
+TD P{margin:0px;}
+.boxed{border:1px solid black}
+.textboxed{border:1px solid black}
+.vbar{border:none;width:2px;background-color:black;}
+.hbar{border:none;height:2px;width:100%;background-color:black;}
+.hfill{border:none;height:1px;width:200%;background-color:black;}
+.vdisplay{border-collapse:separate;border-spacing:2px;width:auto; empty-cells:show; border:2px solid red;}
+.vdcell{white-space:nowrap;padding:0px;width:auto; border:2px solid green;}
+.display{border-collapse:separate;border-spacing:2px;width:auto; border:none;}
+.dcell{white-space:nowrap;padding:0px;width:auto; border:none;}
+.dcenter{margin:0ex auto;}
+.vdcenter{border:solid #FF8000 2px; margin:0ex auto;}
+.minipage{text-align:left; margin-left:0em; margin-right:auto;}
+.marginpar{border:solid thin black; width:20%; text-align:left;}
+.marginparleft{float:left; margin-left:0ex; margin-right:1ex;}
+.marginparright{float:right; margin-left:1ex; margin-right:0ex;}
+.theorem{text-align:left;margin:1ex auto 1ex 0ex;}
+.part{margin:2ex auto;text-align:center}
+.rfloat{float:right;}
+body{font-family: sans-serif;
+font-size: medium;
+}
+h1, h2, h3, h4{font-weight: normal;
+}
+h1{font-size: 140%;}
+h2{font-size: 130%;
+border-bottom: solid 1pt;
+}
+h3{font-size: 115%;}
+h4{font-size: 105%;}
+.paragraph{font-size: 105%;
+font-weight: normal;
+/* text-decoration: underline; */
+}
+.alphaenum ol{list-style-type: lower-alpha;
+}
+.mantra{border: solid;
+border-width: 1px;
+border-color: #aaa;
+background: #eee;
+margin: 2pt;
+margin-left: 8%;
+margin-right: 8%;
+padding: 2pt;
+}
+.summary{border: solid;
+border-width: 1px;
+border-color: #aaa;
+background: #eee;
+margin: 2pt;
+padding: 2pt;
+}
+a{text-decoration: none;}
+a:hover{text-decoration: underline;}
+.floatright{float: right;
+}
+</STYLE>
+</HEAD>
+<BODY >
+<!--HEVEA command line is: /usr/bin/hevea -fix platform.tex -->
+<!--CUT DEF section 1 --><TABLE CLASS="title"><TR><TD><H1 CLASS="titlemain">DPL platform</H1><H3 CLASS="titlerest">Stefano Zacchiroli<BR>
+ <A HREF="mailto:zack@debian.org"><TT>zack@debian.org</TT></A><BR>
+ <A HREF="http://upsilon.cc/~zack"><TT>http://upsilon.cc/~zack</TT></A></H3><H3 CLASS="titlerest">March 12, 2010</H3></TD></TR>
+</TABLE><DIV CLASS="flushright">
+<FONT SIZE=1>Version: </FONT><FONT SIZE=1><TT>2.0</TT></FONT><FONT SIZE=1><BR>
+ Other formats:
+</FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/platform.html"><FONT SIZE=1>.html</FONT></A><FONT SIZE=1>,
+</FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/platform.pdf"><FONT SIZE=1>.pdf</FONT></A><FONT SIZE=1>.<BR>
+ More info </FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2010/"><FONT SIZE=1>on my
+homepage</FONT></A><FONT SIZE=1>.
+</FONT></DIV><!--TOC section Executive summary-->
+<H2 CLASS="section"><!--SEC ANCHOR -->Executive summary</H2><!--SEC END --><P>Hi, I’m <A HREF="http://upsilon.cc/~zack">Stefano Zacchiroli</A>—mostly
+known as <EM>Zack</EM>—and I’m running for DPL.
+</P><DIV CLASS="summary">
+The <B>main points</B> of my platform are as follows:
+<UL CLASS="itemize"><LI CLASS="li-itemize"> <I>I intend to be a </I><I><EM>present</EM></I><I> DPL, both in
+discussions and as the responsible for the project agenda.</I></LI><LI CLASS="li-itemize"><I>I will provide a stream of DPL activity news, to be
+frozen and posted </I><I><EM>monthly</EM></I><I> to </I><I><TT>d-d-a</TT></I><I>.</I></LI><LI CLASS="li-itemize"><I>I will apply mechanisms that make
+</I><I><EM>consensus</EM></I><I> emerge when it exists.</I></LI><LI CLASS="li-itemize"><I>I will push for more </I><I><EM>gradual</EM></I><I> and
+</I><I><EM>rewarding</EM></I><I> access paths to Debian.</I></LI><LI CLASS="li-itemize"><I>I will fight strong package ownership </I><I><EM>when it
+conflicts with quality</EM></I><I>.</I></LI><LI CLASS="li-itemize"><I>I will do my best to support, with money and other
+resources, contributors meetings.</I></LI></UL></DIV><P>The remainder of the platform provides background information about me
+(Section <A HREF="#sec:intro">1</A>), describes the above points in more detail
+(Section <A HREF="#sec:goals">2</A>), and highlights more specific plans for my term
+(Section <A HREF="#sec:itches">2.3</A>). Rebuttals can be found in
+Appendix <A HREF="#sec:rebuttals">A</A>. If you have read my 2009 platform, you might want
+to have a look at the changelog (Appendix <A HREF="#sec:changelog">B</A>).</P><!--TOC section Introduction-->
+<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc1">1</A>  Introduction</H2><!--SEC END --><P>
+<A NAME="sec:intro"></A></P><!--TOC subsection Who am I-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc2">1.1</A>  Who am I</H3><!--SEC END --><P>
+<A NAME="sec:aboutme"></A></P><P>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 <TT>-devel</TT> subscription, etc. Then at LinuxTag 2004 I discovered
+Debian as a <EM>community</EM> and got fascinated by it, gradually increasing my
+involvement in the project. My most noteworthy activities during all these
+years have been:
+</P><DL CLASS="description"><DT CLASS="dt-description">
+<B>PTS</B></DT><DD CLASS="dd-description"> I’ve been co-maintaining the
+<A HREF="http://packages.qa.debian.org">Package Tracking System (PTS)</A> for the
+past 4-5 years, contributing day to day maintenance as well as
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/">more</A>
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/08/improved_integration_among_PTS_and_Lintian/">significant</A>
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/01/pts_dehs_integration/">changes</A>;
+details are available <A HREF="http://upsilon.cc/~zack/tags/pts/">on my
+blog</A>. (My initial interest in the PTS came from the desire to
+<A HREF="http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/">make</A> the
+<TT>Vcs-*</TT> fields
+<A HREF="http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/">popular</A>,
+which has eventually led me to write
+<A HREF="http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/"><TT>debcheckout</TT></A>.)</DD><DT CLASS="dt-description"><B>QA</B></DT><DD CLASS="dd-description"> more generally, I’m a long time member of the
+<A HREF="http://qa.debian.org/">Quality Assurance</A> team: I enjoy thinking of the
+project as a whole and looking for new solutions
+(e.g. <A HREF="http://wiki.debian.org/UltimateDebianDatabase">UDD</A>,
+<A HREF="http://lists.debian.org/debian-project/2009/07/msg00067.html">DD
+expiry/WAT</A>, etc.) to persisting problems.</DD><DT CLASS="dt-description"><B>OCaml</B></DT><DD CLASS="dd-description"> Proper support for the <A HREF="http://caml.inria.fr">OCaml</A>
+language was my motivation to join the project. I’ve contributed forming the
+<A HREF="http://wiki.debian.org/Teams/OCamlTaskForce">Debian OCaml Task
+Force</A> where I’ve ranged from the newbie, to leading activities. The team
+currently takes care of about
+<A HREF="http://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html">150
+source packages</A> with
+<A HREF="http://upsilon.cc/~zack/research/publications/jfla10-dh-ocaml.pdf">insanely
+intricate inter-dependencies</A>, and complex
+<A HREF="http://glondu.net/debian/ocaml_transition_monitor.html">transition</A>
+needs.</DD><DT CLASS="dt-description"><B>RCBW</B></DT><DD CLASS="dd-description"> Since September 2009, I’ve been contributing to fix one RC bug per
+day by starting the <EM>Release Critical Bugs of the Week</EM> initiative; see
+<A HREF="http://upsilon.cc/~zack/hacking/debian/rcbw/">the RCBW page</A> for
+motivations and details.</DD><DT CLASS="dt-description"><B>AM</B></DT><DD CLASS="dd-description"> I’ve joined the <A HREF="https://nm.debian.org/whoisam.php">New
+Maintainer Committee</A> in 2009, becoming an Application Manager. I’ve been
+processing 4 new maintainers, 2 of which have become Debian Developers in the
+meantime.</DD><DT CLASS="dt-description"><B>Packaging</B></DT><DD CLASS="dd-description"> I also maintain
+<A HREF="http://qa.debian.org/developer.php?login=zack@debian.org">some
+packages</A>. Beside OCaml-related packages, I’m proud of various
+contributions to
+<A HREF="http://packages.debian.org/sid/devscripts"><TT>devscripts</TT></A>,
+<A HREF="http://packages.debian.org/sid/vim"><TT>vim</TT></A>,
+<A HREF="http://packages.debian.org/sid/python-debian"><TT>python-debian</TT></A>,
+and
+<A HREF="http://packages.debian.org/sid/python-turbogears2"><TT>turbogears2</TT></A>.</DD></DL><P>Believing in the community as the real strength of Debian, I’m a regular
+attendee of <A HREF="http://www.debconf.org/">DebConf</A> and, time permitting, of
+any other face to face meetings like
+<A HREF="http://wiki.debian.org/BSP2010/Moenchengladbach">BSPs</A> and
+<A HREF="http://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&context=180&value=debian+extremadura&titlesearch=Titles">Extremadura
+sessions</A>.</P><P>In real life, I’m <A HREF="http://upsilon.cc/~zack/research/">a computer science
+researcher</A>, currently working as a post-doc in the
+<A HREF="http://www.pps.jussieu.fr">PPS</A> laboratory,
+<A HREF="http://www.univ-paris-diderot.fr">University Paris Diderot</A>. The
+laboratory is somewhat of a Debian Developer nest, where coffee breaks
+frequently turn into exciting Debian discussions. I mainly work on the
+<A HREF="http://www.mancoosi.org">Mancoosi</A> project, where we apply formal
+methods to the study of FOSS distributions; the project regularly
+contributes back tools to the community such as
+<A HREF="http://packages.debian.org/sid/edos-debcheck"><TT>edos-debcheck</TT></A>,
+<A HREF="http://edos.debian.net"><TT>edos.debian.net</TT></A>, and other QA services
+used daily by Debian and other distros.</P><!--TOC subsection Why I am running for DPL-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc3">1.2</A>  Why I am running for DPL</H3><!--SEC END --><P>
+<A NAME="sec:whyrunning"></A></P><P>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
+<A HREF="http://www.debian.org/devel/constitution#5">described in our
+constitution</A> and is about three tasks: ordinary and extraordinary decision
+making, public relations with the outside world, and leading discussions inside
+the project.</P><P>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 <EM>imperfect</EM> do-ocracy:
+</P><DIV CLASS="alphaenum">
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate"> 
+access restrictions get added to inhibit people doing alleged dangerous
+actions;
+</LI><LI CLASS="li-enumerate">non-exciting tasks can rot because nobody is motivated enough to take
+care of them;
+</LI><LI CLASS="li-enumerate">those in acquired positions may neglect their duties and lower the
+quality of the service they offer, because they do not admit they are no
+longer fit for the task.
+</LI></OL>
+</DIV><P>
+The DPL has the duty, for a limited amount of time, to mitigate the
+imperfections of our do-ocracy:
+</P><DIV CLASS="alphaenum">
+<OL CLASS="enumerate" type=1><LI CLASS="li-enumerate"> 
+spot overly constraining access restrictions which inhibit capable people
+to work, inducing inefficiencies and frustration;
+</LI><LI CLASS="li-enumerate">find people willing to do non-exciting tasks for the project’s global
+good (in exchange of proper credit);
+</LI><LI CLASS="li-enumerate">(re)assign people to key positions to improve service quality inside and
+outside the project.
+</LI></OL>
+</DIV><P>
+The reward is the occasion to push for project-wide improvements by the only
+virtue of occupying the DPL position.</P><P>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.</P><!--TOC section My goals-->
+<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc4">2</A>  My goals</H2><!--SEC END --><P>
+<A NAME="sec:goals"></A></P><P>DPL institutional tasks deal with decision-making in situations that are, in
+general, unknown <EM>a priori</EM>. Hence, I present my goals as follows.
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+First I give my <EM>vision</EM> 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.</LI><LI CLASS="li-enumerate">Then I present the <EM>approach</EM> I intend to apply in carrying on DPL
+institutional tasks.</LI><LI CLASS="li-enumerate">Finally I list some specific projects I intend to pursue if elected DPL.
+</LI></OL><!--TOC subsection Vision-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc5">2.1</A>  Vision</H3><!--SEC END --><P>
+<A NAME="sec:vision"></A></P><!--TOC paragraph Non-DD contributors-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Non-DD contributors</H5><!--SEC END --><P>
+The introduction of <A HREF="http://wiki.debian.org/DebianMaintainer">DMs</A> (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 <EM>more QA</EM>.</P><P>Through the DM process, many enthusiastic people have found their way into
+Debian, increasing our work force. In addition, the DM process induces a
+<EM>more controlled process</EM> 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 <EM>gradually</EM>
+through recognition.</P><P>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 <EM>how</EM> 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 <EM>only</EM> technical abilities matter in Debian. The
+“best operating system” is <EM>mainly</EM>, not only, made of software; it is
+also made of translations, graphics, musics, etc.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will push for more </I><I><EM>gradual</EM></I><I> and
+</I><I><EM>rewarding</EM></I><I> access paths to Debian.</I></DIV>
+</DIV><!--TOC paragraph Collaborative maintenance-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Collaborative maintenance</H5><!--SEC END --><P>
+The introduction of the <TT>Uploaders:</TT> 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.</P><P>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.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will fight strong package ownership </I><I><EM>when it
+conflicts with quality</EM></I><I>.</I></DIV>
+</DIV><!--TOC paragraph Vocal minorities-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Vocal minorities</H5><!--SEC END --><P>
+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:
+</P><BLOCKQUOTE CLASS="quote"> <I>Freedom of speech: good.<BR>
+ Vocal minorities holding hostage the silent majorities: bad.</I></BLOCKQUOTE><P>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 <EM>assumption</EM> 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 <A HREF="http://master.debian.org/~jeroen/polls/">polls</A>, as proposed by
+others years ago. The intention is to enable every DD to start mail-based,
+authenticated polls <EM>à la</EM> <TT>devotee</TT>.</P><P>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.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will apply mechanisms that make
+</I><I><EM>consensus</EM></I><I> emerge when it exists.</I></DIV>
+</DIV><!--TOC paragraph Face-to-face meetings-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Face-to-face meetings</H5><!--SEC END --><P>
+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.</P><P>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 <A HREF="http://www.debconf.org">DebConf</A>, 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.</P><P>A simple metric for deciding when to do that and when not, beside the required
+amount of money, can be the number <I>x</I> of other developers asking for that. If
+and <EM>when</EM> money will become an issue, I do not see any showstopper in
+organizing specific sponsoring campaigns.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will do my best to support, with money and other
+resources, contributors meetings.</I></DIV>
+</DIV><!--TOC paragraph Derivatives-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Derivatives</H5><!--SEC END --><P>
+We are part of the FOSS ecosystem, in which patches flow both downstream and
+upstream. We <A HREF="http://www.debian.org/social_contract">have promised</A> to
+give back to the free software community, yet sometimes we fail to do
+so. Initiatives like the <A HREF="http://patch-tracking.debian.org">patch tracker</A>
+are a way to ensure that all our changes are visible both to downstream and
+upstream.</P><P>Our derived distributions (AKA <EM>derivatives</EM>) have us as theirs upstream,
+and are in a similar situation. We cannot <EM>force</EM> them to give back to us,
+because our promises are not necessarily theirs, still we should:
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+<EM>be exemplar in our giving back practices</EM>, for example by tracking
+publicly our efforts in sending patches upstream;</LI><LI CLASS="li-enumerate"><EM>make as easy as possible to give back to us</EM>, for example by
+participating in cross-distribution initiatives and by NMU-ing packages when
+important downstream patches lay unattended in the BTS.
+</LI></OL><P>
+Doing both will strengthen our give back <EM>requests</EM> to derivatives that we
+should not stop posing.</P><P>In particular, we should not ignore the fact that <B>Ubuntu</B> is the most
+popular among our derivatives and seems to have a larger community than
+ours. (i) <EM>Technically</EM>, 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) <EM>Politically</EM>,
+we have the asset that Ubuntu releases contain about 70% of unmodified Debian
+packages.<SUP><A NAME="text1" HREF="#note1">1</A></SUP> 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 <EM>communicate</EM>
+why we are better (see Section <A HREF="#sec:website">2.3.1</A>) and don’t forget that we
+<EM>are</EM> better.</P><!--TOC subsection Interaction with the project-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">2.2</A>  Interaction with the project</H3><!--SEC END --><P>
+<A NAME="sec:dpl-project"></A></P><!--TOC subsubsection Being present-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc7">2.2.1</A>  Being present</H4><!--SEC END --><P>
+<A NAME="sec:presence"></A></P><P>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 <B>lead discussions</B> among developers, as
+<A HREF="http://www.debian.org/devel/constitution#5">prescribed in the
+constitution</A>, 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.</P><P>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.</P><P>The second expression of presence that should be expected from the DPL is the
+management of the <B>project agenda</B>, as well as the communication of
+<B>our vision</B>. Managing the agenda means having a road map of topics the
+project should <EM>consider</EM> within some time frame. The
+<A HREF="http://wiki.debian.org/DiscussionsAfterLenny">DiscussionsAfterLenny</A>
+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.</P><P>Management also means keeping track of what happened. The
+<A HREF="http://dep.debian.net/deps/dep0/">DEP proposal</A>, 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.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I intend to be a </I><I><EM>present</EM></I><I> DPL, both in
+discussions and as the responsible for the project agenda.</I></DIV>
+</DIV><!--TOC subsubsection Transparency-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc8">2.2.2</A>  Transparency</H4><!--SEC END --><P>
+<A NAME="sec:transparency"></A></P><P>Another way for a DPL to be present is to disclose <EM>periodically</EM> 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.</P><P>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.</P><P>The solution I will implement is to have some constant <B>feed of DPL
+activity news</B>. “Feed” as a concept, the implementation can vary: an IRC
+channel, blogging or micro-blogging, a wiki page <TT>BitsFromTheDPL</TT>
+handled <EM>à la</EM>
+<A HREF="http://wiki.debian.org/DeveloperNews"><TT>DeveloperNews</TT></A>, posts to
+<TT>-private</TT> 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 <EM>at all</EM>,
+not even by censoring or rewording details, are scarce enough <EM>not</EM> to
+imply empty feeds. The feed will then be frozen each month and
+posted to <TT>d-d-a</TT>. 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.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will provide a stream of DPL activity news, to be
+frozen and posted </I><I><EM>monthly</EM></I><I> to </I><I><TT>d-d-a</TT></I><I>.</I></DIV>
+</DIV><!--TOC paragraph Money-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Money</H5><!--SEC END --><P>
+I believe we need transparency improvements also on <EM>money management</EM>:
+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).</P><!--TOC subsubsection No DPL board-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc9">2.2.3</A>  No DPL board</H4><!--SEC END --><P>
+<A NAME="sec:dpl-board"></A></P><P>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
+<B>DPL board</B>, 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.</P><P>For more specific task assignments we have delegates, which is more than
+enough. In particular, I would like to investigate the usage of
+<EM>time-based delegations</EM> 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).</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will not have a DPL board; I will rather use delegations, possibly
+constraining their duration.</I></DIV>
+</DIV><!--TOC subsection Specific plans-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc10">2.3</A>  Specific plans</H3><!--SEC END --><P>
+<A NAME="sec:itches"></A></P><!--TOC subsubsection The website-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc11">2.3.1</A>  The website</H4><!--SEC END --><P>
+<A NAME="sec:website"></A></P><P>We all want a <A HREF="http://www.debian.org/vote/2007/platforms/sho">sexier
+website</A>, 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 <A HREF="http://wiki.debian.org/DebianWebsiteDiscussion">has
+been going on</A> in the WWW team, we have not delivered visible improvements
+yet.</P><P>As time passes, the drawbacks of the website <EM>status quo</EM> 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 <EM>free from the bottom up</EM> (including all
+pieces of our infrastructure) and that we are a <EM>truly democratic project</EM>
+where decisions are taken by volunteers and not by money. In other words, we
+need to promote <B>our vision</B> to the FOSS world and the website should
+be the primary medium to convey it.</P><P>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.
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+Establish the minimal requirements for an improved website in terms of:
+message, structure, accessibility, work-flow. Make those requirements
+<EM>public</EM> as well as a detailed plan of the work 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 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.)<SUP><A NAME="text2" HREF="#note2">2</A></SUP></LI><LI CLASS="li-enumerate">Make sure the takers have access to the needed resources and that they
+get credit for their attempt and, hopefully, success.</LI></OL><P>If all this fails, we will have an emergency plan. For instance, we can
+consider an <EM>external</EM> 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.</P><!--TOC subsubsection Clarify delegates-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc12">2.3.2</A>  Clarify delegates</H4><!--SEC END --><P>
+<A NAME="sec:delegates"></A></P><P>Remember: TINC (there is no cabal). Good. Then:
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+all current <A HREF="http://www.debian.org/devel/constitution#8">delegates</A>
+should be clearly stated at
+<A HREF="http://www.debian.org/intro/organization">our organization page</A> with
+reference to the delegation mail;</LI><LI CLASS="li-enumerate">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.
+</LI></OL><!--TOC subsubsection Core teams-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc13">2.3.3</A>  Core teams</H4><!--SEC END --><P>
+<A NAME="sec:core-teams"></A></P><P>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.</P><P>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
+<A HREF="http://www.debian.org/intro/organization">organization page</A> 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.</P><P>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
+<A HREF="http://lists.debian.org/debian-devel-announce/2008/04/msg00014.html">team
+reviews</A> by Steve McIntyre has been in the right direction, though it will
+obviously need revamping, as time passes for everybody.</P><!--TOC section Additional info-->
+<H2 CLASS="section"><!--SEC ANCHOR -->Additional info</H2><!--SEC END --><P>
+<A NAME="sec:extra"></A></P><!--TOC paragraph Time commitment-->
+<H5 CLASS="paragraph"><!--SEC ANCHOR -->Time commitment</H5><!--SEC END --><P>
+<A NAME="sec:time-commit"></A></P><P>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.</P><P>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
+<A HREF="http://en.wikipedia.org/wiki/Roberto_Di_Cosmo">FOSS-sensitive boss</A>: 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.</P><!--TOC section Rebuttals-->
+<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc14">A</A>  Rebuttals</H2><!--SEC END --><P>
+<A NAME="sec:rebuttals"></A></P><P>Will be released when ready.</P><!--TOC section Changelog-->
+<H2 CLASS="section"><!--SEC ANCHOR --><A NAME="htoc15">B</A>  Changelog</H2><!--SEC END --><P>
+<A NAME="sec:changelog"></A></P><P><A HREF="http://www.debian.org/vote/2009/platforms/zack">My 2009 platform</A> and
+this one are very much alike. For those who have read the latter, here is a
+brief summary of significant changes:
+</P><UL CLASS="itemize"><LI CLASS="li-itemize">
+Revamp the section on derivatives, detail relationships with Ubuntu (see
+Section <A HREF="#sec:vision">2.1</A>).
+</LI><LI CLASS="li-itemize">I will not be looking for a 2IC, rather I plan to use normal delegations,
+possibly constraining their duration (see Section <A HREF="#sec:dpl-board">2.2.3</A>).
+</LI><LI CLASS="li-itemize">Realize the role of the website in communicating our vistion (see
+Section <A HREF="#sec:website">2.3.1</A>).
+</LI><LI CLASS="li-itemize">Minor changes pretty much everywhere <TT>:-)</TT>
+</LI></UL><!--BEGIN NOTES document-->
+<HR CLASS="footnoterule"><DL CLASS="thefootnotes"><DT CLASS="dt-thefootnotes">
+<A NAME="note1" HREF="#text1">1</A></DT><DD CLASS="dd-thefootnotes">that includes the universe, but the universe is nevertheless
+an important selling point for them
+</DD><DT CLASS="dt-thefootnotes"><A NAME="note2" HREF="#text2">2</A></DT><DD CLASS="dd-thefootnotes">even though it was way
+simpler, my experience with the
+<A HREF="http://upsilon.cc/~zack/blog/posts/2007/12/pts_face_lifted/">PTS face
+lift</A> 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.
+</DD></DL>
+<!--END NOTES-->
+<!--CUT END -->
+<!--HTMLFOOT-->
+<!--ENDHTML-->
+<!--FOOTER-->
+<HR SIZE=2><BLOCKQUOTE CLASS="quote"><EM>This document was translated from L<sup>A</sup>T<sub>E</sub>X by
+</EM><A HREF="http://hevea.inria.fr/index.html"><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>
+</HTML>
diff --git a/hacking/debian/dpl-2010/platform.pdf b/hacking/debian/dpl-2010/platform.pdf
new file mode 100644 (file)
index 0000000..c6a0da4
Binary files /dev/null and b/hacking/debian/dpl-2010/platform.pdf differ