checkin platform in ikiwiki
authorStefano Zacchiroli <zack@upsilon.cc>
Sun, 8 Mar 2009 10:35:37 +0000 (11:35 +0100)
committerStefano Zacchiroli <zack@upsilon.cc>
Sun, 8 Mar 2009 10:35:37 +0000 (11:35 +0100)
hacking/debian/dpl-2009.mdwn
hacking/debian/dpl-2009/platform.html [new file with mode: 0644]
hacking/debian/dpl-2009/platform.pdf [new file with mode: 0644]
hacking/debian/dpl-2009/platform.txt [new file with mode: 0644]

index ca07f68..9e3deca 100644 (file)
@@ -11,8 +11,8 @@ This year, I've been foolish enough to candidate in the yearly
 This page collects information about my candidacy.
 
 * my [nomination mail](http://lists.debian.org/debian-vote/2009/03/msg00004.html)
-* my [DPL platform](http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.html):
-  [`.html`](http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.html),
-  [`.pdf`](http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.pdf),
-  [`.txt`](http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.txt)
+* my [[DPL platform|platform.html]]:
+  [[`.html`|platform.html]],
+  [[`.pdf`|platform.pdf]],
+  [[`.txt`|platform.txt]].
 
diff --git a/hacking/debian/dpl-2009/platform.html b/hacking/debian/dpl-2009/platform.html
new file mode 100644 (file)
index 0000000..df8f572
--- /dev/null
@@ -0,0 +1,535 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
+            "http://www.w3.org/TR/REC-html40/loose.dtd">
+<HTML>
+<HEAD>
+<TITLE>DPL platform 
+ version 0.4~1
+</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%;}
+h3{font-size: 120%;}
+h4{font-size: 110%;}
+.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;}
+</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<BR>
+ version <TT>0.4~1</TT></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></TD></TR>
+</TABLE><P><FONT SIZE=1>[ Other formats available:
+</FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.html"><FONT SIZE=1><TT>.html</TT></FONT></A><FONT SIZE=1>,
+</FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.pdf"><FONT SIZE=1><TT>.pdf</TT></FONT></A><FONT SIZE=1>
+</FONT><A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.txt"><FONT SIZE=1><TT>.txt</TT></FONT></A><FONT SIZE=1>. ]</FONT></P><!--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 will be a present DPL: in discussions
+and as the person in charge of our agenda.</I></LI><LI CLASS="li-itemize"><I>I will provide a constant feed of mini-bits
+from the DPL, to be frozen and posted to </I><I><TT>d-d-a</TT></I><I> monthly.</I></LI><LI CLASS="li-itemize"><I>I will push for more gradual and rewarding
+access paths to Debian.</I></LI><LI CLASS="li-itemize"><I>I will push for mechanisms that makes
+rough consensus visible where it exists.</I></LI><LI CLASS="li-itemize"><I>I will push to diminish strong package
+ownership whenever it conflicts with package quality.</I></LI><LI CLASS="li-itemize"><I>I will do my best to help out, with money
+and other resources, to support contributors get-togethers.</I></LI></UL>
+</DIV><P>The reminder of this platform provides background information about me
+(Section <A HREF="#sec:intro">1</A>), describes the above points in mode detail
+(Section <A HREF="#sec:goals">2</A>), also highlighting some more focused plans
+for my term (Section <A HREF="#sec:itches">2.3</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
+current NM process was introduced. My Debian involvement has been
+through two distinct phases. In the first one 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.</P><P>Technically, my main activities during all these years have been:
+</P><DL CLASS="description"><DT CLASS="dt-description">
+<B>OCaml</B></DT><DD CLASS="dd-description"> Better support for the
+<A HREF="http://caml.inria.fr">OCaml</A> programming 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> in which I’ve ranged from the newbie, to leading
+activities. The team nowadays maintains more than
+<A HREF="http://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html">120
+source packages</A> with
+<A HREF="http://upsilon.cc/~zack/stuff/ocaml-debian-deps.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>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 3-4 years, contributing day to day maintenance as well
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/">as</A>
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/08/improved_integration_among_PTS_and_Lintian/">more</A>
+<A HREF="http://upsilon.cc/~zack/blog/posts/2007/12/pts_face_lifted/">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/qa/">on my blog</A>.</DD><DT CLASS="dt-description"><B>Vcs-* fields</B></DT><DD CLASS="dd-description"> I’ve
+<A HREF="http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/">made</A>
+<A HREF="http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/">popular</A>
+the notion of VCS (Version Control System) related fields in
+<TT>debian/control</TT>, and I wrote
+<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’ve joined the
+<A HREF="http://qa.debian.org/">QA</A> team because 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>) to
+our persisting problems.</DD><DT CLASS="dt-description"><B>Packaging</B></DT><DD CLASS="dd-description"> Obviously, I’ve maintained (and continue to maintain)
+<A HREF="http://qa.debian.org/developer.php?login=zack@debian.org">several
+packages</A>. Beside OCaml-related packages, I’m proud of
+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> (in spite of my
+recent
+<A HREF="http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1/">betrayal</A>
+<TT>:-)</TT>, and
+<A HREF="http://packages.debian.org/sid/python-debian"><TT>python-debian</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 the
+<A HREF="http://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&context=180&value=debian+extremadura&titlesearch=Titles">Extremadura
+work ones</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>. This laboratory is somewhat of a Debian contributors nest
+of the French Debian community; our coffee breaks frequently turn into
+exciting Debian discussions.</P><P>I mainly work on the <A HREF="http://www.mancoosi.org">Mancoosi</A>
+project. We apply techniques such as formal methods to the study of
+FOSS distributions, including but not limited to Debian, and to the
+improvement of upgrade planning algorithms. Mancoosi is the
+successor of <A HREF="http://www.edos-project.org">EDOS</A>, which was the
+source of various tools used for Debian QA, like
+<A HREF="http://packages.debian.org/sid/edos-debcheck"><TT>edos-debcheck</TT></A>, running periodically at
+<A HREF="http://edos.debian.net"><TT>edos.debian.net</TT></A>.</P><!--TOC subsection Why I am running-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc3">1.2</A>  Why I am running</H3><!--SEC END --><P>
+<A NAME="sec:whyrunning"></A></P><P>Being the DPL is about two distinct aspects: the institutional role
+and a set of extra goals which each prospective DPL wants to pursue
+during the term. This distinction matters.</P><P>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 personal 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 irresistible 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
+potentially 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 <EM>limited amount of time</EM>, 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 (making sure they get credit for it);
+</LI><LI CLASS="li-enumerate">assign (additional) people to key positions to improve service
+quality inside and outside the project.
+</LI></OL>
+</DIV><P>
+The reward for this 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 being a transparent and present DPL, and
+improving the mechanisms of our project. That is why I’m running for
+DPL. (I’ve also been <EM>asked</EM> by some of you to run, so
+the blame for bothering you in reading all this does not fall
+exclusively on me <TT>:-)</TT></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><UL CLASS="itemize"><LI CLASS="li-itemize">
+First I give my <EM>vision</EM> encompassing key themes of Debian
+“politics”. This, I believe, is both a way to give a rough idea of
+how I can react to unforeseeable scenarios, and to allow you to get
+to better know me.</LI><LI CLASS="li-itemize">Then I present the <EM>approach</EM> I intend to apply in carrying
+on DPL institutional tasks.</LI><LI CLASS="li-itemize">Finally I list the specific projects of mine I intend to pursue
+as DPL.
+</LI></UL><!--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/Maintainers">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)
+sub-standard packages maintained by full-fledged maintainers who have
+lost their interest in Debian. The solution to both is <EM>more QA</EM>,
+nothing else.</P><P>On the other hand, through the DM process, many enthusiastic people
+have found their way into our project and increased our work force.
+<SUP><A NAME="text1" HREF="#note1">1</A></SUP> In
+addition, the DM process facilitates a more controlled process to
+becoming a full-fledged DD, with greater insurance of serious
+commitment to Debian, and experience levels. In its full generality,
+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. Contributing to Debian is no
+longer all-or-nothing, it is now way less frustrating for packages,
+who previously might have turned their efforts to other projects.</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 and 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 truly “Universal 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 gradual and rewarding
+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 is another example of
+a very 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. Additionally, team member feedback
+can be useful to take some of the weight off the shoulders of the AMs
+(Application Managers). Similarly, we should not accept one-man-band
+maintenance when it comes with de facto unmaintained packages (to be
+identified with
+<A HREF="http://wiki.debian.org/qa.debian.org/bapase">suitable QA
+activities</A>). 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 push to diminish strong package
+ownership whenever it conflicts with package quality.</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 5
+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 (how frequent are temporary VAC messages due to this? Too
+much). 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 propagate are
+<A HREF="http://master.debian.org/~jeroen/polls/">polls</A>, as proposed by
+Jeroen van Wolffelaar and other 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 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 push for mechanisms that makes
+rough consensus visible where 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 a wonderful way of spending
+Debian money or other investing resources, such as specifically
+appointed people. Luckily we do have
+<A HREF="http://www.debconf.org">DebConf</A>, which is organized by a very
+efficient specific team. Nevertheless it 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
+economically 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 help out, with money
+and other resources, to support contributors get-togethers.</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 can 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 recent
+<A HREF="http://patch-tracking.debian.net">patch tracker</A> by Sean Finney
+are a way to ensure that all our changes are visible both to down 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>pretend</EM>
+that they give back to us, because our promises are not necessarily
+theirs. On one hand we should strive for being exemplars in our giving
+back practices, for example by tracking our efforts of doing so. On
+the other hand we should make as easy as possible for people to give
+back to us, for example by participating in cross-distribution
+initiatives which make maintainers know each other and share
+distributed VCSs. Doing both will strengthen our give back
+<EM>demands</EM> that we should not stop posing.</P><!--TOC subsection DPL ↔ project interaction-->
+<H3 CLASS="subsection"><!--SEC ANCHOR --><A NAME="htoc6">2.2</A>  DPL ↔ project interaction</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>As a DD, 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/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 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>More generally, managing the <B>project agenda</B> is something that
+should be expected from the DPL, and on which I intend to
+work. Managing the agenda means on one hand having a road map of
+topics the project should <EM>consider</EM> with in some time frame.
+The
+<A HREF="http://wiki.debian.org/DiscussionsAfterLenny">DiscussionsAfterLenny</A>
+page is an example of such need. The DPL should ensure the project has
+similar agendas to avoid forgetting about important topics to 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>—started by
+myself, <A HREF="http://chistera.yi.org/~adeodato/blog/">Adeodato Simó</A>,
+and <A HREF="http://liw.iki.fi/liw/">Lars Wirzenius</A>—was an attempt to
+deliver a technical device to achieve that: no excessive extra burden
+induced, but a work flow to remember what is the status of “large”
+project-changing proposals.</P><P>In the long run, it is reasonable to expect the DPL to take care of
+“orphaned” DEPs by reassigning or driving them in first person. I am
+convinced that DEPs have not taken off due to the lack of some
+technical bits, and of representative examples. I will ensure that we
+give a try to DEPs or 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 will be a present DPL: in discussions
+and as the person in charge of our 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”. Recently we
+have got better, but only 4 or 5 “bits from …” mails during a
+DPL term is just too little for a role which is meant to represent
+such a big and diverse project.</P><P>I’m sure 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 from: 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.</P><P>The resulting 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 (e.g., using a poll, which can also contain an
+option “resign, you do not communicate enough”).</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will provide a constant feed of mini-bits
+from the DPL, to be frozen and posted to </I><I><TT>d-d-a</TT></I><I> monthly.</I></DIV>
+</DIV><!--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
+<EM>is</EM> daunting. To counter that, like most past DPLs, I will be
+constantly seeking advice from others, on the basis of their project
+expertise. I do not however believe in the utility of a <B>DPL
+board</B>: the DPL term is too short to spend time with extra
+coordination hops, so I will not have a DPL board. For more specific
+task assignment we do have delegates, which is more than enough.</P><P>However, as life goes, the DPL is in this sense a single point of
+failure, and I will be looking for a <B>2IC</B> (second in charge,
+vice-leader). The duties of the 2IC will be: DPL backup (in case of
+unexpected absences), and help in communicating outside and inside the
+project (e.g., for the news feed). The 2IC will be appointed with an
+ordinary, term-limited, delegation. As the DPL, I will take full
+responsibility for 2IC actions.</P><DIV CLASS="mantra">
+<DIV CLASS="center"><I>I will not have a DPL board; I will rather look for a 2IC for
+backup and communication.</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 Clarify delegates-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc11">2.3.1</A>  Clarify delegates</H4><!--SEC END --><P>
+<A NAME="sec:delegates"></A></P><P>Remember: <A HREF="http://tinc.debian.net">there is no cabal</A>. Good
+news. Then:
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+all current
+<A HREF="http://www.debian.org/devel/constitution#8">delegates</A> (no
+matter who delegated them) should be clearly stated somewhere under
+<A HREF="http://www.debian.org/intro/organization"><TT>http://www.debian.org/intro/organization</TT></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 The <TT>www.d.o</TT> issue-->
+<H4 CLASS="subsubsection"><!--SEC ANCHOR --><A NAME="htoc12">2.3.2</A>  The <TT>www.d.o</TT> issue</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>I intend to help the WWW team in order to solve the issue 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 of
+them 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: accessibility, site structure, team work flow. Make those
+requirements public as well as a detailed plan of the work that
+needs to be done to implement them: we will not hide problems.</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, if any, 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 external bounty (i.e. nobody involved in Debian can
+take it) to realize what is missing, under the supervision of the WWW
+team. We regularly pay for services we are unable to produce by
+ourselves, the website should be no difference.</P><!--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 improved a lot, both in terms of manpower and
+communication with the project. Kudos for that go to Steve McIntyre
+and Sam Hocevar (the last two DPLs) and of course to the team
+themselves.</P><P>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 core team members are either not active anymore,
+or are very bad in communicating what they are doing. For their own
+good, they should be encouraged to find some replacement and finding
+something to work on that is more fun for them.</P><P>All these changes however should be attempted first with team
+agreement, to not bother potentially understaffed teams, which are
+very efficient in spite of that. I will start from the precious
+<A HREF="http://lists.debian.org/debian-devel-announce/2008/04/msg00014.html">team
+reviews</A> gathered by Steve McIntyre last year (with specific
+exceptions, if interviewed people do not feel like sharing the actual
+content with me) to drive re-staffing and procedural changes in order
+not to bother properly working teams.</P><!--TOC section Additional info-->
+<H2 CLASS="section"><!--SEC ANCHOR -->Additional info</H2><!--SEC END --><P>
+<A NAME="sec:extra"></A></P><!--TOC subsection Time commitment-->
+<H3 CLASS="subsection"><!--SEC ANCHOR -->Time commitment</H3><!--SEC END --><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. I’m not the only
+responsible in most of my current Debian duties and I will leave
+behind efficient teams, so I’m confident the tasks will not remain
+unattended. The remaining parts are a handful of packages which will
+need a new maintainer.</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 do that. What I offer is my Debian time, to be diverted to DPL
+tasks. Luckily though, I work at a university where I have a very
+FOSS-sensitive boss. I have the freedom to reorganize and possibly
+shrink my schedule both for emergencies, and for longer activities
+such as traveling to deliver Debian talks. Like most of us, I’m
+generally available on IRC, phone, etc.</P><!--TOC subsection Live platform-->
+<H3 CLASS="subsection"><!--SEC ANCHOR -->Live platform</H3><!--SEC END --><P>Beside rebuttals, the DPL platform is fixed once and for all at the
+end of the nomination period. While that makes perfect sense in the
+context of a vote, it makes it hard for candidates to communicate
+their positions on important topics, because of the volume of
+information the vote process generates. Hence, if noteworthy topics
+will come up during the campaigning, I will summarize my positions
+about them at
+<A HREF="http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/"><TT>http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/</TT></A>.</P><!--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">FWIW are you aware that a couple of enthusiastic DMs have
+been taking care of <TT>devscripts</TT> for several months now?
+</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 PTS face lift is that our community is
+responsive to this deficiencies of ours in Web presence. I asked
+for a new CSS layout, got several replies, and chose one of
+them. Of course 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-2009/platform.pdf b/hacking/debian/dpl-2009/platform.pdf
new file mode 100644 (file)
index 0000000..fd7722a
Binary files /dev/null and b/hacking/debian/dpl-2009/platform.pdf differ
diff --git a/hacking/debian/dpl-2009/platform.txt b/hacking/debian/dpl-2009/platform.txt
new file mode 100644 (file)
index 0000000..161acee
--- /dev/null
@@ -0,0 +1,636 @@
+                                     
+                              DPL platform
+                              ************
+                              version 0.4~1
+                             **************
+                           Stefano Zacchiroli
+                           ==================
+                           zack@debian.org (1)
+                          ====================
+                         http://upsilon.cc/~zack
+                        ========================
+  
+  [ Other formats available: .html (2), .pdf (3) .txt (4). ]
+  
+
+Executive summary
+*=*=*=*=*=*=*=*=*
+
+  
+  Hi, I’m Stefano Zacchiroli (5)—mostly known as Zack—and I’m
+running for DPL. summary The main points of my platform are as follows: 
+  
+   - I will be a present DPL: in discussions and as the person in charge
+   of our agenda.
+   - I will provide a constant feed of mini-bits from the DPL, to be
+   frozen and posted to d-d-a monthly.
+   - I will push for more gradual and rewarding access paths to Debian.
+   - I will push for mechanisms that makes rough consensus visible where
+   it exists.
+   - I will push to diminish strong package ownership whenever it
+   conflicts with package quality.
+   - I will do my best to help out, with money and other resources, to
+   support contributors get-togethers.
+   
+  The reminder of this platform provides background information about me
+(Section 1), describes the above points in mode detail (Section 2), also
+highlighting some more focused plans for my term (Section 2.3).
+  
+
+1  Introduction
+*=*=*=*=*=*=*=*
+
+   
+  
+
+1.1  Who am I
+=============
+   
+  I became a Debian Developer (DD) in March 2001, shortly after the
+current NM process was introduced. My Debian involvement has been
+through two distinct phases. In the first one I only cared about my
+packages, ignoring the community: no IRC, no -devel subscription, etc.
+Then, at LinuxTag 2004, I discovered Debian as a community and got
+fascinated by it, gradually increasing my involvement in the project.
+  Technically, my main activities during all these years have been: 
+  
+ OCaml  Better support for the OCaml (6) programming language was my
+   motivation to join the project. I’ve contributed forming the Debian
+   OCaml Task Force (7) in which I’ve ranged from the newbie, to
+   leading activities. The team nowadays maintains more than 120 source
+   packages (8) with insanely intricate inter-dependencies (9), and
+   complex transition (10) needs.
+ PTS  I’ve been co-maintaining the Package Tracking System (PTS) (11)
+   for the past 3-4 years, contributing day to day maintenance as well
+   as (12) more (13) significant (14) changes (15). Details are
+   available on my blog (16).
+ Vcs-* fields  I’ve made (17) popular (18) the notion of VCS (Version
+   Control System) related fields in debian/control, and I wrote
+   debcheckout (19).
+ QA  ...more generally, I’ve joined the QA (20) team because I enjoy
+   thinking of the project as a whole and looking for new solutions
+   (e.g. UDD (21)) to our persisting problems.
+ Packaging  Obviously, I’ve maintained (and continue to maintain)
+   several packages (22). Beside OCaml-related packages, I’m proud of
+   contributions to devscripts (23), vim (24) (in spite of my recent
+   betrayal (25) :-), and python-debian (26).
+  
+  Believing in the community as the real strength of Debian, I’m a
+regular attendee of DebConf (27) and, time permitting, of any other face
+to face meetings, like the Extremadura work ones (28).
+  In real life, I’m a computer science researcher (29), currently
+working as a post-doc in the PPS (30) laboratory, University Paris
+Diderot (31). This laboratory is somewhat of a Debian contributors nest
+of the French Debian community; our coffee breaks frequently turn into
+exciting Debian discussions.
+  I mainly work on the Mancoosi (32) project. We apply techniques such
+as formal methods to the study of FOSS distributions, including but not
+limited to Debian, and to the improvement of upgrade planning
+algorithms. Mancoosi is the successor of EDOS (33), which was the source
+of various tools used for Debian QA, like edos-debcheck (34), running
+periodically at edos.debian.net (35).
+  
+
+1.2  Why I am running
+=====================
+   
+  Being the DPL is about two distinct aspects: the institutional role
+and a set of extra goals which each prospective DPL wants to pursue
+during the term. This distinction matters.
+  The institutional role is described in our constitution (36) and is
+about three tasks: ordinary and extraordinary decision making, public
+relations with the outside world, and leading discussions inside the
+project.
+  My personal 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 irresistible tendency of turning into an imperfect
+do-ocracy: alphaenum 
+   
+   1. access restrictions get added to inhibit people doing potentially
+   dangerous actions; 
+   2. non-exciting tasks can rot because nobody is motivated enough to
+   take care of them; 
+   3. 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. 
+    The DPL has the duty, for a limited amount of time, to mitigate the
+imperfections of our do-ocracy: alphaenum 
+   
+   1. spot overly constraining access restrictions which inhibit capable
+   people to work, inducing inefficiencies and frustration; 
+   2. find people willing to do non-exciting tasks for the project’s
+   global good (making sure they get credit for it); 
+   3. assign (additional) people to key positions to improve service
+   quality inside and outside the project. 
+    The reward for this is the occasion to push for project-wide
+improvements by the only virtue of occupying the DPL position.
+  I want to challenge myself being a transparent and present DPL, and
+improving the mechanisms of our project. That is why I’m running for
+DPL. (I’ve also been asked by some of you to run, so the blame for
+bothering you in reading all this does not fall exclusively on me :-)
+  
+
+2  My goals
+*=*=*=*=*=*
+
+   
+  DPL institutional tasks deal with decision-making in situations that
+are, in general, unknown a priori. Hence, I present my goals as follows.
+
+  
+   - First I give my vision encompassing key themes of Debian
+   “politics”. This, I believe, is both a way to give a rough idea
+   of how I can react to unforeseeable scenarios, and to allow you to
+   get to better know me.
+   - Then I present the approach I intend to apply in carrying on DPL
+   institutional tasks.
+   - Finally I list the specific projects of mine I intend to pursue as
+   DPL. 
+  
+  
+
+2.1  Vision
+===========
+   
+Non-DD contributors
+   The introduction of DMs (37) (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) sub-standard packages maintained by full-fledged
+maintainers who have lost their interest in Debian. The solution to both
+is more QA, nothing else.
+  On the other hand, through the DM process, many enthusiastic people
+have found their way into our project and increased our work force.
+ (38) In addition, the DM process facilitates a more controlled process
+to becoming a full-fledged DD, with greater insurance of serious
+commitment to Debian, and experience levels. In its full generality, the
+DM process is a more fine-grained access path to Debian than what we had
+before it, which enables us to give back to our contributors gradually
+through recognition. Contributing to Debian is no longer all-or-nothing,
+it is now way less frustrating for packages, who previously might have
+turned their efforts to other projects.
+  We need to generalize the lessons learned from the DM process. We have
+a lot of potential valuable contributors out there. They just need
+better documentation about how to join and they simply demand something
+in exchange, to be proud of, that acknowledges their efforts. I do not
+have preconceptions on the different ways of achieving this (e.g., ACLs
+vs linearly increasing privileges), but we need to go in that direction.
+In doing so, we should also relax our implicit assumptions that only
+technical abilities matter in Debian. The truly “Universal Operating
+System” is mainly, not only, made of software; it is also made of
+translations, graphics, musics, etc.
+  mantra 
+    I will push for more gradual and rewarding access paths to Debian.
+    
+Collaborative maintenance
+   The introduction of the Uploaders: field is another example of a very
+fortunate development in Debian. While it can, in principle, form teams
+of people with no clear responsibility for specific tasks, on average it
+works very well. It creates efficient technical spaces for collaboration
+on specific topics, and it also scales through (re)creating
+organizational structures with specific position and task-assignments.
+  Collaborative maintenance should not be mandatory (we do have several
+very efficient one-man-band developers), but should be our default.
+Packaging newbies should start in collaborative maintenance teams and
+gain experience there. Additionally, team member feedback can be useful
+to take some of the weight off the shoulders of the AMs (Application
+Managers). Similarly, we should not accept one-man-band maintenance when
+it comes with de facto unmaintained packages (to be identified with
+suitable QA activities (39)). 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.
+  mantra 
+  I will push to diminish strong package ownership whenever it conflicts
+                         with package quality.
+    
+Vocal minorities
+   Our mailing lists have substantially improved over the last 5 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 (how
+frequent are temporary VAC messages due to this? Too much). My take: 
+    Freedom of speech: good.
+   Vocal minorities holding hostage the silent majorities: bad.
+  
+  While we should consider—and have actually applied in the
+past—moderation measures to counter repeated community disrupting
+behaviors, we cannot take the risk of applying them only on the
+assumption that the posters actually are a vocal minority. Even though
+there are no optimal solutions for this kind of problems, technical
+devices can help. One such device I want to propagate are polls (40), as
+proposed by Jeroen van Wolffelaar and other years ago. The intention is
+to enable every DD to start mail-based, authenticated polls à la
+devotee.
+  Polls can give a reasonable idea where the community stands, without
+having to engage the whole GR 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.
+  mantra 
+  I will push for mechanisms that makes rough consensus visible where it
+                                exists.
+    
+Face-to-face meetings
+   Meetings are essential to improve the quality of collaboration within
+the project, no matter how good we are in communicating digitally. Get
+together face to face, hack for hours, do stuff together, and get back
+home. The day after, your remote collaboration will be better.
+  Helping the organization of meetings is a wonderful way of spending
+Debian money or other investing resources, such as specifically
+appointed people. Luckily we do have DebConf (41), which is organized by
+a very efficient specific team. Nevertheless it 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
+economically the trips of active contributors when that will make
+possible joining others to work on specific topics.
+  A simple metric for deciding when to do that and when not, beside the
+required amount of money, can be the number x of other developers asking
+for that. If and when money will become an issue, I do not see any
+showstopper in organizing specific sponsoring campaigns.
+  mantra 
+    I will do my best to help out, with money and other resources, to
+                  support contributors get-togethers.
+    
+Derivatives
+   We are part of the FOSS ecosystem, in which patches can flow both
+downstream and upstream. We have promised (42) to give back to the free
+software community, yet sometimes we fail to do so. Initiatives like the
+recent patch tracker (43) by Sean Finney are a way to ensure that all
+our changes are visible both to down and upstream.
+  Our derived distributions (AKA derivatives) have us as theirs
+upstream, and are in a similar situation. We cannot pretend that they
+give back to us, because our promises are not necessarily theirs. On one
+hand we should strive for being exemplars in our giving back practices,
+for example by tracking our efforts of doing so. On the other hand we
+should make as easy as possible for people to give back to us, for
+example by participating in cross-distribution initiatives which make
+maintainers know each other and share distributed VCSs. Doing both will
+strengthen our give back demands that we should not stop posing.
+  
+
+2.2  DPL <-> project interaction
+================================
+   
+  
+
+2.2.1  Being present
+--------------------
+   
+  As a DD, 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/her
+presence. That comes in two forms: one is to lead discussions among
+developers, as prescribed in the constitution (44), 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 big
+picture of the project. I will also encourage seeking the DPL opinion on
+specific topics, by pinging me explicitly.
+  The DPL opinion can also be a reasonable first attempt to solve a
+conflict; if it fails, we do have other mechanisms to settle it. In this
+respect, I believe my personal qualities can be useful for the project:
+I am thoughtful, listen to others, and open to be convinced by good
+arguments.
+  More generally, managing the project agenda is something that should
+be expected from the DPL, and on which I intend to work. Managing the
+agenda means on one hand having a road map of topics the project should
+consider with in some time frame. The DiscussionsAfterLenny (45) page is
+an example of such need. The DPL should ensure the project has similar
+agendas to avoid forgetting about important topics to remember them,
+say, just before a release.
+  Management also means keeping track of what happened. The DEP
+proposal (46)—started by myself, Adeodato Simó (47), and Lars
+Wirzenius (48)—was an attempt to deliver a technical device to achieve
+that: no excessive extra burden induced, but a work flow to remember
+what is the status of “large” project-changing proposals.
+  In the long run, it is reasonable to expect the DPL to take care of
+“orphaned” DEPs by reassigning or driving them in first person. I am
+convinced that DEPs have not taken off due to the lack of some technical
+bits, and of representative examples. I will ensure that we give a try
+to DEPs or 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.
+  mantra 
+  I will be a present DPL: in discussions and as the person in charge of
+                              our agenda.
+    
+  
+
+2.2.2  Transparency
+-------------------
+   
+  Another way for a DPL to be present is to disclose periodically what
+she or he is doing; let’s call it “transparency”. Recently we have
+got better, but only 4 or 5 “bits from ...” mails during a DPL term
+is just too little for a role which is meant to represent such a big and
+diverse project.
+  I’m sure that a given number of DPL activities are not suitable for
+disclosure, whether they are personal to some, plain boring, or
+otherwise should not be archived forever on the Web. I’m also aware
+that writing from scratch a “bits from DPL” mail can be time
+consuming and possibly intimidating.
+  The solution I will implement is to have some constant feed of DPL
+activity news. “Feed” as a concept, the implementation can vary
+from: an IRC channel, blogging or micro-blogging, a wiki page
+BitsFromTheDPL handled à la DeveloperNews (49), posts to -private for
+sensitive material, etc. No feed activity will mean no DPL activity and
+the right for DDs to complain and demand explanation. I believe that
+activities which are not yet ready to be disclosed at all, not even by
+censoring or rewording details, are scarce enough not to imply empty
+feeds.
+  The resulting feed will then be frozen each month and posted to d-d-a.
+If I fail to post and freeze twice, I will admit my failure by
+explaining the reasons and seeking opinions on how to continue the term
+(e.g., using a poll, which can also contain an option “resign, you do
+not communicate enough”).
+  mantra 
+  I will provide a constant feed of mini-bits from the DPL, to be frozen
+                      and posted to d-d-a monthly.
+    
+  
+
+2.2.3  (no) DPL board
+---------------------
+   
+  According to past DPLs, carrying over the DPL burden all alone is
+daunting. To counter that, like most past DPLs, I will be constantly
+seeking advice from others, on the basis of their project expertise. I
+do not however believe in the utility of a DPL board: the DPL term is
+too short to spend time with extra coordination hops, so I will not have
+a DPL board. For more specific task assignment we do have delegates,
+which is more than enough.
+  However, as life goes, the DPL is in this sense a single point of
+failure, and I will be looking for a 2IC (second in charge,
+vice-leader). The duties of the 2IC will be: DPL backup (in case of
+unexpected absences), and help in communicating outside and inside the
+project (e.g., for the news feed). The 2IC will be appointed with an
+ordinary, term-limited, delegation. As the DPL, I will take full
+responsibility for 2IC actions.
+  mantra 
+   I will not have a DPL board; I will rather look for a 2IC for backup
+                           and communication.
+    
+  
+
+2.3  Specific plans
+===================
+   
+  
+
+2.3.1  Clarify delegates
+------------------------
+   
+  Remember: there is no cabal (50). Good news. Then: 
+  
+   1. all current delegates (51) (no matter who delegated them) should
+   be clearly stated somewhere under
+   http://www.debian.org/intro/organization with reference to the
+   delegation mail;
+   2. all people in core teams which predate widespread use of
+   delegation should be officially delegated. This will avoid
+   disparities between “young” team members who are delegates and
+   “old” team members who live in an unclear limbo. 
+  
+  
+
+2.3.2  The www.d.o issue
+------------------------
+   
+  We all want a “sexier website” (52), i.e., a website where people
+can find what they look for, and which does not make us look like Debian
+is an operating system of the 1980s. While work on the issue has been
+going on (53) in the WWW team, we have not delivered visible
+improvements yet.
+  I intend to help the WWW team in order to solve the issue 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 of them
+are meant to be performed in agreement with the WWW team. 
+  
+   1. Establish the minimal requirements for an improved website in
+   terms of: accessibility, site structure, team work flow. Make those
+   requirements public as well as a detailed plan of the work that needs
+   to be done to implement them: we will not hide problems.
+   2. Send out a call for help to our community, looking for people
+   willing to take over the job and complete it in a given time frame.
+   (Yes, I know we are all volunteers, but we do take responsibilities
+   and aim for deadlines, this issue is relevant enough to ask for
+   it.) (54)
+   3. Make sure the takers, if any, have access to the needed resources
+   and that they get credit for their attempt and, hopefully, success.
+  
+  If all this fails, we will have an emergency plan. For instance, we
+can consider an external bounty (i.e. nobody involved in Debian can take
+it) to realize what is missing, under the supervision of the WWW team.
+We regularly pay for services we are unable to produce by ourselves, the
+website should be no difference.
+  
+
+2.3.3  Core teams
+-----------------
+   
+  Our core teams have improved a lot, both in terms of manpower and
+communication with the project. Kudos for that go to Steve McIntyre and
+Sam Hocevar (the last two DPLs) and of course to the team themselves.
+  Nevertheless some teams are still short, or so it seems from the
+outside. Adding members makes a team more tolerant to absences, and also
+helps to prepare the next generation of contributors. The distinction
+between assistants and regulars in several teams seems to work very well
+in that respect.
+  My naive intention would be to bring all core teams to at least three
+members and to push for campaigning for assistants when there are no
+well-established procedures for team joining. Also, by looking at our
+organization page (55) it looks as if several core team members are
+either not active anymore, or are very bad in communicating what they
+are doing. For their own good, they should be encouraged to find some
+replacement and finding something to work on that is more fun for them.
+  All these changes however should be attempted first with team
+agreement, to not bother potentially understaffed teams, which are very
+efficient in spite of that. I will start from the precious team
+reviews (56) gathered by Steve McIntyre last year (with specific
+exceptions, if interviewed people do not feel like sharing the actual
+content with me) to drive re-staffing and procedural changes in order
+not to bother properly working teams.
+  
+
+Additional info
+*=*=*=*=*=*=*=*
+
+   
+  
+
+Time commitment
+===============
+  
+  Being DPL is challenging, for it to succeed the job must be taken
+seriously. For the duration of the mandate I will therefore put on hold
+my other Debian tasks. It is an obligation towards habitual co-workers
+and a fair deal to avoid burning out. I’m not the only responsible in
+most of my current Debian duties and I will leave behind efficient
+teams, so I’m confident the tasks will not remain unattended. The
+remaining parts are a handful of packages which will need a new
+maintainer.
+  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 do that. What I offer is my Debian time, to be diverted to DPL
+tasks. Luckily though, I work at a university where I have a very
+FOSS-sensitive boss. I have the freedom to reorganize and possibly
+shrink my schedule both for emergencies, and for longer activities such
+as traveling to deliver Debian talks. Like most of us, I’m generally
+available on IRC, phone, etc.
+  
+
+Live platform
+=============
+  
+  Beside rebuttals, the DPL platform is fixed once and for all at the
+end of the nomination period. While that makes perfect sense in the
+context of a vote, it makes it hard for candidates to communicate their
+positions on important topics, because of the volume of information the
+vote process generates. Hence, if noteworthy topics will come up during
+the campaigning, I will summarize my positions about them at
+http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/.
+  
+-----------------------------------------------------------------------
+  
+   This document was translated from LaTeX by HeVeA (57).
+-----------------------------------
+  
+  
+ (1) mailto:zack@debian.org
+ (2) http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.html
+ (3) http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.pdf
+ (4) http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/platform.txt
+ (5) http://upsilon.cc/~zack
+ (6) http://caml.inria.fr
+ (7) http://wiki.debian.org/Teams/OCamlTaskForce
+ (8) http://pkg-ocaml-maint.alioth.debian.org/debian-ocaml-status.html
+ (9) http://upsilon.cc/~zack/stuff/ocaml-debian-deps.pdf
+ (10) http://glondu.net/debian/ocaml_transition_monitor.html
+ (11) http://packages.qa.debian.org
+ (12) http://upsilon.cc/~zack/blog/posts/2008/11/PTS_SOAP_interface/
+ (13)
+   http://upsilon.cc/~zack/blog/posts/2008/08/improved_integration_among
+   _PTS_and_Lintian/
+ (14) http://upsilon.cc/~zack/blog/posts/2007/12/pts_face_lifted/
+ (15) http://upsilon.cc/~zack/blog/posts/2008/01/pts_dehs_integration/
+ (16) http://upsilon.cc/~zack/tags/qa/
+ (17) http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/
+ (18)
+   http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/
+ (19) http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/
+ (20) http://qa.debian.org/
+ (21) http://wiki.debian.org/UltimateDebianDatabase
+ (22) http://qa.debian.org/developer.php?login=zack@debian.org
+ (23) http://packages.debian.org/sid/devscripts
+ (24) http://packages.debian.org/sid/vim
+ (25)
+   http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1
+   /
+ (26) http://packages.debian.org/sid/python-debian
+ (27) http://www.debconf.org/
+ (28)
+   http://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&cont
+   ext=180&value=debian+extremadura&titlesearch=Titles
+ (29) http://upsilon.cc/~zack/research/
+ (30) http://www.pps.jussieu.fr
+ (31) http://www.univ-paris-diderot.fr
+ (32) http://www.mancoosi.org
+ (33) http://www.edos-project.org
+ (34) http://packages.debian.org/sid/edos-debcheck
+ (35) http://edos.debian.net
+ (36) http://www.debian.org/devel/constitution#5
+ (37) http://wiki.debian.org/Maintainers
+ (38) FWIW are you aware that a couple of enthusiastic DMs have been
+   taking care of devscripts for several months now?
+ (39) http://wiki.debian.org/qa.debian.org/bapase
+ (40) http://master.debian.org/~jeroen/polls/
+ (41) http://www.debconf.org
+ (42) http://www.debian.org/social_contract
+ (43) http://patch-tracking.debian.net
+ (44) http://www.debian.org/devel/constitution#5
+ (45) http://wiki.debian.org/DiscussionsAfterLenny
+ (46) http://dep.debian.net/deps/dep0/
+ (47) http://chistera.yi.org/~adeodato/blog/
+ (48) http://liw.iki.fi/liw/
+ (49) http://wiki.debian.org/DeveloperNews
+ (50) http://tinc.debian.net
+ (51) http://www.debian.org/devel/constitution#8
+ (52) http://www.debian.org/vote/2007/platforms/sho
+ (53) http://wiki.debian.org/DebianWebsiteDiscussion
+ (54) Even though it was way simpler, my experience with the PTS face
+   lift is that our community is responsive to this deficiencies of ours
+   in Web presence. I asked for a new CSS layout, got several replies,
+   and chose one of them. Of course it required some back and forth
+   round trips, but is nothing different from the usual patch work flow.
+ (55) http://www.debian.org/intro/organization
+ (56)
+   http://lists.debian.org/debian-devel-announce/2008/04/msg00014.html
+ (57) http://hevea.inria.fr/index.html