platform v0.4
authorStefano Zacchiroli <zack@upsilon.cc>
Sun, 8 Mar 2009 11:56:54 +0000 (12:56 +0100)
committerStefano Zacchiroli <zack@upsilon.cc>
Sun, 8 Mar 2009 11:56:54 +0000 (12:56 +0100)
hacking/debian/dpl-2009/platform.html
hacking/debian/dpl-2009/platform.pdf
hacking/debian/dpl-2009/platform.txt

index df8f572..237523b 100644 (file)
@@ -3,7 +3,7 @@
 <HTML>
 <HEAD>
 <TITLE>DPL platform 
- version 0.4~1
+ version 0.4
 </TITLE>
 
 <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
@@ -83,7 +83,7 @@ a:hover{text-decoration: underline;}
 <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>
+ version <TT>0.4</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:
@@ -130,18 +130,19 @@ intricate inter-dependencies</A>, and complex
 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>
+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/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
+the notion of VCS (Version Control System) 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
+<A HREF="http://qa.debian.org/">QA</A> (Quality Assurance) 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
@@ -162,18 +163,19 @@ science researcher</A>, currently working as a post-doc in the
 <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
+exciting Debian discussions. 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 HREF="http://edos.debian.net"><TT>edos.debian.net</TT></A>.</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 a set of extra goals which each prospective DPL wants to pursue
-during the term. This distinction matters.</P><P>The institutional role is
+and a set of extra goals the 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
@@ -201,16 +203,16 @@ 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><LI CLASS="li-enumerate">assign 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-->
+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. (Actually, 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
@@ -220,8 +222,7 @@ 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.
+on DPL institutional tasks.</LI><LI CLASS="li-itemize">Finally I list some specific projects 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-->
@@ -234,17 +235,17 @@ 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
+<SUP><A NAME="text1" HREF="#note1">1</A></SUP> In addition, the
+DM process facilitates a <EM>more controlled process</EM> to become a
+full-fledged DD, with greater insurance of serious commitment to
+Debian, and experience levels. 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 packagers, 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
+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
@@ -258,16 +259,16 @@ 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
+a 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
+teams and gain experience there. Team member feedback can then 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
@@ -292,15 +293,16 @@ 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
+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
 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">
+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 push for mechanisms that makes
 rough consensus visible where it exists.</I></DIV>
 </DIV><!--TOC paragraph Face-to-face meetings-->
@@ -324,7 +326,7 @@ not see any showstopper in organizing specific sponsoring campaigns.</P><DIV CLA
 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
+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
@@ -334,36 +336,37 @@ 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-->
+theirs, still we should:
+</P><OL CLASS="enumerate" type=1><LI CLASS="li-enumerate">
+be exemplar in our giving back practices, for example by
+tracking publicly our efforts in sending patches upstream;</LI><LI CLASS="li-enumerate">make as easy as possible to give back to us, for example by
+participating in cross-distribution initiatives which make
+maintainers know each other and share distributed VCSs.
+</LI></OL><P>
+Doing both will strengthen our give back <EM>requests</EM> to
+derivatives 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
+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 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
+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>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
+should be expected from the DPL. Managing the agenda means 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
@@ -371,15 +374,15 @@ them, say, just before a release.</P><P>Management also means keeping track of w
 <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">
+deliver a 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>We should expect the DPL to take care of “orphaned” DEPs by
+reassigning or driving them in first person. 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-->
@@ -387,14 +390,14 @@ and as the person in charge of our agenda.</I></DIV>
 <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
+DPL term is still 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
+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
@@ -411,12 +414,12 @@ from the DPL, to be frozen and posted to </I><I><TT>d-d-a</TT></I><I> monthly.</
 </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
+<EM>is</EM> daunting. To counter that, 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
@@ -433,8 +436,8 @@ backup and communication.</I></DIV>
 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/devel/constitution#8">delegates</A> should
+be clearly stated 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
@@ -443,20 +446,21 @@ disparities between “young” team members who are delegates and
 </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://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.
+on</A> in the WWW team, we have not delivered visible improvements yet.</P><P>I intend to help the WWW team in order to solve the main issues within
+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: 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
+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
@@ -468,10 +472,10 @@ 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
+<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 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
@@ -479,35 +483,35 @@ work very well in that respect.</P><P>My naive intention would be to bring all c
 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
+looks as if several teams are either not active anymore, or are very
+bad in communicating what they are doing. For their own good, involved
+people should be encouraged to replacement and 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 yet very efficient
+teams. 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-->
+reviews</A> gathered by Steve McIntyre last year<SUP><A NAME="text3" HREF="#note3">3</A></SUP> 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
+<H3 CLASS="subsection"><!--SEC ANCHOR -->Time commitment</H3><!--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
+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
+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 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
+cannot grant 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
+<H3 CLASS="subsection"><!--SEC ANCHOR -->Live platform</H3><!--SEC END --><P>
+<A NAME="sec:live-platform"></A></P><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
@@ -516,14 +520,19 @@ 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.
+<A NAME="note1" HREF="#text1">1</A></DT><DD CLASS="dd-thefootnotes">FWIW are you aware that 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">FWIW, 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> is 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. Of course it required
+some back and forth round trips, but is nothing different from the
+usual patch work flow.
+</DD><DT CLASS="dt-thefootnotes"><A NAME="note3" HREF="#text3">3</A></DT><DD CLASS="dd-thefootnotes">with specific
+exceptions, if interviewed people do not feel like sharing the
+actual content with me
 </DD></DL>
 <!--END NOTES-->
 <!--CUT END -->
index fd7722a..4432b51 100644 (file)
Binary files a/hacking/debian/dpl-2009/platform.pdf and b/hacking/debian/dpl-2009/platform.pdf differ
index 161acee..8b6568a 100644 (file)
@@ -2,8 +2,8 @@
                                      
                               DPL platform
                               ************
-                              version 0.4~1
-                             **************
+                               version 0.4
+                              ************
                            Stefano Zacchiroli
                            ==================
                            zack@debian.org (1)
@@ -64,45 +64,44 @@ fascinated by it, gradually increasing my involvement in the project.
  
  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).
+   as more (12) significant (13) changes (14). Details are available on
+   my blog (15).
  
- 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).
+ Vcs-* fields  I’ve made (16) popular (17) the notion of VCS (Version
+   Control System) fields in debian/control, and I wrote
+   debcheckout (18).
  
- 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.
+ QA  ...more generally, I’ve joined the QA (19) (Quality Assurance)
+   team because I enjoy thinking of the project as a whole and looking
+   for new solutions (e.g. UDD (20)) 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).
+   several packages (21). Beside OCaml-related packages, I’m proud of
+   contributions to devscripts (22), vim (23) (in spite of my recent
+   betrayal (24) :-), and python-debian (25).
   
   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
+regular attendee of DebConf (26) and, time permitting, of any other face
+to face meetings, like the Extremadura work ones (27).
+  In real life, I’m a computer science researcher (28), currently
+working as a post-doc in the PPS (29) laboratory, University Paris
+Diderot (30). 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).
+exciting Debian discussions. I mainly work on the Mancoosi (31) 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 (32), which was the source of various tools used for Debian QA,
+like edos-debcheck (33), running periodically at edos.debian.net (34).
   
 
-1.2  Why I am running
-=====================
+1.2  Why I am running for DPL
+=============================
    
   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
+and a set of extra goals the prospective DPL wants to pursue during the
+term. This distinction matters.
+  The institutional role is described in our constitution (35) and is
 about three tasks: ordinary and extraordinary decision making, public
 relations with the outside world, and leading discussions inside the
 project.
@@ -126,14 +125,15 @@ imperfections of our do-ocracy: alphaenum
    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. 
+   3. assign 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 :-)
+  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. (Actually, 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
@@ -152,8 +152,7 @@ are, in general, unknown a priori. Hence, I present my goals as follows.
    - 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. 
+   - Finally I list some specific projects I intend to pursue as DPL. 
   
   
 
@@ -161,7 +160,7 @@ are, in general, unknown a priori. Hence, I present my goals as follows.
 ===========
    
 Non-DD contributors
-   The introduction of DMs (37) (Debian Maintainers) has been a
+   The introduction of DMs (36) (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
@@ -169,21 +168,21 @@ 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.
+ (37) In addition, the DM process facilitates a more controlled process
+to become a full-fledged DD, with greater insurance of serious
+commitment to Debian, and experience levels. 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 packagers, 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
+better documentation about how 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 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.
@@ -191,7 +190,7 @@ translations, graphics, musics, etc.
     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
+   The introduction of the Uploaders: field is another example of a
 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
@@ -200,13 +199,13 @@ 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.
+gain experience there. Team member feedback can then 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 (38)). 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.
@@ -226,15 +225,16 @@ 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
+devices can help. One such device I want to put into use are polls (39),
+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.
+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.
   mantra 
   I will push for mechanisms that makes rough consensus visible where it
                                 exists.
@@ -246,7 +246,7 @@ 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
+appointed people. Luckily we do have DebConf (40), 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
@@ -261,20 +261,24 @@ showstopper in organizing specific sponsoring campaigns.
                   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
+   We are part of the FOSS ecosystem, in which patches flow both
+downstream and upstream. We have promised (41) 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
+recent patch tracker (42) 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.
+give back to us, because our promises are not necessarily theirs, still
+we should: 
+  
+   1. be exemplar in our giving back practices, for example by tracking
+   publicly our efforts in sending patches upstream;
+   2. make as easy as possible to give back to us, for example by
+   participating in cross-distribution initiatives which make
+   maintainers know each other and share distributed VCSs. 
+   Doing both will strengthen our give back requests to derivatives that
+we should not stop posing.
   
 
 2.2  DPL <-> project interaction
@@ -287,38 +291,37 @@ strengthen our give back demands that we should not stop posing.
    
   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
+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 lead discussions among
-developers, as prescribed in the constitution (44), something I have
+developers, as prescribed in the constitution (43), 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.
+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.
   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.
+be expected from the DPL. Managing the agenda means having a road map of
+topics the project should consider with in some time frame. The
+DiscussionsAfterLenny (44) 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.
+proposal (45)—started by myself, Adeodato Simó (46), and Lars
+Wirzenius (47)—was an attempt to deliver a device to achieve that: no
+excessive extra burden induced, but a work flow to remember what is the
+status of “large” project-changing proposals.
+  We should expect the DPL to take care of “orphaned” DEPs by
+reassigning or driving them in first person. 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.
@@ -331,22 +334,21 @@ decisions which too often resemble no decisions at all.
   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.
+is still 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.
+activity news. “Feed” as a concept, the implementation can vary: an
+IRC channel, blogging or micro-blogging, a wiki page BitsFromTheDPL
+handled à la DeveloperNews (48), 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
@@ -362,12 +364,12 @@ not communicate enough”).
 ---------------------
    
   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.
+daunting. To counter that, 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
@@ -389,10 +391,9 @@ responsibility for 2IC actions.
 2.3.1  Clarify delegates
 ------------------------
    
-  Remember: there is no cabal (50). Good news. Then: 
+  Remember: there is no cabal (49). Good news. Then: 
   
-   1. all current delegates (51) (no matter who delegated them) should
-   be clearly stated somewhere under
+   1. all current delegates (50) should be clearly stated under
    http://www.debian.org/intro/organization with reference to the
    delegation mail;
  
@@ -406,15 +407,14 @@ responsibility for 2IC actions.
 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. 
+  We all want a sexier website (51), 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 (52) in the WWW team, we have not delivered visible improvements yet.
+  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. 
   
    1. Establish the minimal requirements for an improved website in
    terms of: accessibility, site structure, team work flow. Make those
@@ -425,7 +425,7 @@ are meant to be performed in agreement with the WWW team.
    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)
+   it.) (53)
  
    3. Make sure the takers, if any, have access to the needed resources
    and that they get credit for their attempt and, hopefully, success.
@@ -440,28 +440,25 @@ 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.
+  Our core teams have recently improved a lot, in terms of manpower and
+communication. 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.
+organization page (55) it looks as if several teams are either not
+active anymore, or are very bad in communicating what they are doing.
+For their own good, involved people should be encouraged to replacement
+and 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.
+agreement, to not bother potentially understaffed yet very efficient
+teams. I will start from the precious team reviews (56) gathered by
+Steve McIntyre last year (57) to drive re-staffing and procedural
+changes in order not to bother properly working teams.
   
 
 Additional info
@@ -472,18 +469,18 @@ 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
+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 new
-maintainer.
+remaining parts are a handful of packages which will need new
+maintainers.
   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
+cannot grant 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
@@ -493,7 +490,7 @@ 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
@@ -504,7 +501,7 @@ http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/.
   
 -----------------------------------------------------------------------
   
-   This document was translated from LaTeX by HeVeA (57).
+   This document was translated from LaTeX by HeVeA (58).
 -----------------------------------
   
   
@@ -536,101 +533,105 @@ http://www.upsilon.cc/~zack/hacking/debian/dpl-2009/.
    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/
+ (14) http://upsilon.cc/~zack/blog/posts/2008/01/pts_dehs_integration/
  
- (16) http://upsilon.cc/~zack/tags/qa/
+ (15) http://upsilon.cc/~zack/tags/qa/
  
- (17) http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/
+ (16) http://upsilon.cc/~zack/blog/posts/2006/09/xs-x-vcs-XXX/
  
- (18)
+ (17)
    http://upsilon.cc/~zack/blog/posts/2006/10/xs-vcs-XXX_almost_there/
  
- (19) http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/
+ (18) http://upsilon.cc/~zack/blog/posts/2007/08/debcheckout/
  
- (20) http://qa.debian.org/
+ (19) http://qa.debian.org/
  
- (21) http://wiki.debian.org/UltimateDebianDatabase
+ (20) http://wiki.debian.org/UltimateDebianDatabase
  
- (22) http://qa.debian.org/developer.php?login=zack@debian.org
+ (21) http://qa.debian.org/developer.php?login=zack@debian.org
  
- (23) http://packages.debian.org/sid/devscripts
+ (22) http://packages.debian.org/sid/devscripts
  
- (24) http://packages.debian.org/sid/vim
+ (23) http://packages.debian.org/sid/vim
  
- (25)
+ (24)
    http://upsilon.cc/~zack/blog/posts/2008/10/from_Vim_to_Emacs_-_part_1
    /
  
- (26) http://packages.debian.org/sid/python-debian
+ (25) http://packages.debian.org/sid/python-debian
  
- (27) http://www.debconf.org/
+ (26) http://www.debconf.org/
  
- (28)
+ (27)
    http://wiki.debian.org/DebianQAExtremadura2008?action=fullsearch&cont
    ext=180&value=debian+extremadura&titlesearch=Titles
  
- (29) http://upsilon.cc/~zack/research/
+ (28) http://upsilon.cc/~zack/research/
  
- (30) http://www.pps.jussieu.fr
+ (29) http://www.pps.jussieu.fr
  
- (31) http://www.univ-paris-diderot.fr
+ (30) http://www.univ-paris-diderot.fr
  
- (32) http://www.mancoosi.org
+ (31) http://www.mancoosi.org
  
- (33) http://www.edos-project.org
+ (32) http://www.edos-project.org
  
- (34) http://packages.debian.org/sid/edos-debcheck
+ (33) http://packages.debian.org/sid/edos-debcheck
  
- (35) http://edos.debian.net
+ (34) http://edos.debian.net
  
- (36) http://www.debian.org/devel/constitution#5
+ (35) http://www.debian.org/devel/constitution#5
  
- (37) http://wiki.debian.org/Maintainers
+ (36) 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?
+ (37) FWIW are you aware that enthusiastic DMs have been taking care of
+   devscripts for several months now?
  
- (39) http://wiki.debian.org/qa.debian.org/bapase
+ (38) http://wiki.debian.org/qa.debian.org/bapase
  
- (40) http://master.debian.org/~jeroen/polls/
+ (39) http://master.debian.org/~jeroen/polls/
  
- (41) http://www.debconf.org
+ (40) http://www.debconf.org
  
- (42) http://www.debian.org/social_contract
+ (41) http://www.debian.org/social_contract
  
- (43) http://patch-tracking.debian.net
+ (42) http://patch-tracking.debian.net
  
- (44) http://www.debian.org/devel/constitution#5
+ (43) http://www.debian.org/devel/constitution#5
  
- (45) http://wiki.debian.org/DiscussionsAfterLenny
+ (44) http://wiki.debian.org/DiscussionsAfterLenny
  
- (46) http://dep.debian.net/deps/dep0/
+ (45) http://dep.debian.net/deps/dep0/
  
- (47) http://chistera.yi.org/~adeodato/blog/
+ (46) http://chistera.yi.org/~adeodato/blog/
  
- (48) http://liw.iki.fi/liw/
+ (47) http://liw.iki.fi/liw/
  
- (49) http://wiki.debian.org/DeveloperNews
+ (48) http://wiki.debian.org/DeveloperNews
  
- (50) http://tinc.debian.net
+ (49) http://tinc.debian.net
  
- (51) http://www.debian.org/devel/constitution#8
+ (50) http://www.debian.org/devel/constitution#8
  
- (52) http://www.debian.org/vote/2007/platforms/sho
+ (51) http://www.debian.org/vote/2007/platforms/sho
  
- (53) http://wiki.debian.org/DebianWebsiteDiscussion
+ (52) 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.
+ (53) FWIW, even though it was way simpler, my experience with the PTS
+   face lift (54) is 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. Of course it required some
+   back and forth round trips, but is nothing different from the usual
+   patch work flow.
+ (54) http://upsilon.cc/~zack/blog/posts/2007/12/pts_face_lifted/
  
  (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
+ (57) with specific exceptions, if interviewed people do not feel like
+   sharing the actual content with me
+ (58) http://hevea.inria.fr/index.html