-- .~. Nicolas Bertolissio /V\ nico.bertol@free.fr // \\ /( )\ ^`~'^ Debian GNU-Linux
#use wml::debian::template title="Programme d'Anthony Towns" BARETITLE="true" NOHEADER="true"
#include "$(ENGLISHDIR)/vote/style.inc"
#use wml::debian::translation-check translation="1.4" maintainer="Nicolas Bertolissio"
<h2>Programme d'Anthony Towns</h2>
<h3>Introduction</h3>
<p>
Bonjour ! Voici mon programme !
</p>
<p>
Mes notes m'indiquent que je devrais garder cela simple, aussi vais-je juste
énumérer quelques thèmes généraux pour l'année prochaine et les choses
spécifiques sur lesquelles j'avais pensé travailler pendant cette année qui
vient. J'ai également inclus un résumé des choses qui se sont produites pendant
mon mandat de responsable du projet Debian cette année.
</p>
<p>
Hors de Debian, je suis assez impliqué dans l'équipe de <a
href="http://www.linux.org.au/";>Linux Australie</a>, et cette année je suis
également impliqué dans la planification de la <a
href="http://arjen-lentz.livejournal.com/87378.html";>conférence des
développeurs de code source ouvert</a> 2007. Globalement, je trouve cela
plutôt en symbiose avec mon implication dans Debian qu'en concurrence en terme
de charge de travail, mais avec mes projets d'étudier sérieusement les
logiciels libres de comptabilité l'année prochaine, je m'attends à devoir faire
plus attention à la répartition de mon temps que je ne l'ai fait cette année.
</p>
<p>
À cet effet, si je suis réélu, j'étendrai le concept <q>2IC</q><!-- c est quoi
? --> pour obtenir un certain nombre d'<q>assistants responsables</q> qui
auront chacun leurs propres projets et l'autorité pour les implanter, et qui
pourront répondre aux demandes d'entrevue et autres, afin de répartir la charge
de travail. J'espère que certains des autres candidats seront disposés à
considérer ce rôle si je suis réélu, et de même je serais heureux de me porter
candidat pour un tel rôle si je ne suis pas responsable du projet Debian. Dans
le meilleur des cas, j'espère que certains des autres candidats pourront
réaliser certains de leurs projets aussi bien avec ce genre de fonction, et
qu'ils en tireront en même temps une introduction plus douce au rôle de
responsable du projet Debian que nous n'en avons habituellement. De manière
idéale, je voudrais encore concourir l'année prochaine contre trois ou quatre
coresponsables du projet Debian avec lesquels j'aurai travaillé cette année,
perdre face à l'un d'entre eux, et qu'il nous invite tous de nouveau à
travailler ensemble en 2008, sous sa direction.
</p>
<p>
J'ai un <a href="http://azure.humbug.org.au/~aj/blog/";>blog<!-- on dit comment
en v.f. ? --></a>, et mes programmes de <a
href="http://www.debian.org/vote/2005/platforms/ajt";>2005</a>et de <a
href="http://www.debian.org/vote/2006/platforms/ajt";>2006</a> sont également
disponibles.
<hr />
<h3>Revue du responsable du projet Debian – avril 2006 à
février 2007</h3>
<p>
Mes buts pour l'année dernière étaient vitalité, recrutement et orientation.
En ce qui concerne la <q>vitalité</q>, je pense que l'année dernière s'est
assez bien passée. Il y a eu beaucoup de choses intéressantes qui se sont
poursuivies, qui se sont passées et qui ont progressé, et même les principales
disputes que nous avons eu ont au moins été au sujet de nouvelles choses,
plutôt qu'encore une répétition des mêmes vieilles discussions.
</p>
<p>
Notre <q>recrutement</q> n'a pas été aussi réussi que je l'aurais souhaité
— c'est toujours un processus important pour ajouter de nouveaux
développeurs, et il n'y a toujours pas assez de place pour les personnes qui
veulent contribuer mais ne peut pas s'engager à devenir un développeur complet.
Nous avons eu un certain succès en travaillant avec d'autres organismes, à la
fois par SPI et directement, mais je pense que nous pourrions faire beaucoup
mieux sur ce point également.
</p>
<p>
Nous avons eu un peu de succès en réfléchissant à la <q>direction</q> que
devait prendre Debian hors des seules élections du responsable du projet
– bien que pour en apporter la preuve il y ait eu un vote de
révocation du responsable du projet Debian, ce n'est peut-être pas un succès
dont je devrais me vanter... :)
</p>
<p>
Quoi qu'il en soit voici une idée brute de ce qui a occupé mon attention au
sujet de Debian l'année dernière, pour ce qui en vaut la peine :
</p>
<ul>
<li><b>Avril</b>
<ul>
<li>Introduction du <a
href="http://azure.humbug.org.au/~aj/blog/2006/04/12";>concept des
responsables de Debian</a> (par Marc Brockschmidt et Christoph Berg, il y
eu une présentation à la sixième conférence Debian, mais ce n'est pas
allé jusqu'à l'implantation).</li>
<li>Steve McIntyre désigné comme 2IC.</li>
<li>Debian admis comme organisation marraine du camp d'été de codage de
Google.</li>
<li>Entrevues sur <a
href="http://www.linux.com/article.pl?sid=06/04/11/1818237";>linux.com</a>
et <a
href="http://www.zdnet.com.au/news/software/soa/Towns_the_talk_of_Debian_Project/0,130061733,139251011,00.htm";>\
zdnet.com.au</a>.</li>
</ul>
<li><b>Mai</b>
<ul>
<li>Sixième conférence Debian.</li>
<li><a href="http://lists.debian.org/debian-devel-announce/2006/05/msg00009.html";>\
Parrains</a>.</li>
<li>Java de Sun dans l'archive non libre.</li>
<li><a href="http://lists.debian.org/debian-devel-announce/2006/06/msg00005.html";>\
Création de debian-publicity</a>.</li>
</ul>
<li><b>Juin</b>
<ul>
<li>Processus de sélection de la septième conférence Debian.</li>
<li>Entrevue sur <a
href="http://www.pro-linux.de/berichte/interview-towns-mcintyre-en.html";>\
pro-linux.de</a>.</li>
</ul>
<li><b>Juillet</b>
<ul>
<li>Ajout de Steve McIntyre à l'alias leader@.</li>
<li>Élections à SPI (voir par exemple <a
href="http://lists.spi-inc.org/pipermail/spi-general/2006-July/001951.html";>\
ce courriel</a>).</li>
<li><a href="http://lists.debian.org/debian-project/2006/07/msg00241.html";>\
Marques dérivées</a>.</li>
</ul>
<li><b>Août</b>
<ul>
<li>Visite au département du procureur général australien avec Rusty
Russell.</li>
<li>freedesktop.org rejoint SPI.</li>
<li>Apparition de l'ébauche d'un licence créative commune semble-t-il libre
au sens des principes du logiciel libre selon Debian.</li>
<li>Linspire lance Freespire, un dérivé communautaire.</li>
<li>HP annoncent le soutien officiel de Debian sur des machines de classe
serveur.</li>
<li>Kalle Kivimaa désigné comme auditeur de Debian.</li>
<li>Entrevue sur la <a
href="http://www.localfoss.org/node/204";>balladodiffusion
d'OSOTA</a>.</li>
</ul>
<li><b>Septembre</b>
<ul>
<li>Gallery rejoint SPI.</li>
<li>Publication de l'ébauche de GFDL<!-- c est quoi ça ? --> résolvant
d'autres préoccupations de Debian.</li>
<li>Succès de la résolution sur la gestion des capitaux.</li>
<li>Lancement de Dunc-Tank.org.</li>
<li>Entrevues sur <a
href="http://www.itwire.com.au/content/view/5684/997/";>itwire.com.au</a>
et <a
href="http://www.computerworld.com.au/index.php/id;1964607233;fp;2;fpid;1";>\
computerworld.com.au</a>.</li>
</ul>
<li><b>Octobre</b>
<ul>
<li>Résolutions sur les microprogrammes.</li>
<li>Vote de révocation.</li>
<li>Visite de Google à Mountain View pour le camp d'été de codage et <a
href="http://video.google.com/videoplay?docid=4740076597670713699";>exposé
technique sur britney</a>.</li>
</ul>
<li><b>Novembre</b>
<ul>
<li>Nouvelle équipe sur la charte.</li><!-- ? -->
<li>Annonce que Jave de Sun sera sous licence GPL.</li>
</ul>
<li><b>Décembre</b>
<ul>
<li>SPI résout son conflit avec OSI sur opensource.org.</li>
<li>ftp-master est déplacé sur ries, dinstall deux fois par jour.</li>
</ul>
<li><b>Janvier</b>
<ul>
<li>mini conférence Debian à linux.conf.au (exposé sur l'état du projet,
sur dunc-tank, et sur l'ensemble des distributions ; des vidéos sont
<a href="http://lca2007.linux.org.au/Programme";>disponibles</a>).</li>
<li>Entrevue sur <a
href="http://video.google.com/videoplay?docid=4740076597670713699";>\
computerworld (dunc-tank)</a>.</li>
</ul>
<li><b>Février</b>
<ul>
<li>Présence à <a href="http://en.wikipedia.org/wiki/Kiwi_Foo_Camp";>Kiwi
Foo</a>.</li>
<li><a
href="http://lists.debian.org/debian-project/2007/02/msg00206.html";>\
Nouvelle politique sur les marques déposées</a> passée à SPI pour
action.</li>
<li>Proposition de délégation pour les <a
href="http://lists.debian.org/debian-devel-announce/2007/02/msg00005.html";>\
rencontres</a>.</li>
<li>Envoi <a
href="http://lists.debian.org/debian-project/2007/02/msg00204.html";>des
informations et des rapports sur les délégations</a> re:
DAM/DSA/buildd/ftpmaster.</li>
</ul>
</ul>
<p>
Ce n'est pas tout à fait complet, et plusieurs de ces items ne se sont pas
limités à un seul mois de travail, mais c'est probablement utile pour avoir une
idée de ce qui a été réalisé. Évidemment il y a eu beaucoup de choses qui se
sont produites et qui ne m'ont pas impliqué de quelque façon que ce soit !
</p>
<hr />
<p>
Quoi qu'il en soit, voici pour les thèmes de cette année.
</p>
<h3>Technologie</h3>
<p>
La chose la plus importante au sujet de Debian est sa technologie – les
idées ingénieuses que nous avons mises en œuvre pour mieux faire marcher les
choses. Que ce soient les logiciels que nous avons écrit pour mieux faire
fonctionner nos paquets, ou faire notre système d'empaquetage nous-mêmes, la
modification de notre politique de licence et de celle des autres pour
encourager une boucle de retour d'expérience positive des améliorations, les
procédures et les chartes que nous avons publiées pour faciliter une
maintenance des logiciels de haute qualité, ou les structures d'organisation
que nous avons inventées pour nous permettre d'opérer en tant qu'organisation
mondiale distribuée dans un monde qui s'attend à ce que nous soyons centralisés
et isolés.
</p>
<p>
Bien sûr, la plupart des améliorations technologiques pour Debian ne font pas
(et ne doivent pas faire) participer le responsable du projet. Il y a cependant
un rôle que le responsable du projet Debian peut jouer – c'est en étant
un exemple en travaillant constamment à ses propres améliorations techniques,
et ainsi en encourageant les autres à faire de même.
</p>
<p>
J'ai fait beaucoup de choses techniques en 2005 – y compris
travailler aux pdiffs pour apt, à l'amorçage inter-architecture, à un ensemble
de débogages dont les étiquettes et les catégories utilisateurs, ainsi que les
feuilles de style, à quelques améliorations mémoire pour britney, au soutien de
l'équipe de sécurité de la distribution de test pour employer
security.debian.org sans avoir besoin de privilèges vendor-sec, à certain
travaux pour rendre les archives capables d'accepter l'architecture amd64 et à
quelques autres choses.
</p>
<p>
Depuis que j'ai été élu, je n'ai presque pas fait de chose au niveau de la
programmation ; il y a eu un certain nombre de choses pour garder
l'architecture amd64 en bon état et aider l'équipe de publication, il y a eu le
déménagement de ftp-master sur un nouveau serveur, et quelques autres mises à
jour pour l'équipe de sécurité de la distribution de test comme elle commence à
être utilisée. Je pense qu'une partie de ce que je fais à la place est
<q>technique</q> au sens significatif, y compris travailler avec SPI pour le
rendre plus efficace, impliquer Debian dans le camp d'été de codage de Google,
travailler sur les licences de marque déposée, et aider des personnes à former
des organismes et à lancer des événements au nom de Debian ; mais
finalement Debian est une organisation de <strong>logiciel</strong> libre, et
nous devons être plus visibles pour notre logiciel que pour ce qui est autour.
</p>
<p>
Donc personnellement, les travaux techniques sur lesquels je projette de
travailler au cours des mois à venir sont <a
href="http://alioth.debian.org/projects/jetring/";>jetring</a> le nouvel outil
de gestion de porte-clés de Joey Hess ; dak le kit d'archives de Debian
pour lequel j'espère que nous obtiendrons quelques bonnes améliorations pendant
le camp et la conférence Debian ; et la revue toujours attendue de de qui
concerne la gestion des publication de dunc-tank.
</p>
<p>
En plus de cela, j'espère que nous pourrons mieux souligner notre travail
technique l'année prochaine grâce à un certain nombre de choses, dont la
publication d'Etch, la charte de développement pour Lenny, des essais et une
intégration améliorés de l'assistance qualité, et tout autre travail qui doit
être fait.
</p>
<h3>Communauté</h3>
<p>
La <q>communauté</q> est probablement le principal mot à la mode pour Linux
Australie – nous essayons de maintenir nos activités concentrées sur des
activités de la communauté, que ce soit la communauté d'utilisateurs ou la
communauté de développeurs ou d'autre chose. Cela est une méthode vraiment
efficace pour nous, pour nous assurer d'accueillir correctement de nouveaux
membres, de continuer à fournir un retour d'expérience à nos membres, d'être
accessibles à toute personne impliquée dans la communauté australienne de
Linux, qu'elle soit membre ou pas, que nos activités sont centrées sur les
bénéfices de la communauté, plutôt que sur des projets importants particuliers,
<i>et cætera</i>.
</p>
<p>
J'ai essayé d'éviter de mettre la même emphase sur la communauté à l'intérieur
de Debian, parce que je suspecte qu'un bon nombre de personnes pensent à ce mot
comme n'étant rien d'autre qu'un mot à la mode ou une stratégie de vente ou
encore une tentative de réduire au silence quiconque ne serait pas d'accord
avec moi en ne se considérant <q>pas comme faisant partie de la communauté</q>.
Mais il n'y a aucun moyen de l'éviter : Debian a une énorme et vibrante
communauté, et même s'il y a des désaccords importants à travers toute cette
communauté, c'est quand même une communauté – de développeurs,
d'utilisateurs, de défenseurs, d'entreprises, de développeurs amonts, de
dérivés, de concurrents et finalement de chaque personne travaillant sur Linux
et le logiciel libre – qui rend Debian prospère. Enfin c'est quelque
chose qui mérite d'être identifié, parce que le logiciel, comme la liberté, ne
peut pas exister sans personne pour le créer ni le maintenir.
</p>
<p>
Je prévois donc de rester impliqué dans <a href="http://www.spi-inc.org/";>\
Software in the Public Interest</a> et d'aider à le faire travailler avec
d'autres organismes tels qu'OFTC, PostgreSQL et FreeDesktop.org pour construire
et maintenir des liens avec ces organismes. SPI a fait un excellent travail
pour se réorganiser récemment, et à mon avis, devrait véritablement devenir une
ressource excellente pour les groupes de logiciels libres, en fournissant
encore plus de soutient à ses projets existants, y compris Debian.
</p>
<p>
Une personne peut difficilement en faire autant, bien que, d'après quelques
commentaires récents de Martin Michlmayr, je pense qu'il est également
intéressant de nommer quelques développeurs en tant qu'<q>ambassadeurs de
Debian</q>. L'idée est qu'ils seraient des gens qui promouvraient régulièrement
Debian lors des conférences et des expositions, ou participeraient aux groupes
d'industrie ou assisteraient à des rencontres de développement en tant que
représentants de Debian, et Debian les soutiendrait en participant aux frais de
déplacement ou en s'assurant qu'ils aient des CD et autres à distribuer. Je
m'attendrais à ce que cela inclue le responsable du projet Debian et d'autres
membres de l'équipe de direction, et en tant que tel cela autoriserait des
remboursements de vols – quelque chose que je n'ai pas voulu faire
pour moi-même cette année.
</p>
<p>
Comme je <a href="http://azure.humbug.org.au/~aj/blog/2006/04/12";>l'ai écrit
l'année dernière</a>, je pense que nous devons étendre notre communauté de
développement pour permettre aux responsables qui sont actuellement parrainés
de participer plus directement. J'espère que jetring s'avérera être la
principale pièce manquante à cette proposition, mais nous verrons ce qui se
produira.
</p>
<p>
En plus cela, je pense qu'il est important de continuer à soutenir d'autres
activités basées sur la communauté, telles que des conférences locales ou
régionales de Debian, des réunions de travail, les <a
href="http://forums.debian.net/";>forums officieux des utilisateurs de
Debian</a>, ou de nouvelles initiatives comme <a
href="http://debian-community.org/";>Debian-Community.org</a> proposé par Holger
Levsen.
<h3>À faire tout simplement</h3>
<p>
Au cours de l'année dernière, et à un moindre degré depuis déjà un bon moment,
j'ai passé un certain temps à essayer d'expliquer aux gens qui se plaignent de
la manière dont Debian fonctionne ce que sont (d'après mon expérience) les
manières les plus efficaces de réaliser réellement les changements qu'ils
souhaitent voir, et à les décourager d'essayer de communiquer leurs désirs de
manières qui (à mon avis) causent plus de mal que de bien.
</p>
<p>
Autant que j'en ai vu, cela n'a eu aucun effet productif – finalement
l'attention des développeurs est une ressource limitée et précieuse et il vaut
mieux la dépenser à créer de bonnes choses et à travailler avec des personnes
productives et utiles qu'à répéter les mêmes disputes avec les mêmes personnes.
</p>
<p>
Personnellement, je vois plein de choses qui ont besoin d'être améliorées dans
Debian, et je pense qu'il sera en fin de compte mieux de passer mon temps à
travailler dessus, qu'à essayer de faire comprendre à chacun mes priorités. Il
est fort probable que cela puisse ne pas marcher, et il est possible que je ne
l'ai pas très bien expliqué – mais, et bien, c'est en gros mon
idée. ;:)
</p>
<hr />
<h2>Réfutation</h2>
<h3>Communication</h3>
<p>
Plus de communication est fréquemment proposée comme une solution à la plupart
de nos problèmes, et cela a été une question importante dans un certain nombre
d'élections passées de responsable du projet Debian – avec Martin
critiquant Bdale pour un manque de communication en 2003, et faisant de
cela un point important de son programme de réélection en 2004. De même,
Branden a fait de la communication et de la transparence l'un des principaux
sujets de son programme en 2003, 2004 et 2005. Cette année c'est une
partie des programmes respectifs de Raphaël, de Steve, de Wouter, de Sam, et de
Gustavo.
<p>
Le problème avec ceci est que communiquer est beaucoup plus dur qu'il n'y
paraît – à la fois pour établir ce qui vaut la peine d'être dit, comment
le décrire d'une manière que les gens peuvent comprendre, où et comment le
dire, comment traiter les malentendus, les mauvaises interprétations ou
simplement les désaccords, et pour laisser retomber l'énervement qui est normal
lorsqu'on parle à toute sorte d'assistance, en particulier lorsqu'elle est
large et souvent critique. Vous pouvez trouver beaucoup d'exemples de cette
difficulté – que vous regardiez la performance des responsables du projet
Debian au cours de ces dernières années pour maintenir chacun au courant de ce
qui se passe, les gens promettant de mettre à jour leurs blogs<!-- en v.f. on
dit comment ? --> plus régulièrement, ou la crainte infondée des personnes de
prendre la parole en public.
</p>
<p>
Il n'y a simplement aucune solution facile pour faire que la communication se
passe bien ; c'est un problème où vous devez constamment faire beaucoup de
petits efforts et accumuler des améliorations croissantes.
</p>
<p>
Un secteur dans lequel le projet n'est pas très bon est la reconnaissance des
efforts qui sont faits, et l'assurance que la critique est concentrée sur les
domaines qui en mérite le plus.
</p>
<p>
Par exemple, l'année dernière, il y a eu huit annonces raisonnablement
importantes concernant les annonces de sécurité de Debian, de Joey (nouvelles
listes <a
href="http://lists.debian.org/debian-devel-announce/2006/03/msg00004.html";>\
packages.d.o</a> et <a
href="http://lists.debian.org/debian-devel-announce/2006/03/msg00005.html";>\
backup.d.o</a>), de James (<a
href="http://lists.debian.org/debian-devel-announce/2006/03/msg00021.html";>\
temps d'arrêt</a> et <a
href="http://lists.debian.org/debian-devel-announce/2006/07/msg00003.html";>\
compromis</a>), de Ryan (<a
href="http://lists.debian.org/debian-devel-announce/2006/12/msg00010.html";>\
db.debian.org</a> et <a
href="http://lists.debian.org/debian-devel-announce/2007/02/msg00014.html";>\
wiki.debian.org</a>), de Joerg (<a
href="http://lists.debian.org/debian-devel-announce/2006/12/msg00011.html";>\
enchaînement sur db.debian.org</a>) et de moi-même (<a
href="http://lists.debian.org/debian-project/2007/02/msg00204.html";>délégation
de travail sur les annonces de sécurité</a>). En plus de cela, ils sont dans le
processus de discuter du problème qu'ils rencontrent à utiliser le système de
gestion des bogues pour suivre les problèmes en créant une instance temps réel
(qui au moment où j'écris est toujours dépendante de la disponibilité de
spohr.debian.org), ce qui devrait fournir une surveillance efficace des progrès
de cette équipe, à la fois publiquement pour la plupart des questions, en
interne et par le responsable du projet Debian pour les questions privées.
</p>
<p>
Cela ne signifie pas qu'il ne reste pas des améliorations à faire, ou qu'il n'y
a pas d'autres personnes qui finissent par perdre du temps parce qu'ils
n'arrivent pas à trouver ce qui ne va pas. Ce que cela montre, c'est qu'il y a
de vraies actions qui sont entreprises par des gens qui sont critiqués
continuellement pour leur manque de communication, et si nous voulons vraiment
améliorer la communication et la transparence, la première chose que nous
devons faire est de prendre l'habitude de reconnaître, d'apprécier et
d'encourager finalement la communication dont nous disponsons déjà.
</p>
<h3>Pour sympathiser</h3>
<p>
En tant que grand projet, un aspect important de notre succès est que soit en
travaillant ensemble chacun de nous réalise plus que ce qu'il pourrait faire
seul, soit nous nous marchons tellement sur les pieds que nous faisons moins
ensemble que nous ne réaliserions seul.
</p>
<p>
C'est un défi à de nombreux niveaux – mais il y a deux que je voudrais
mentionner en particulier.
</p>
<p>
<b>Équipes de direction</b>
</p>
<p>
La première chose dans une équipe de direction : il y a un tas de manières
qui ne fonctionnent pas de rassembler une équipe, que ce soit un comité perdu
dans des débats, une bureaucratie perdue dans des procédures, une hiérarchie où
seuls les bénis oui-oui se font entendre, ou quoi que ce soit d'autre. Nous
avons eu quelques exemples pratiques que cela ne fonctionne pas mieux dans
Debian – que vous considériez l'efficacité du comité technique ou du
conseil de SPI il y a quelques années, ou la capacité de l'équipe du
responsable du projet Debian en 2005 de travailler ensemble, ou les
désaccords entre Andreas et Jeroen pendant la campagne 2006 de responsable
du projet Debian, ou entre Andreas et Raphaël en 2006 ou Raphaël et Sam
cette année. Aucun d'eux n'est nécessairement un briseur d'élan, mais faire
travailler une équipe est autant une question de trouver des moyens d'éviter ce
genre de tensions et de s'assurer que votre temps passé ensemble est utile et
agréable que de trouver des choses à faire et de les faire réellement.
</p>
<p>
Il n'y a absolument rien de facile à ce sujet, et ce n'est certainement pas
quelque chose pour laquelle je vais prétendre avoir une réponse. La seule
manière de la traiter que je connaisse est de l'identifier comme un problème et
d'être préparé à la contourner si vous trouvez qu'une équipe n'arrive pas à
travailler correctement. Que Steve et moi soyons parvenus à aller plus ou moins
dans la même direction la majeure partie de l'année était non seulement une
question d'un gros effort et de coopération entre nous tout au long de l'année,
mais également pour bonne part de la chance que nous nous soyons souvent avérés
être d'accord tous les deux sur la manière dont les choses devaient se passer.
Et si les choses s'étaient trouvées différemment et si nous n'avions pas pu
travailler ensemble, pour quelque raison que ce soit, alors l'abandon de tout
le concept <q>2IC</q> était toujours sur la table : si travailler ensemble
ne s'était pas avéré amusant, nous savions tous deux comment travailler à
nouveau séparément. Je ne suis pas sûr que Raphaël dispose d'un plan de secours
semblable si son équipe de responsable du projet Debian ne réussissait pas à
travailler ensemble de la manière qu'il espère, et étant donné notre expérience
jusqu'ici, je ne pense pas que la difficulté d'obtenir une bonne équipe doive
être sous-estimée.
</p>
<p>
<b>Amis et influence</b>
</p>
<p>
Obliger des individus à travailler ensemble est un défi ; un autre est
d'obliger des groupes à travailler ensemble. Par certains côtés cela a toujours
été une partie de Debian – notre contrat social indique que nous
travaillerons à la fois avec les développeurs amonts et d'autres groupes de
logiciel libre, par exemple. D'un autre côté, c'est toujours une chose que nous
avons trouvée difficile : soit en ne coopérant pas très bien avec les
distributions dérivés, soit en nous disputant avec des développeurs amonts ou
d'autres groupes de logiciels libres, ou en ne trouvant pas les moyens de
travailler avec les entreprises qui utilisent Debian.
</p>
<p>
C'est quelque chose que j'ai essayé de faire ces dernières années, soit en
travaillant avec Sun sur leurs paquets non libres de Java, soit en faisant
participer Debian au camp d'été de codage de Google, ou en aidant les
distributions dérivés à plus s'impliquer dans Debian, ou encore en travaillant
avec SPI, ou en promouvant généralement l'idée que d'autres projets peuvent et
devraient travailler avec Debian.
</p>
<p>
Je pense qu'il y a deux raisons que je soulève ceci. La première est le
commentaire dans le programme de Sam <q>Ubuntu n'est « pas le
Diable » que dans le sens de Google</q>. Google et Ubuntu peuvent beaucoup
contribuer à Debian, et bien plus, ils contribuent déjà beaucoup à Debian.
Tandis qu'il est certainement juste d'être en désaccord avec la manière dont
ils font des choses tous deux ont des applications web
significatives pour lesquelles ils ne publient pas le code source, par
exemple ! – il est précieux de garder du respect sur ces
désaccords, de sorte que nous puissions continuer à coopérer dans les domaines
où nous sommes réellement d'accord. Demander, même occasionnellement ou pour
plaisanter, qu'un autre groupe ne suive pas ses principes de manière la plus
stricte est une excellente manière d'arrêter toutes ses contributions
potentielles pour toujours avec l'éventualité de n'obtenir aucun gain pour nos
utilisateurs ni le logiciel libre dans son ensemble.
</p>
<p>
La seconde raison qui découle de la première est que : je doute qu'il y
ait jamais un temps où <em>personne</em> dans Debian ne dira quelque chose de
pareil, soit en plaisantant soit avec le sérieux le plus complet, et pour les
personnes qui ne sont pas fortement impliquées dans Debian, faire la différence
entre une personne quelconque sur une liste montrant sa capacité à présenter
son propre avis de la manière la plus courte possible, et la voix officielle du
consensus établi de Debian peut être assez difficile. Et les listes et la
politique de Debian peuvent être suffisamment difficiles et confondantes que,
plutôt que de poser la question, de chercher un peu plus, ou même de continuer
à discuter, cela mettra souvent un terme à la discussion, et nous aurons encore
perdu un contributeur et un collaborateur potentiel.
</p>
<p>
En fin de compte, je pense que c'est là que le concept de Wouter <q>de ne pas
chercher la polémique</q> rencontre son plus grand problème – si nous
voulons être activement impliqués dans la communauté du logiciel libre autant
que possible, je pense qu'il est nécessaire que quelqu'un recherche ses
désaccords et intervienne en tant que militant pour les non-initiés, simplement
parce qu'ils ne sont pas assez familiers avec Debian pour discuter avec leurs
mots propres, et que leurs idées ne devraient pas être écartées juste parce
qu'elles semblent contredire la sagesse conventionnelle de Debian. Je pense que
faire du responsable du projet Debian cette personne, au moins de temps en
temps, est une manière utile pour le projet de montrer son appréciation des
nouvelles idées et des nouveaux contributeurs.
</p>
<hr />
<h2>Antiréfutation</h2>
<p>
J'ai décidé qu'elle était trop longue, ainsi l'ai-je postée sur <a
href="http://lists.debian.org/debian-vote/2007/03/msg00262.html";>debian-vote</a>
à la place.
</p>
<hr />
<p>
Merci de m'avoir lu !
</p>
Attachment:
signature.asc
Description: Digital signature