-- .~. Nicolas Bertolissio /V\ [EMAIL PROTECTED] // \\ /( )\ ^`~'^ Debian GNU-Linux
#use wml::debian::template title="Programme de Steve McIntyre" BARETITLE="true" NOHEADER="true" #include "$(ENGLISHDIR)/vote/style.inc" #use wml::debian::translation-check translation="1.5" maintainer="Nicolas Bertolissio"
<h1>Programme de Steve McIntyre pour l'élection au poste de responsable du projet Debian, année 2007</h1>
<h2>Introduction</h2>
<p>
Je suis développeur Debian depuis octobre 1996. Je le suis devenu, au
début, pour maintenir la version Debian de mikmod ; j'étais le développeur
amont à ce moment-là et je souhaitais que la version Debian fonctionne aussi
correctement. En ce temps-là, le processus du nouveau responsable de paquets
était bien plus simple qu'aujourd'hui : j'ai installé Debian, puis, deux
jours plus tard, j'ai envoyé un courriel à Bruce Perens avec une clef PGP et je
lui ai demandé un compte Debian. Il m'a répondu presque immédiatement avec les
données du compte – et j'étais rentré !
</p>
<p>
Depuis lors, j'ai travaillé sur un certain nombre de paquets, certains
importants, d'autre petits. Le travail le plus remarquable que j'ai
probablement réalisé pour Debian est avec l'équipe des CD-ROM, à la fois en
développant le logiciel debian-cd lui-même et en l'utilisant pour créer les CD
officiels (et maintenant les DVD) qui accompagnent chaque publication de
Debian. Je me suis impliqué dans ces CD à presque chaque version majeure et
chaque mise à jour depuis Hamm.
</p>
<p>
Je me suis porté candidat à l'élection du responsable du projet Debian l'année
dernière, et je suis arrivé deuxième derrière AJ. Peu après l'élection, il m'a
contacté et m'a invité à accepter un nouveau rôle de délégué Debian pour
« I2C », comme assistant du responsable du projet. J'ai accepté, et
depuis je l'aide sur certaines fonctions du responsable du projet Debian
– en traitant des lettres, en représentant Debian devant la presse
et lors de divers rassemblements pour le logiciel libre et en agissant comme
médiateur dans certains débats. Cela m'a donné un bon aperçu du travail du
responsable du projet Debian : ce que cela entraîne et combien de temps
cela prend.
</p>
<h2>Buts</h2>
<p>
La plus grand partie de ce programme vous sera familière, car il est largement
basé sur ce que je disais l'année dernière à cette période-ci. La plupart des
choses sur lesquelles je souhaite travailler dans Debian n'ont pas changé
depuis : ce sont des problèmes bien connus, des questions qui nous
touchent depuis longtemps.
</p>
<h3>Communication à l'intérieur du projet</h3>
<p>
C'est l'Arlésienne ; les candidats au poste de responsable du projet
Debian promettent de travailler à améliorer la communication au sein du projet
depuis aussi longtemps que je me souvienne. Il y a plusieurs endroits où la
communication a posé des problèmes par le passé. Parfois les efforts du
responsable du projet ont aidé à arranger les choses, mais le plus souvent il
n'y avait aucune amélioration visible.
</p>
<p>
Des mises à jour courtes et régulières de l'état d'avancement des diverses
équipes du projet peuvent apporter beaucoup d'amélioration. De la même manière,
des comptes-rendus réguliers du responsable du projet Debian sont nécessaires
pour s'assurer que la communauté Debian est consciente de ce qui se dit et de
ce qui est fait en son nom. Même si certains de ces comptes-rendus ne
consistent qu'en simples « Désolé, j'étais trop occupé dans la vie réelle
et je n'ai pas avancé », un accusé réception montrant que les messages ne
restent pas sans réponse est mieux que rien du tout. Je vise à encourager ces
mises à jour, et si je suis élu j'enverrai des nouvelles régulières du
responsables du projet Debian.
</p>
<h3>Apprentissage et nouveau responsable de paquets</h3>
<p>
Actuellement le processus du nouveau responsable de paquets contient des tests
détaillés sur les capacités techniques des candidats, et bien sûr c'est quelque
chose de bon et d'utile. Malheureusement, nous ne sélectionnons pas sur les
compétences sociales ; nous avons besoin de travailler ensemble comme une
communauté !
</p>
<p>
On demande souvent aux nouveaux responsables de paquets de montrer leurs
compétences en construisant de nouveaux paquets où en reprenant un paquet
abandonné. C'est utile pour tester les compétences d'empaquetage, mais cela peut
conduire à faire travailler les nouveaux responsables de paquets sur des
logiciels pour lesquels ils n'ont pas de réel intérêt – pour aller
plus loin, il y a de grandes chances que ces paquets soient à nouveau
abandonnés.
</p>
<p>
J'aimerais suggérer qu'une plus grande partie de l'entraînement des nouveaux
responsables de paquets devrait plus se réaliser en équipe. Nous avons un grand
nombre de paquets pour lesquels les responsables pourraient accepter de l'aide,
et un grand nombre de nouveaux responsables de paquets qui recherchent du
travail. Je crois que c'est un domaine dans lequel nous pouvons beaucoup nous
améliorer. Nous avons besoin de responsables de paquets compréhensifs pour
faire ce travail – ils seraient responsables du travail réalisé,
puis devraient faire un compte-rendu aux responsables de candidature concernés.
Je me suis déjà porté volontaire pour cet effort avec certains de mes paquets,
et je souhaiterais encourager d'autres développeurs Debian à faire de même.
</p>
<p>
Nous avons également besoin de trouver comment traiter plus efficacement les
nombreux types différents de contributeurs que nous avons désormais. En plus
des responsables de paquets, nous disposons de plus en plus de gens qui
travaillent sur d'autres domaines importants comme les traductions. Il y a un
certain temps, nous avons eu un bon débat à ce sujet et nous devons régler
cette question.
</p>
<h3>Ouverture au sein du projet</h3>
<p>
Nous promettons d'être aussi ouverts que possible, mais nous échouons souvent
sur ce front. C'est parfois nécessaire (par exemple lors des débats à huis clôt
sur les mises à jour de sécurité), mais la plupart du temps ça ne l'est pas.
Parfois des débats sont privés alors qu'ils ne devraient pas l'être, et ce
n'est pas une bonne chose pour nous. Parfois du travail technique est réalisé
au sein de nos diverses équipes et, lorsqu'il est présenté à une audience plus
large, il reçoit des accusations d'avoir été fait en secret.
</p>
<p>
Malheureusement, il n'y a aucune potion magique pour améliorer cette
situation. Je crois qu'un des principaux points de blocage est l'agressivité
qui est souvent montrée sur nos forums de développement, et il faut couper
court à cela d'abord. Une fois que nous disposerons d'une atmosphère de
discussion plus sereine, des discussions plus ouvertes arriverons
naturellement.
</p>
<h3>Standards techniques</h3>
<p>
Dans notre grand dépôt de logiciels, nous avons un très grand nombre de paquets
et de responsables. La plupart du travail dans Debian est très bien fait, mais
malheureusement pas totalement. Beaucoup de choses ont été dites dans le passé
sur nos développeurs qui sont des volontaires et qu'on ne peut pas forcer à
travailler sur ce qu'ils ne veulent pas faire. Cela peut excuser les gens qui
travaillent peu sur leurs paquets, mais cela n'excuse <strong>pas</strong> une
partie du manque de soin qui arrive de temps en temps, par exemple les paquets
qui ne se construisent pas sur un système propre.
</p>
<p>
Nous avons un nombre grandissant d'outils que les responsables de paquets
peuvent utiliser pour vérifier la qualité de leurs paquets (linda, lintian et
désormais piuparts). Nous avons construits des outils qui peuvent réduire les
risques de dépendances cassées et d'autres problèmes lors de la construction
(sbuild, pbuilder, etc.). Cependant nous avons toujours des paquets cassés ou
de faible qualité qui sont téléchargés régulièrement.
</p>
<p>
Je peux voir deux problèmes ici. Certains de nos responsables de paquets ne
sont pas au courant des mises à jours qui ont été faites sur nos outils et nos
procédures. Certains d'entre nous ne ressentent pas la nécessité d'utiliser ces
nouveaux outils et méthodes. Chacun de ces problèmes devrait pouvoir être
résolu : il faudrait plus de documentation sur les meilleures pratique
d'empaquetage et les méthodes de test, à la fois en décrivant ce qui est
disponible et quel en est l'intérêt.
</p>
<h3>Travailler efficacement ; demander de l'aide</h3>
<p>
En poursuivant sur le point précédent : une autre partie du travail de
développeur Debian est de travailler efficacement, à la fois sur ses propres
paquets et au sein du projet dans son ensemble. Cela comprend des choses
simples comme la gestion des bogues de ses paquets de manière ponctuelle, mais
aussi des choses plus complexes, comme le prise en compte de l'impact de
modifications sur le calendrier des publications. Travailler efficacement n'est
pas important seulement pour sa propre satisfaction ; cela a aussi un
impact majeur sur le temps qu'il nous faut pour publier les versions et
le ressenti des utilisateurs de Debian.
</p>
<p>
À mon avis, la clef du travail efficace est l'honnêteté. Nous pouvons tous
manquer de temps pour faire le travail que nous avions promis. Après tout, la
vie réelle a la fâcheuse habitude de s'introduire dans notre temps
« perdu ». Tant que nous ne laissons pas les choses prendre trop de
délai, nous pouvons tenir le coup et continuer à contribuer. Mais à un moment,
nous avons besoin d'être plus honnêtes avec nous-mêmes et admettre vraiment
que nous ne pouvons plus continuer à faire le travail promis. C'est difficile à
faire, mais dans une communauté conviviale où nous travaillons tous ensemble
pour un but commun, il ne devrait y avoir <strong>aucune</strong> honte à
demander de l'aide.
</p>
<p>
De manière plus générale, des procédures existent pour que les développeurs
Debian quittent temporairement le projet si la vie réelle les accapare, puis
le joignent à nouveau lors leur situation change. Encore une fois, il n'y a
aucune honte à faire cela – nous devrions nous réjouir de
reconnaître toutes les contributions des gens qui ont contribué au logiciel
libre lorsqu'ils le pouvaient. Mais, il y a toujours beaucoup de gens qui ne
prennent pas ce chemin et au lieu de cela disparaissent simplement. Retrouver
les développeurs Debian qui ont simplement laissé tomber le projet peut prendre
un certain temps.
</p>
<h2>Pourquoi voter pour moi ?</h2>
<p>
Nous avons un grand nombre de candidats cette année, ce qui peut rendre le
choix difficile pour nos développeurs. Je crois que je peux réaliser du bon
travail en tant que responsable du projet Debian grâce aux qualités
suivantes :
</p>
<ul>
<li><strong>Expérience :</strong> Je suis développeur au sein de Debian
depuis plus de dix années. J'ai fait beaucoup de travail d'empaquetage,
j'ai vu Debian évoluer beaucoup dans ce laps de temps, et je me suis
impliqué dans de nombreux débats différents. En ayant travaillé comme 2IC,
cela signifie que je connais déjà ce que le travail de responsable du
projet Debian entraîne, et je suis heureux de pouvoir faire ce
travail.</li>
<li><strong>Organisation :</strong> En plus de l'empaquetage, j'ai fait
beaucoup de travail de promotion pour Debian. J'ai organisé des stands
Debian lors de nombreuses expositions et manifestations ces dernières
années, et je gère la liste de diffusion debian-uk. Ces deux choses
permettent d'être conscient de ce qu'est Debian et de ses buts. Je suis
également le trésorier actuel de la <em>Debian UK Society</em>. J'ai aussi
une bonne expérience du « grégarisme », y compris de
l'organisation de voyages pour les groupes pour les conférences Debian, le
FOSDEM ou d'autres événements. J'ai aussi mené certains travaux lors de la
septième conférence Debian, en particulier sur le parrainage et les
finances.</li>
<li><strong>Social :</strong> Je suis un programmeur, ce qui signifie
que j'ai des avis tranchés sur de nombreux sujets (sourire). Malgré cela,
je crois être honnête, généralement abordable et qu'il est facile de
travailler avec moi. Je suis un bon communicateur et négociateur, et je
me suis fait de nombreux amis dans la communauté Debian et plus largement
celle du logiciel libre ces dernières années.</li>
</ul>
<h2>Résumé</h2>
<p>
J'ai abordé ici certains problèmes qui ne sont heureusement pas surprenants
pour la plus grande partie de notre communauté. Je dois reconnaître également
le fait que le responsable du projet Debian n'a pas le pouvoir d'imposer
facilement les changements comme il les voit. Le mieux qu'il puisse faire est
de nous encourager à nous améliorer, parfois par des discussions et des débats
et parfois en donnant l'exemple. Je ne prétends pas être parfait, mais je crois
que je peux nous aider à atteindre certains des buts que j'ai listés ici.
</p>
<p>
Merci d'avoir pris le temps de lire mon programme.
</p>
<h2>Réfutation</h2>
<p>
Tous d'abord, je voudrais dire que cette année (encore) je crois que nous avons
une sélection de bons candidats. C'est l'un des aspects de l'élection du
responsable du projet Debian que je j'aime le moins, car je ne crois pas avoir
d'opinion négative sur les autres candidats. Néanmoins, je dois faire un
effort. J'aimerais être responsable du projet Debian (évidemment, sinon je
n'aurais pas été candidat !) mais je serai aussi heureux de voir
<strong>toute</strong> personne compétente élue. Beaucoup d'idées se recoupent
à ce que je peux voir. Voici ce que je pense des autres candidats et de leurs
programmes :
</p>
<h3>Wouter Verhelst</h3>
<p>
Wouter est un développeur Debian connu et expérimenté que je considère comme un
ami. Nous nous sommes rencontrés de nombreuses fois, en particulier lors de
conférences Debian et de FOSDEM. Il dit vouloir améliorer le noyau social de
Debian, je suis d'accord avec cela et je lui souhaite beaucoup de chance sur ce
point.
</p>
<h3>Aigars Mahinovs</h3>
<p>
Aigars est un candidat peu connu, sans point précis lié à Debian qui me vienne à
l'esprit. Je dois reconnaître que son idée sur les publications, un tronc de
distribution et le processus des anciens responsables ne me disent rien. Sur la
réforme des fichiers de configuration, je pense qu'il a des idées
intéressantes, mais je ne vois pas cela comme relevant du travail du
responsable du projet Debian du tout. Pour que ce soit noté, je suis totalement
d'accord avec lui au sujet des marques déposées. Toute l'idée qui est derrière
les marques déposées est un gâchis !
</p>
<h3>Gustavo Franco</h3>
<p>
Gustavo a listé dans son programme une quantité <strong>colossale</strong> de
buts, couvrant le moindre domaine de Debian que je connaisse : les
publications, les équipes principales, le système de gestion des bogues, le
processus du nouveau responsable, de nouveaux processus et bien bien plus. Je
lui souhaite bonne chance pour tout ce qu'il pourra réaliser dans cette grande
liste ; je pense qu'il en aura besoin.
</p>
<h3>Sven Luther</h3>
<p>
Je ne vois aucun programme.
</p>
<h3>Sam Hocevar</h3>
<p>
J'ai été impressionné l'année dernière par les tentatives de Sam pour faire de
humour sur les problèmes de Debian, aussi je ne m'attends pas à grand chose de
plus cette fois. Cependant, son programme contient beaucoup d'idées positives
sur la manière d'améliorer les choses et j'espère qu'il pourra en délivrer
quelques unes.
</p>
<h3>Raphaël Hertzog</h3>
<p>
Raphaël contribue à Debian depuis un certain temps, il est sans doute connu
surtout pour avoir beaucoup travaillé à Alioth. Nous avons travaillé ensemble
dans le passé, et les buts qu'il suggère semblent très raisonnables. Il appuie
principalement pour un bureau du responsable du projet Debian, une idée qui ne
me convient pas à 100 %. Malgré cela, je lui ai proposé de faire partir
de ce bureau au cas où il serait élu – après tout, le travail de
responsable du projet Debian devra être fait et je serai heureux de pouvoir
l'aider.
</p>
<h3>Anthony Towns</h3>
<p>
AJ et moi avons pas mal travaillé ensemble l'année dernière comme responsable
du projet Debian et 2IC<!-- c est quoi ça ? -->. Ça a été très productif, et je
le remercie de m'avoir donnée l'opportunité de l'aider. Il parle cette année de
technologie, de communauté et de faire avancer les choses, des sujets
importants. Je sais qu'AJ peut beaucoup apporter comme responsable du projet
Debian, et je lui souhaite encore beaucoup de chance dans la compétition cette
année.
</p>
<h3>Simon Richter</h3>
<p>
Je ne suis pas sûr de bien comprendre les idées de Simon. Il liste des
problèmes dans son programme, mais je ne vois aucune proposition pour les
résoudre.
</p>
signature.asc
Description: Digital signature
