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