ajout des réfutations --
#use wml::debian::template title="Programme d'Anthony Towns" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.7" maintainer="Nicolas Bertolissio" #include "$(ENGLISHDIR)/vote/style.inc" <h1 class="title">Programme d'Anthony Towns</h1> <p> Bonjour, je m'appelle Anthony Towns. Je suis candidat à l'élection du responsable du projet Debian cette année. Voici ce sur quoi j'aimerais travailler. </p> <h2>Accueillir des personnes dans le projet</h2> <p> Je pense qu'il est important que le projet accepte des contributions d'un groupe de personnes techniquement compétentes aussi large que possible. Je pense que la meilleure façon d'y arriver est : </p> <ol style=" list-style-type: lower-roman"> <li> de truffer nos listes de discussions techniques intéressantes qui accueillent les contributions intelligentes des nouveaux venus et ne perdent pas plein de temps à revenir sur d'anciens sujets classés ou sur du hors sujet. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00075.html";>[1]</a> <a href="http://lists.debian.org/debian-vote/2005/03/msg00525.html";>[2]</a> ;</em> </li> <li> d'inviter les nouveaux arrivants à venir assister des groupes existants ; et à traiter les assistants comme des personnes plutôt que comme des nouveaux programmes qui ont besoin de passer par une suite de tests standardisés. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00338.html";>[1]</a> ;</em> </li> <li> de permettre aux utilisateurs de participer au projet de façon reconnue, et ainsi de pouvoir les consulter directement sur les décisions plutôt que de laisser les développeurs deviner leur opinion. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00654.html";>[1]</a> <a href="http://lists.debian.org/debian-vote/2005/03/msg00701.html";>[2]</a> <a href="http://lists.debian.org/debian-vote/2005/03/msg00696.html";>[3]</a> ;</em> </li> <li> de rendre nos activités bien plus publiques, par exemple, en menant plus de débats sur les listes existantes, en créant des listes temporaires pour des discussions rapides qui seraient cependant archivées de façon permanente dans Debian, et en résumant les débats sur IRC sur des listes de manière systématique ; </li> <li> d'essayer activement d'inclure des dérivés dans le projet plutôt que d'espérer passivement qu'ils contribueront — par exemple inclure des projets comme Knoppix, backport.org, Ubuntu, fink et d'autres dans l'archive là où c'est possible ; et sinon développer les relations avec des organismes comme HP, Linspire, SkoleLinux et d'autres. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00781.html";>[1]</a>.</em> </li> </ol> <h2>Efficacité du projet</h2> <p> Bien qu'il soit parfois difficile de le dire, Debian a actuellement un but : à savoir créer un fantastique système d'exploitation libre. Il est important que nous soyons efficaces pour arriver à cet objectif — il ne sert à rien d'avoir le meilleur des concepts de système d'exploitation, les meilleures des chartes pour l'assembler, ou les meilleures des procédures pour l'entretenir si nous n'arrivons pas à suivre ces concepts, ces chartes et ces procédures, ni à implanter quoi que ce soit. Je pense que Debian a pris du retard dans ce domaine, et que la manière de résoudre cela est de travailler à prendre des décisions et à les suivre plutôt que d'essayer d'entretenir un consensus bancal en menant constamment les même débats avec de nouveaux participants. </p> <p>Nos mécanismes pour prendre des décisions sont :</p> <ol style="list-style-type: lower-roman"> <li>le consensus sur les listes de diffusion ;</li> <li>l'expertise des délégués et des responsables de paquets ;</li> <li>l'expertise du comité technique ;</li> <li>les résolutions générales des développeurs dans l'ensemble.</li> </ol> <p> Le premier a été la clef du succès de Debian — toute décision qui peut satisfaire plus ou moins tout le monde dans un groupe hétérogène est assez bonne. Il n'est bien sûr pas toujours possible de prendre une décision de cette façon ; c'est pourquoi nous avons besoins des autres possibilités. Malheureusement, elles ne fonctionnent pas très bien actuellement. </p> <p> J'ai la conviction que Debian pourrait s'améliorer ici simplement en donnant aux délégués une autorité claire pour prendre des décisions dans leurs domaines d'expertise, ainsi qu'en acceptant que l'on puisse persuader et convaincre les délégués et les responsables de paquets que quelque chose pourrait être fait d'une certaine façon. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00037.html";>[1]</a>\ </em> </p> <p> De plus, je pense que le comité technique servirait mieux le projet s'il était composé des membres actifs d'équipes clefs plutôt que par les vieux sages actuels ; cela à la fois comme un signe de confiance envers nos délégués et pour s'assurer que la connaissance des processus de Debian par le comité technique est aussi récente et complète que possible. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00518.html";>[1]</a>.</em> </p> <h2>Qualité de la distribution</h2> <p> Somme toute, je pense que nous pourrions produire une distribution substantiellement meilleure. La plus grande partie du travail a déjà été faite par les dérivés — comme l'accélération des scripts d'initialisation sur laquelle ont travaillé les gens d'Ubuntu, ou le développement d'un CD direct pour lequel Knoppix est connue — et nous pouvons acquérir ces caractéristiques simplement en travaillant à une meilleure intégration des dérivés ; mais il y a d'autres sujets, à mon avis, sur lesquels Debian lui-même devrait travailler : </p> <ol style="list-style-type: lower-roman"> <li> une meilleure charte — à présent la « charte » est fragmentée entre la charte Debian, la référence du développeur, divers documents spécifiques pour des sous-systèmes, et le bouche-à-oreille. Je pense que nous devrions travailler à leur intégration dans un unique paquet, si ce n'est dans un seul document ; </li> <li> une meilleure assurance qualité — avoir la totalité du code source de tous les logiciels que nous fournissons est la chance d'exceller dans un faisceau de domaines du type de l'assurance qualité ; je pense que nous ne devrions pas simplement avoir pour but de récolter tous les logiciels sympathiques qui passent à notre portée pour les mettre dans un .deb, mais que nous devrions aussi polir les parties rugueuses en écrivant des ensembles de tests automatiques pour nos paquets afin de nous assurer que tout est documenté et pour tendre vers le zéro défaut pour tout ce que nous embarquons. </li> <li> une meilleure sélection de paquets — l'un des problèmes que tout utilisateur de Debian a rencontré et rencontrera certainement encore est de trouver quels paquets installer ; par exemple ether-wake ou wakeonlan ? Je pense que cela fait longtemps que nous n'avons pas fait de progrès significatifs dans ce domaine, en nous posant des questions sur le classement et l'imbrication des paquets, ainsi que l'accessibilité des paquets non libres ou commerciaux. </li> </ol> <h2><i>Addenda</i></h2> <p> Enfin, quelques autres notes que vous trouverez pertinentes ou pas. </p> <p> Je pense que le rôle du responsable du projet Debian est, eh bien, de mener le projet : trouver les domaines particuliers sur lesquels le projet devrait se concentrer, ainsi que trouver les domaines où le projet fonctionne mal et l'aider à s'en sortir. Le responsable du projet Debian n'a en fait qu'un seul pouvoir, donner de l'autorité aux autres. C'est un pouvoir assez subtile — c'est la différence entre celui qui a le mot de passe du superutilisateur et celui qui a la permission de l'utiliser. Mais dans un groupe de personnes qui se soucie aussi résolument qu'un développeur Debian de ce qui est juste et ce qui est faux, c'est en fait un pouvoir relativement important. <em>Remarques complémentaires : <a href="http://lists.debian.org/debian-vote/2005/03/msg00702.html";>[1]</a> <a href="http://lists.debian.org/debian-vote/2005/03/msg00703.html";>[2]</a>.</em> </p> <p> Pour ceux que ça intéresse, j'ai rejoint Debian au début 1998. Je suis l'auteur d'ifupdown et de debootstrap. J'ai écrit des correctifs pour gzip (bogues n° 30537, n° 184057), pour dpkg (bogues n° 93386, n° 112386, n° 184635), pour pax (bogue n° 139943), et d'autres. J'ai participé aux forums sur la base standard Linux et le standard hiérarchique des systèmes de fichiers, ainsi que sur diverses listes Debian. J'attends toujours avec impatience le jour où les bogues n° 18733 et n° 62529 seront résolus. </p> <p> J'ai écrit des scripts SGI pour bugs.debian.org comme preuve de faisabilité et j'ai commencé à conserver d'anciens rapports de bogue plutôt que de les laisser se perdre à jamais un mois après leur clôture. Je me suis alors retrouvé dans l'équipe des bogues de Debian lorsque les vieux scripts qui généraient les pages statiques une ou deux fois par jour ont commencé à défaillir juste parce que nous avions trop de bogues. J'ai également ajouté le support des étiquettes de bogues, des requêtes par rapporteur, le clonage des bogues et le blocage de l'accès à l'adresse control@ pour les personnes qui en abusent. </p> <p> Mon activité la plus exposée dans le projet est ma participation à la gestion des éditions. J'ai commencé à m'y impliquer en 1998 en m'engageant dans le débat à propos du « modem de publication de Debian », <i>Debian release modem</i>, (<i>sic</i>) sur -devel, et avec d'autres personnes intéressées nous sommes arrivés à l'idée qui est derrière la distribution de test. Après de plus amples discussions et des modifications, j'ai commencé à implanter « britney » en 1999 en entretenant une copie de l'archives par des liens durs, et pour finir nous sommes arrivés à un point où je pensais qu'on était prêt à l'intégrer correctement en 2000. À ce moment, j'ai proposé à Richard Braakman de l'aider dans la gestion de l'édition de Potato, il avait pratiquement fuit le pays, et j'ai dû réaliser les phases finales de la publication de Potato qui est sortie en août 2000. J'ai ensuite travaillé avec Jason Gunthorpe (qui est l'auteur principal d'apt) et James Troup pour convertir l'archive en zones afin de pouvoir abandonner les horribles liens durs et de pouvoir faire des miroirs de la distribution de test, et nous avons sorti cette distribution fin 2000. C'est à cette époque que j'ai été ajouté au groupe des responsables ftp pour rendre plus facile l'intégration. J'ai poursuivi en tant que responsable de publication pour Woody, j'ai alors pensé que suivre l'exemple de Richard serait une bonne chose et j'ai eu la chance que Steve Langasek et Colin Watson se portent volontaires. </p> <p> J'ai saisi l'occasion de me retirer du rôle de gestionnaire de publication l'année dernière pour différentes raisons. À long terme, je souhaitais transmettre le rôle de responsable de publication depuis quelques temps déjà — je suis plus intéressé (et efficace) dans la conception initiale et l'implantation que sur l'entretien à long terme — et Colin et Steve étaient déjà capable de réaliser la plupart du travail eux-mêmes. À court terme, je n'étais plus convaincu d'avoir le soutien du projet pour faire le travail du responsable de publication, et Colin et Steve auraient une bien meilleure occasion de le poursuivre sans confusion ni distraction. Je pense que ça s'est plutôt bien passé. </p> <p> Mon activité de responsable ftp consiste principalement en la maintenance de britney, en travail de conception, avec de temps en temps le suivi de nouveaux paquets et des demandes de suppression. J'ai fait pas mal de travail de coordination pour le passage des logiciels de chiffrement dans l'archive principale, à comprendre comment refaire le suivi de sécurité pour l'édition Woody, et j'ai conçu et implanté les fichiers Released signés et aidé à leur support par apt. </p> <h2>Conclusion</h2> <p> Je pense que mes expériences à l'intérieur de Debian correspondent raisonnablement bien avec ce que j'aimerais accomplir et que des progrès intéressants devraient être possibles cette année dans les domaines ci-dessus. Mais bon, il m'est déjà arrivé de me tromper. </p> <h2>Critiques des autres candidats</h2> <p> Eh ! ils leur est aussi arrivé de se tromper ! </p> <h2>Réfutation</h2> <h3>Angus Lees</h3> <p> J'envie la brièveté d'Augus à ce niveau, et j'espère que j'arriverai à l'égaler un jour. </p> <h3>Matthew Garrett</h3> <p> Je pense que le programme de Matthew est assez bon. Ses priorités sont un peu différentes des miennes, mais je pense que s'il accomplit ce qu'il souhaite, ce sera bien pour Debian. </p> <p> Cependant, je ne suis vraiment pas d'accord avec l'accent que met Matthew sur les débat sans confrontation. Je crois que tenter d'éviter les confrontations tend à essayer de satisfaire les personnes les plus tenaces, car elles essayeront de s'assurer qu'il y ait une confrontation à moins qu'elles n'obtiennent exactement ce qu'elles souhaitent, alors que des personnes plus discrètes n'engageront généralement pas de confrontation avant que les choses ne commencent réellement à laisser désirer. Je crois vraiment que les gens sont capable de gérer avec respect des opinions divergentes et des approches différentes, sans devoir se disputer ni être violent ; mais je pense qu'il est important que toute personne dans une position de direction soit prête à mener une discussion en règle pour défendre les gens qui travaillent avec elle, et cela comprend des confrontations de manière occasionnelle. Je crois qu'il est bien meilleur d'avoir ces confrontations et des les résoudre que de les éviter. </p> <h3>Andreas Schuldei et le projet Scud</h3> <p> Je trouve le développement du projet Scud assez déconcertant ; il semble qu'un groupe secret de développeur Debian s'est formé avec le seul but de prendre le contrôle du projet, et vraiment je ne vois pas comment quelque chose comme cela puisse être autrement que déconcertant. </p> <p> Andreas et Steve ont mené toute (ou presque toute) l'organisation de la cabale organisée contre la publication qui s'est tenue à Vancouver (les 5 et 6 mars), ce fut une grande idée et, je pense, qu'elle a été efficace — mais elle a été organisée sans en avertir le responsable actuel du projet Debian, sans plus d'information que celles fournies au reste du projet. J'aime plaisanter de cette cabale dans Debian, mais parce que, de mon expérience, *c'est* une plaisanterie ; toutes les personnes qui ont du pouvoir dans Debian ont une opinions assez différente et assez joyeusement travaillent les unes contre les autres, ne communiquent pas entre être pas plus qu'avec le reste du projet, et ont toutes sortes d'autres problèmes. Le projet Scud au contraire semble avoir été une réelle « cabale » jusqu'à présent, et je ne sais pas trop comment nommer délibérément un tel groupe pour diriger Debian pourrait être une bonne chose pour la promotion du développement ouvert, public et orienté vers la communauté pour lequel Debian est connu. </p> <p> Un autre soucis avec le projet Scud est que s'il est élu, sa façon de fonctionner n'est pas clair du tout — chaque membre a-t-il déjà un domaine d'autorité bien défini, le responsable du projet Debian prendra-t-il les décisions et l'équipe les mettra-t-elle en œuvre, ou essayeront-ils de prendre les décisions en groupe avec comme président le responsable du projet ? Cela dépendra peut-être du candidat élu. Le soutien du projet Scud aux programmes de ses deux candidats ou la façon dont les candidats soutiennent chaque membre de l'équipe ne sont pas clairs non plus. On a un peu l'impression que voter pour l'un ou l'autre des candidats du projet Scud c'est comme jouer à la roulette. </p> <h3>Branden Robinson</h3> <p> Je ne peut sans doute pas écrire grand chose sur Branden qui ne puisse être écarté par quelque chose comme « Oh, mais AJ et Branden se disputent tout le temps, bien sûr qu'il l'a dit ». Et si vous aimez ce genre de choses, Branden et moi avons rejoint les projet la même semaine (fin février 1998 pour ceux qui souhaitent vérifier les archives de -private — la même semaine que Eric S. Raymond). </p> <p> Quoi qu'il en soit, j'ai deux soucis que vous pouvez ou pas prendre en compte avec Branden. Le premier est son attachement régulier lors de ces années de campagnes aux problèmes de procédures à l'exclusion des problèmes techniques : je pense qu'il est bien plus important pour les membres du projet de s'attacher à ce que nous souhaitons accomplir plutôt qu'à la manière d'y arriver, et que nous serons bien mieux si nous bloquons occasionnellement le processus mais ne perdons pas de vue ce que nous essayons de réaliser que le contraire. Je pense que les priorités du responsable du projet devrait refléter cela. </p> <p> Mon second soucis est que je ne pense pas que Branden ait démontré qu'il serait très efficace pour arriver à ces objectifs. Lorsqu'il est devenu trésorier de SPI en août 2001, son but était de corriger les problèmes de conservation des registres qui s'étaient accrus jusque là, et d'être bien plus transparent et efficace pour l'acceptation et le traitement des dons et des remboursements. Malheureusement, et pour diverses raisons, il n'y est pas arrivé — au point que des dons au projet Debian n'ont pas été déposées du tout pendant une période de d'environ une année et ont expiré et ne peuvent plus être déposées à nouveau. Avec la rétrogradation de Branden en trésorier adjoint de Jimmy Kaplowitz, il semble est devenu beaucoup plus efficace, ce qui est en sa faveur, mais, à mon avis, indique toujours qu'il n'est pas prêt pour un poste de direction important. Remarques complémentaires : <em> <a href="http://lists.debian.org/debian-vote/2005/03/msg00698.html";>[1]</a>.</em> </p> <p> Je sens que je devrais aussi noter que pendant que Branden indique que le projet Scud soutien la méthode de scrutin que nous utilisons au moins pour l'élection du responsable du projet Debian, il était l'un de ceux qui avait voté contre son adoption lorsqu'elle avait été proposée ; et de plus il avait fortement argumenté pour encourager les votes non sincères avant le scrutin sur l'archive non libre il y a un peu plus d'un an. </p> <h3>Jonathan Walther</h3> <p> <em><a href="http://lists.debian.org/debian-vote/2005/03/msg00014.html";> Commentaires similaires d'Erinn Clark sur la proposition de commité de Jonathan</a>.</em> </p> <p> Je trouve que je ne suis pas d'accord avec le sentiment que Jonathan indique dans son programme, sentiment d'intérêt croissant par l'implication des femmes dans Debian. Personnellement, j'ai été plutôt encouragé à la fois par le nombre croissant de femmes qui pensent pouvoir participer à Debian et par la forme de leur participation, en particulier les magnifiques diagrammes d'état de dpkg de Margarita Manterola, les présentations d'Hanna Wallach lors des conférences sur Linux, et le programme de parrainage mené par Helen Faulkner, ainsi que l'étendu habituelle d'entretien, de report et de correction de bogues de paquets. Autant que je sache, cette activité est due principalement au travail d'Erinn Clark et Helen Faulkner au paramétrage et à l'entretien du projet Debian et les femmes. Il est en particulier impressionnant que toutes ces femmes aient fait toutes ces contributions avant d'avoir réussi à passer le processus du nouveau responsable. </p> <p> Je pense que la meilleure des choses que nous puissions faire pour la participation des femmes à Debian soit d'admirer ce qu'elles ont réalisé aujourd'hui, de faire ce qui nous est possible pour les aider à améliorer leurs succès, et nous assurer que nous incorporons leurs réussites dans d'autres domaines du projet. </p>
#use wml::debian::template title="Programme d'Andreas Schuldei" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.5" maintainer="Nicolas Bertolissio" #include "$(ENGLISHDIR)/vote/style.inc" <h1 id="top">Programme d'Andreas Schuldei</h1> <h2>Présentation</h2> <p> J'ai 34 ans, je suis marié avec un enfant. Je suis développeur Debian depuis 2000 et je travaille professionnellement avec Linux (puis Debian) depuis 1996. Actuellement je suis payé pour travailler sur Debian-Edu. Si je suis élu, mon employeur continuera à me soutenir car il croit que le rôle du responsable du projet Debian est crucial pour Debian — cela me permettra aussi de travailler sur les questions du responsable du projet Debian pendant mes heures de travail. Beaucoup d'entre vous peuvent également me connaître par les conférences Debian que j'ai aidées à organiser. <a href="http://www.schuldei.org/a_l.png";><img src="http://www.schuldei.org/a_l.png"; /></a> </p> <p> Je me présente pour le rôle de responsable du projet Debian car : </p> <ul> <li> je crois que Debian a besoin de certains changements dans sa manière de fonctionner (même au niveau social) et j'ai de l'expérience dans l'implantation de changements dans des contextes de bénévolat ; </li> <li> j'ai de l'expérience de direction dans des contextes de la vie réelle et des logiciels libres et à source ouvert ; </li> <li> je peux être responsable du projet Debian à temps complet si nécessaire ; </li> <li> j'ai prouvé que j'étais un bon organisateur. </li> </ul> <p> J'ai aussi commencé il y a quelques temps à travailler sur certains des problèmes que nous rencontrons aujourd'hui, à savoir la <em>confusion sur les responsables FTP</em><sup><a id="fnr.1" href="#fn.1">1</a></sup> et le <em>délai de publication des versions</em><sup><a id="fnr.2" href="#fn.2">2</a></sup>. </p> <hr /> <h2>Ce que je souhaite accomplir</h2> <p> <em>L'objectif général est de faire de Debian un endroit de plaisant et de gratifiant où travailler et où passer son temps. Si bien que, si quelqu'un ne pouvait pas être ou travailler à Debian, cela lui manquerait et il en aurait très envie.</em> </p> <p> Une partie de cet objectif pourrait être : </p> <ul> <li> de promouvoir de nombreuses petites équipes à travers tout le projet dans lesquelles les gens travailleraient ensemble, communiqueraient, aideraient, intégreraient et entraîneraient les nouveaux responsables ; </li> <li> d'avoir un environnement plus amical et plus utile sur les listes de diffusion et les canaux IRC ; </li> <li> de rendre les gens conscients de leur rôle de responsable dans le projet et de les encourager à l'accepter plus délibérément et avec plus de confiance ; </li> <li> d'avoir des versions publiées plus fréquemment et plus régulièrement ; </li> <li> d'avoir des <em>rencontres</em><sup><a id="fnr.3" href="#fn.3">3</a></sup> dans la vie réelle plus fréquentes comme les conférences Debian, les chasses aux bogues ou les rencontres de développement (comme ce qu'a fait l'équipe de l'installateur Debian à Oldenburg ou l'équipe Debian-Edu à Oslo). </li> </ul> <p> Ces étapes feraient de Debian un endroit plus agréable et en même temps s'occuperaient des <em>problèmes d'échelle</em><sup><a id="fnr.4" href="#fn.4">4</a></sup> dont souffre Debian. </p> <p> L'implantation de ces changements d'un seul coup échouerait à coup sûr et ferait du tort : les changements sociaux doivent être implantés graduellement et délicatement. Néanmoins il est important de débuter dès que possible, et même si nous ne voyons pas de résultats immédiats, il est important de continuer lentement mais sûrement. </p> <p> Il n'est pas nécessaire d'avoir des dirigeants parfaits à la recherche de petites équipes et une ambiance de travail amicale et utile en un seul mois. Mais nous commencerons vite à voir des changements notables et positifs si nous arrivons à réaliser beaucoup de petites améliorations, l'une après l'autre. </p> <hr /> <h2>Comment je souhaite y arriver : une équipe responsable du projet Debian</h2> <p> Je crois qu'être responsable du projet Debian est devenu un travail de plus en plus difficile au cours des années, avec de plus en plus de tâches consommatrices de temps. Je crois également que Debian pourrait réaliser de bonnes choses ici ou là avec une attention sérieuse non limitée par les ressources d'une seule personne. Afin de mieux réaliser mes objectifs, j'ai sollicité l'aide d'une petite équipe de développeurs Debian. Actuellement elle est composée (dans l'ordre alphabétique) d'Andreas Schuldei, Bdale Garbee, Branden Robinson, Enrico Zini, Jeroen van Wolffelaar et Steve Langasek. </p> <p> Avoir une équipe responsable du projet Debian nous permettrait de : </p> <ul> <li> répartir la charge de travail, éviter la surchauffe et les problèmes liés à l'indisponibilité de développeurs individuels dans le monde réel ; </li> <li> rester régulièrement en contact avec une plus grande partie de projet, être plus proactif face aux difficultés, et les déceler plus tôt ; </li> <li> aider à construire un consensus plus large en fonctionnant comme un « président » dans Debian ; </li> <li> s'assurer que les décisions qui doivent être prises le sont réellement, même si cela demande de garder des traces de beaucoup de choses, prend du temps et requiert peut-être d'être à plusieurs endroits en même temps ; </li> <li> avoir la personne la plus appropriée comme responsable dans son domaine d'expertise. Chacun dispose de talents uniques et de motivations qui rendent certaines tâches plus agréables pour soi que pour les autres et lui permet de les traiter plus efficacement. </li> </ul> <h3>Détails de l'implantation :</h3> <ul> <li> le responsable du projet Debian est le président de l'équipe responsable du projet ; </li> <li> le responsable du projet Debian reste formellement responsable de toutes les décisions ; </li> <li> à chaque fois que possible, des tâches plus petites sont déléguées au membre de l'équipe le plus approprié ; </li> <li> les décisions importantes et controversées sont prises en accord avec l'équipe complète ; </li> <li> l'équipe se rencontre régulièrement et fréquemment (au moins une heure par semaine) pour débattre des nouveaux problèmes et passer en revue les tâches en cours ; </li> <li> l'équipe existe réellement, chaque membre peut la représenter et communiquer le point de vue de l'équipe quelque soit sa propre opinion ; </li> <li> des minutes des rencontres privées sont rendues publiquement disponibles lorsque la réserve le permet ; de même, un agenda public est rendu disponible à l'avance pour lister tous les objets non sensibles, afin de permettre et d'inviter à des débats et des retours d'expériences publics avant que des décisions ne soient prises. </li> </ul> <p> Nous recherchons la transparence et sommes ouvert à plus de gens, mais nous n'avons pas l'intention de trop grossir (disons environ sept personnes) pour conserver l'efficacité du travail de groupe. Des fluctuations et un remplacement lents ainsi que la fidélité des membres sont souhaitables, quoi qu'il en soit, il ne faut pas s'attendre à ce que les membres de l'équipe restent plus longtemps qu'ils ne le peuvent. </p> <hr /> <h2>Direction</h2> <p> De bons dirigeants existent dans le monde du logiciel libre, y compris Debian, et ils se distinguent sans que personne ne le remarque, pas même eux. Il y a de bons exemples dans Debian avec Steve Langasek dans l'équipe de publication, Petter Reinholdtsen dans Debian-Edu ou Joey Hess pour l'installateur Debian. </p> <p> Les dirigeants d'organisations bénévoles comme Debian n'ont pas à leur disposition les instruments du pouvoir qui sont utilisés dans les environnements d'entreprise qui leur donnent leur mauvais goût. Cela n'empêche pas certaines personnes de les appliquer tout de même : il en résulte habituellement le départ des gens et de la frustration en général. La réponse à la crainte d'avoir de mauvais dirigeants n'est pas de ne pas avoir de dirigeants du tout, mais d'en rechercher de bons. Les grands dirigeants ne sortent pas de nulle part, mais ils ont besoin de se former. Les petites équipes sont des environnements favorables pour le développement de leurs qualités et pour apprendre des autres. </p> <p> # HELP # The "Herding of Cats" failed. The problem is in the word "herding" # which implies "keeping people in the place where they are". # HELP Les gens sont plus enclins à poursuivre des objectifs fascinants. L'objectif de Debian est de produire un excellent système d'exploitation libre et d'y prendre du plaisir. La tâche du responsable est de conserver cette vision active et vivante ainsi que d'encourager les gens à y prendre part. </p> <h3>Rendre la vie plus facile !</h3> <p> Les responsables des projets bénévoles peuvent et doivent : </p> <ul> <li> donner mandat aux bonnes personnes pour réaliser le travail qui correspond le mieux à leurs talents, leurs motivations et leur tempérament ; </li> <li> trouver et aider les autres responsables à trouver leurs domaines d'intérêt ; </li> <li> inspirer confiance aux gens sur la direction que prend ou devrait prendre Debian, leur sous-projet ou les petites équipes ; </li> <li> rendre leur domaine d'influence aussi amusant, plaisant et gratifiant que possible pour travailler ou pour vivre ; </li> <li> se rendre inutiles. </li> </ul> <p> Introduire cela doucement dans Debian prendra du temps. </p> <hr /> <h2>De petites équipes</h2> <p> De petites équipes sont probablement la plus importante des caractéristiques dont un groupe comme Debian a besoin pour pouvoir croître de façon saine. Montées correctement, cela peut résoudre de nombreux problèmes. </p> <h3>Ce que peuvent faire de petites équipes</h3> <ul> <li> elles fournissent un <em>point d'entrée simple</em> pour que les nouvelles personnes apprennent les ficelles du métier et développent leurs compétences (nouveaux responsables) ; </li> <li> elles sont l'<em>endroit où l'on peut rencontrer des gens</em> le plus rapidement et le mieux (grâce au nombre restreint de personnes que constitue le groupe) ; </li> <li> grâce aux forts liens sociaux des petits groupes, le risque de voir les gens <em>disparaître est souvent réduit</em> ; </li> <li> les gens peuvent former un <em>ensemble de connaissances</em> en coopérant pour l'entretien de paquets, les tâches d'infrastructure ou d'organisation, et cet ensemble à moins de risques d'être perdu que lorsqu'une personne est seule. Cela pourrait rendre Debian plus solide face aux paquets fous, non entretenus ou aux chasseurs de têtes ; </li> <li> comme ces équipes peuvent croître et se diviser d'elles-mêmes, elles s'organisent <em>seules</em> et assurent une <em>très bonne évolutivité</em> de leur nombre ; </li> <li> elles servent de lieu d'essai pour les gens qui découvrent leurs motivations intérieures, leurs talents et leurs motivations pertinentes pour que Debian fonctionne ; </li> <li> elles rendent la <em>communication</em> plus facile. </li> </ul> <h3>Ce à quoi les petites équipes devraient ressembler</h3> <p> Pour qu'une équipe soit capable de répondre complètement à ces fonctions, elle a besoin d'avoir quelques caractéristiques : </p> <ul> <li> elle ne doit <em>pas trop grossir</em> (sept semble être un bon chiffre) au risque de devenir plus impersonnelles ; </li> <li> les membres de l'équipe doivent être conscients que le groupe devra se scinder lorsqu'il aura atteint une certaine taille et que l'occasion se présentera ; </li> <li> les membres de l'équipe doivent être <em>compatibles socialement</em> (le courant de base doit passer) ; </li> <li> les gens doivent être capables de se contacter fréquemment (par IRC si possible) ; </li> <li> l'équipe ne devrait pas seulement se préoccuper elle-même des questions techniques mais de toutes les choses humaines. Elle devrait être capable de discuter de série télé, de politique ou de football, trouver des amis et tomber amoureuse ; </li> <li> l'équipe devrait s'ouvrir aux autres ; </li> <li> elle devrait avoir un responsable tel que décrit dans <em>Direction</em>. </li> </ul> <p> Introduire une telle organisation de petites équipes dans Debian prend du temps et est un processus progressif. Bien que l'entretien en groupe des paquets ne soit pas une nouveauté et que le travail en équipe existe, ce concept va plus loin. </p> <p> Si vous m'élisez comme responsable du projet Debian, je me trouverai dans une position bien plus efficace pour défendre et implanter de telles équipes dans le projet Debian. </p> <hr /> <h2>Ambiance de travail</h2> <p> L'attractivité d'un groupe dépend de façon significative de la manière dont ses membres se sentent <em>bien accueillis, respectés et appréciés</em>. Même si ce mot est incroyablement banalisé et qu'on en abuse fréquemment, je dis toujours que la relation dont nous avons besoin est l'« amour » car c'est lui qui transmet le mieux ce concept. La qualité de la communication dans les groupes est fortement corrélée à cette caractéristique clef. </p> <h3>Des Indicateurs</h3> <p> Le tons des débats dans Debian est une bonne indication de la manière dont s'« aiment » les gens. L'atmosphère est-elle amicale et constructive ou caustique et corrosive ? L'humour, les rires et l'amusement sont des composants positifs qui font d'un groupe un environnement plaisant. Les actes de bonté aléatoires sont aussi possible dans les communautés virtuelles et peuvent même se poursuivre dans la vie réelle. </p> <h3>Où cela fonctionne le mieux</h3> <p> Les sous-projets les plus petits, les plus personnels et où les gens se rencontrent régulièrement obtiennent un bien meilleur rapport signal sur bruit dans leur communication et sont plus chaleureux que les grosses listes de diffusion et les canaux Debian IRC. </p> <h3>Des changement sont possibles</h3> <p> Il est possible de modifier de façon déterminée les relations et le ton des débats dans Debian. Nous pouvons informer les gens des bases de la dynamique des groupes et les aider à trouver de meilleures formes d'expression. Chacun devrait savoir quand un courriel ou une remarque ne vaut pas la peine d'être envoyé par exemple. </p> <h2>Conclusion</h2> <p> Ce que je propose dans ce programme est en même temps « radical » et « simplement du bon sens » : la plus grande partie consiste à rendre Debian moins stressant et plus amusant. Les seules modifications qui seront acceptées seront celles que les gens veulent, dans Debian comme dans tous les endroits où les gens sont libres. </p> <p> Je crois que ces modifications sont des idées si évidentes que nous les <em>souhaitons</em> tous, indépendemment de celui qui sera élu responsable du projet Debian. M'élire est une manière de montrer votre accord, et de commencer. </p> <hr /> <p> <a id="fn.1" href="#fnr.1">1</a>. <strong><em>La confusion sur les responsables FTP</em></strong> </p> <p> Depuis quelques temps il y a de l'irritation, de l'énervement général ou même de l'hostilité ouverte entre les responsables FTP et certains autres développeurs Debian concernant le travail des responsables FTP et la manière dont ces développeurs pensent qu'il devrait être fait. Il s'agit d'un exemple d'ambiance de travail négative dans Debian. </p> <p> Cette situation a abouti à une impasse où les uns demandent des comptes et de la transparence et où les autres refusent de s'y conformer tant que l'ambiance hostile perdurera. </p> <p> La solution en plusieurs étapes à ce problème prend du temps et fournira une solution évolutive à long terme. J'en ai discuté avec les responsables FTP et certaines personnes qui pourraient réaliser ce travail. En plus, elle correspond bien à l'approche des « petites équipes » que je promeus partout et elle ressemble aux modèles de maître et d'assistant de publication ainsi que de responsable de candidature, secrétariat du nouveau responsable et responsable des comptes de Debian, modèles qui fonctionnent déjà de façon satisfaisante. </p> <p> Il s'agit simplement d'un exemple de ce que je ferai si je suis élu responsable du projet Debian. Bien que je puisse déjà aujourd'hui apaiser les passions, avoir l'autorité que confère d'être choisi responsable de tous les développeurs est une aide pour mener ce projet vers la résolution favorable des conflits internes. </p> <p> <a id="fn.2" href="#fnr.2">2</a>. <strong><em>Les délais de publication des versions</em></strong> </p> <p> Debian a besoin de publier des versions plus fréquemment et plus régulièrement. Les délais actuels engendrent de la frustration et le déclin du moral dans les contrées de Debian. Pour montrer la voie vers un cycle de développement et un processus de publication plus doux, j'ai pris l'initiative, trouvé des parrainage (de NUUGF) et organisé une rencontre entre l'équipe de publication et les responsables FTP qui doit se tenir bientôt. </p> <p> <a id="fn.3" href="#fnr.3">3</a>. <strong><em>Les rencontres de la vie réelle</em></strong> </p> <p> En plus d'être divertissantes, ces rencontres servent quelques fonctions vitales, en particulier pour les communautés virtuelles comme Debian : </p> <ul> <li> elles aident les gens à connaître les personnes qui sont derrière les personnages en ligne, et à mieux se comprendre ; </li> <li> elles aident à voir la grande communauté Debian ; </li> <li> la vie réelle fournit une bande passante infinie pour communiquer et minimiser les malentendus ; </li> <li> les gens sont nouvellement attirés vers Debian en rencontrant d'autres gens et en écoutant de bons discours ; </li> <li> les groupes peuvent être très productif pour résoudre des problèmes. </li> </ul> <p> Alors bien que les rencontres ne soient pas un but en elles-mêmes, leurs résultats le sont sans aucun doute et ils se sont montrés de grande valeur pour Debian. </p> <p> <a id="fn.4" href="#fnr.4">4</a>. <strong><em>La gestions des besoins de croissance</em></strong> </p> <p> La planification des charges est fréquemment un défi pour les grands organismes, et une fois que vous avez pris du retard, il est très difficile de le rattraper. Beaucoup des enjeux de Debian les plus chauds ces dernières années ont été des problèmes de charge : s'assurer que le réseau des constructeurs automatiques avait la capacité de gérer nos nombreux paquets ; s'assurer que le processus du nouveau responsable avait la capacité d'absorber le nombre de candidats ; s'assurer que l'équipe de sécurité avait la capacité de gérer nos nombreuses architectures ; etc. Bien que beaucoup de ces problèmes soient nettement de nature technique, l'identification et la résolution des bouchons avant qu'ils ne deviennent des problèmes requièrent une gestion attentive, et le responsable du projet Debian est le mieux placé pour avoir cette vue d'ensemble. </p> <hr /> <h2>Réfutation</h2> <p> Les programmes et la campagne de cette année semblent être caractérisés par le fait que la plupart des candidats (Branden, Anthony, Matthew mais aussi Angus) reconnaissent les défauts du projet Debian à un niveau social. Le symptôme le plus évident qu'ils identifient est l'efficacité limitée de la communication sur certaines listes de diffusion du projet. </p> <p> Je prends cela comme un signe que mon approche pour essayer d'influencer les caractéristiques sociales du projet est en fait la bonne direction. </p> <p> Ce qui est différent dans mon approche, comparé aux leurs, est qu'elle n'aborde pas qu'un seul symptôme du problème en ajoutant des règles supplémentaires pour la communication à l'intérieur du projet, mais qu'elle modifie un contexte plus large. En introduisant une direction sensée et par délégation, en affermissant et en étendant de petites équipes, en travaillant sur de bonnes relations et en augmentant la fréquence et la qualité de rencontres réelles, on peut réaliser des changements profonds vers quelque chose de meilleur. Dans ce contexte, j'aimerais pointer la très utile question d'Henning « [...] comment vous, en tant que responsable du projet Debian, fairez-vous la différence [...] ? » et ma <a href="http://lists.debian.org/debian-vote/2005/03/msg00372.html";>réponse passionnée</a>. </p> <p> Tous les autres canditats (même Branden) soit semblent sous-estimer la charge de travail qu'induit le poste de responsable du projet Debian ces dernières années soit auront besoin d'y travailler à plein temps. Notre responsable actuel, Martin, est à la fois très intelligent et très organisé et est toujours surchargé de travail, négligeant même partiellement ses recherches. </p> <p> La grande idée de se fier à une équipe responsable du projet Debian nous aiderait, Branden ou moi, à la fois à atteindre nos buts respectifs et à rester dans un processus sain. </p> <p> Branden et moi avons été incapables d'identifier les domaines où nous sommes en désaccord profond. C'est une bonne chose car nous avons l'intention de travailler dans la même équipe. Alors que j'ai l'intention d'utiliser le pouvoir du responsable du projet Debian de manière proactive pour gérer les problèmes quotidiens, je rechercherai aussi des modifications informelles permettant au projet de se charger des principaux défis sociaux alors que Branden propose des améliorations basées sur un formalisme des procédures plus important. </p> <p> Je me différencie de Branden également par mon engagement dans la construction d'une communauté active en m'impliquant dans les conférences Debian et dans de nombreux autres rassemblements et rencontres de développement. </p>
#use wml::debian::template title="Programme de Branden Robinson" BARETITLE="true" NOHEADER="true"
#use wml::debian::translation-check translation="1.3" maintainer="Nicolas Bertolissio"
#include "$(ENGLISHDIR)/vote/style.inc"
<div style="text-align: center">
<h1>Programme de Branden Robinson pour l'élection 2005 du responsable du projet Debian</h1>
</div>
<div>
<ul class="spacey">
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex"><a href="#s1">Introduction</a></li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex"><a href="#s2">Mes objectifs</a></li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex"><a href="#s3">Ce qui change cette année</a></li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex"><a href="#s4">Ce que je propose</a></li>
</ul>
<h2 id="s1">Introduction</h2>
<p>
Je suis développeur Debian depuis début 1998. Mon travail le plus
important dans Debian a été l'entretien des paquets XFree86, entretien que j'ai
réalisé pendant sept années à mars 2005. Depuis 2001, j'ai également
servi au bureau de direction de Software in the Public Interest, Inc., la
société à but non lucratif responsable de la tenue des avoirs du projet Debian
aux États-Unis. Mon emploi chez Progeny, l'entreprise Linux cofondée par le
fondateur de Debian Ian Murdock, est dans sa cinquième année, et j'y tiens à la
fois des responsabilités de gestion et de conception. Je suis marié et sans
enfant. À mon grand chagrin, j'ai récemment passé la trentaine.
</p>
<p>
Je me suis aussi présenté aux élections du responsable du projet Debian
depuis 2001, mais pas encore avec succès. Je continue de me présenter car
je perçois toujours, à l'intérieur du projet Debian, des problèmes et des
opportunités auxquels je souhaiterais m'attaquer à partir de la seule position
de direction élue dans Debian. Je n'étais pas enclin à me porter candidat cette
année, et j'avais posté une <a
href="http://people.debian.org/~branden/dpl/to_run_or_not_to_run_in_2005.html";>\
déclaration</a> en ce sens, mais grâce aux encouragements d'une centaine de
développeurs Debian (dont cinq candidats développeurs qui rejoindront nos rangs
bientôt), j'ai été persuadé de me porter candidat. Ces personnes m'ont fait
comprendre que mes <a
href="http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml";>\
objectifs</a> étaient toujours d'actualité, et que j'en étais toujours un
promoteur convainquant. Je remercie chaleureusement tous ceux qui m'ont demandé,
en public ou en privé, de m'inscrire sur l'ardoise des candidats cette année.
</p>
<h2 id="s2">Mes objectifs</h2>
<p>
J'ai beaucoup écrit à propos de mes objectifs dans mes programmes précédents de
responsable du projet Debian. Comme mes diagnostiques des défis de Debian n'ont
pas changé de manière significative ces dernières années, et afin d'épargner
aux volontaires de Debian le travail de traduction de texte supplémentaire, je
vous demande de regarder mon <a
href="http://people.debian.org/~branden/dpl/campaign/2004/platform.xhtml";>\
programme 2004</a> plus de plus amples informations.
</p>
<h2 id="s3">Ce qui change cette année</h2>
<p>
Je suis heureux de vous informer que, il y a un peu plus d'un mois, on m'a
demandé de prendre part à une nouvelle approche de la direction du projet
Debian. Jeroen van Wolffelaar, Andreas Schuldei, Enrico Zini, Steve Langasek,
Bdale Garbee et moi-même avons formé le « projet Scud », une équipe
de développeurs Debian intéressés qui ont décidé d'utiliser une nouvelle
approche pour résoudre les problèmes qui datent à l'intérieur du projet.
</p>
<p>
Les forces d'une approche basée sur une équipe sont évidentes : il y a
plus d'énergie pour découvrir le travail à faire, plus de temps à consacrer aux
tâches de direction et — le plus important — les
responsabilités peuvent être réparties pour correspondre au mieux aux atouts de
chacun. Alors qu'il peut n'y avoir aucun candidat responsable du projet Debian
qui reflète la vision idéale de responsable du projet d'un votant, nous avons
déjà vu plusieurs fois dans le projet Debian comment une équipe motivée et
harmonieuse peut faire évoluer les choses et les faire fonctionner sans accroc.
</p>
<p>
De même, avec un unique responsable élu du projet Debian, il reste toujours de
la place pour prendre des responsabilités. La responsabilité ultime pour les
décisions de direction incomberont toujours au responsable élu du projet
Debian. Une seule personne reste et doit rester redevable des décisions de
direction en dernier ressort, et cette personne est le responsable du projet
Debian.
</p>
<p>
Si vous n'êtes pas familiers de tous les détails de notre système de scrutin,
la méthode Condorcet avec abandon séquentiel sans clone/Schwarz, <i>Condorcet
with Cloneproof/Schwarz Sequential Dropping</i>, vous pouvez vous demander
pourquoi le projet Scud présente deux candidats. Notre point de vue est
cohérent avec les analyses d'Anthony Towns et d'autres mathématiciens, et la
méthode de scrutin de Debian n'entraînera pas de dispersion sur les candidats
de l'ensemble des votes pour le projet Scud.
</p>
<p>
Une des choses qu'une personne perdant des élections apprend est d'analyser ses
propres défauts. Je ne me nourris pas d'illusions en pensant être un parfait
candidat au poste de responsable du projet Debian, et je ne me sens pas à
l'aise avec les candidatures sorties du chapeau que des élections disputées
semblent créer. L'initiative du projet Scud en supprime même la tentation. Six
personnes peuvent souvent arriver là où une seule échouerait.
</p>
<h2 id="s4">Ce que je propose</h2>
<p>
Voici ce que je vous propose en tant que responsable du projet :
</p>
<ol class="spacey">
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">\
<strong>Un service ininterrompu de sept années dévoué à Debian.</strong>
En sept années, je n'ai jamais eu d'interruption prolongée. Même lorsque je
suis en vacances quelques jours, je m'efforce de passer, de récupérer mon
courriel, de dire bonjour à mes collègues sur les canaux IRC, et à faire le
tri dans les quelques bogues de sévérité importante remplis contre mes
paquets. Je suis là depuis un certain temps et je ne prévois pas de m'en
aller ;
</li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">\
<strong>Une base solide sur les questions techniques, légales et sociales.</strong>
XFree86 est un paquet connu pour la difficulté que l'on rencontre face aux
problèmes techniques — les gens qui étaient suffisamment sensés
pour ne pas l'avoir adopté sept ans plus tôt me l'ont dit. On me rencontre
sur la liste de diffusion <code>debian-legal</code> depuis quelques années,
et j'ai souvent été sollicité par mes collègues développeurs pour étudier
en détail les termes d'une licence et pour partager mes appréciations sur
leur conformité aux principes du logiciel libre selon Debian ainsi que pour
des questions de distribution et de responsabilité (cela dit, je préfère
m'en remettre à des avocats professionnels pour les conseils juridiques
actuels). J'ai aussi été responsable de la force de frappe X de Debian,
l'équipe d'entretien responsable du paquet XFree86 et des paquets associés
pendant plus d'un an, et comme indiqué précédemment j'ai été au bureau de
direction de SPI pendant plus de trois années. J'ai rencontré et discuté
avec des douzaines, peut-être même des centaines, de mes collègues dans le
projet et j'ai été à de nombreuses conférences où Debian était présent,
dont LinuxWorld à New York, LinuxWorld à San Francisco, l'exposition Linux
à Atlanta, et les conférences Debian (où j'ai fait des présentations). Je
tirerai de nombreux avantages de ces connaissances et de ces expériences en
tant que responsable du projet Debian ;
</li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">\
<strong>Du courage.</strong>
J'ai reçu mon lot de colères et de critiques au cours des années. Je ne me
suis pas affaibli de ces critiques — j'ai fait de mon mieux pour
apprendre d'elles, et, lorsque qu'on m'a persuadé que j'étais dans le faux,
j'ai ravalé ma fierté et admis mes erreurs (j'ai aussi de nombreuses
archives de mes courriels que je conserve pour les sceptiques
<code>:)</code>). Je crois que la position de responsable demande un
équilibre entre confiance et humilité, et que ces deux traits demandent du
courage. L'arrogance est réservée aux faibles. En tant que responsable du
projet Debian, je promets de représenter notre projet avec intégrité, cela
inclut de savoir quand et où d'autres peuvent mieux nous représenter ;
</li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">
<strong>De la ténacité.</strong>
Je ne suis pas quelqu'un qui abandonne facilement. Les problèmes du projet
Debian ont parfois des racines profondes, mais notre récompense à tous pour
les résoudre n'en sera que plus grande. Je crois que j'ai démontré au cours
des années passées que je n'abandonnais pas facilement une tâche que je
considérais importante. En tant que responsable du projet Debian, je
souhaite varier mon approche ou déléguer des responsabilités, mais je ne
délaisserai pas un problème tant qu'un consensus n'aura pas été trouvé dans
le projet pour dire que nous ne devons plus nous en occuper. Je suis
déterminé à créer un patrimoine dont nous puissions être fiers ;
</li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">\
<strong>Une détermination à l'ouverture et à la visibilité.</strong>
Une contrepartie importante de la ténacité est l'exposition — se
casser les dents sur un problème peut causer du tort sans avoir la
possibilité de se rattraper grâce à ses collègues. Depuis presque deux
années, la nature de mes modifications (et celles d'autres) apportées aux
paquets entretenus par la force frappe X a été publiquement enregistrée
en détail sur la liste de diffusion <code>debian-x</code>. À plusieurs
occasions, des failles ou des erreurs d'inattentions ont été trouvées et
corrigées par d'autres avant même qu'elles n'entrent dans la distribution
instable de Debian. En tant que membre du bureau de SPI, j'ai appris
d'expérience que la visibilité n'est pas seulement souhaitable, mais
<strong>critique</strong> — en particulier lorsqu'il s'agit de
problèmes. Je poste régulièrement des comptes-rendus sur la liste de
diffusion <code>spi-private</code> que tous les membres contributifs de SPI
(et donc les développeurs Debian) peuvent lire et commenter. La position de
responsable du projet n'est pas un trou noir dans lequel les problèmes
complexes peuvent être jetés pour s'en débarrasser définitivement. En tant
que responsable du projet Debian, je promets de produire au moins un
rapport d'état sur la liste de diffusion <code>debian-devel-announce</code>
chaque mois, rapport dans lequel je détaillerai non seulement mes succès,
mais aussi les domaines où je n'ai pas été capable d'accomplir des progrès.
Armé de ces informations, je m'attends à ce que tout le corps des
développeurs Debian propose des idées et prenne part à la résolution des
défis qui nous font face.
</li>
<li style="padding-top: 0.5ex; padding-bottom: 0.5ex">\
<strong>Une vision.</strong>
Malgré les défis sur lesquels je me concentre, Debian continue d'être un
endroit passionnant où passer la majorité de mon temps libre (et même de ma
carrière). Nos engagements à doter les gens de liberté logicielle, de choix
réels, et de maîtrise technique plutôt que de les asservir aux ordinateurs
continue de m'inspirer, et ils sont les raisons qui font que je reste un
développeur. Dans notre organisation, nous sommes fortement égalitaires et
nous avons une hiérarchie aussi petite que possible. Se faire admettre dans
nos rang peut être un défi (et n'est parfois pas rapide), mais une fois
dans le projet, il y a peu d'obstacles pour les gens de talent. Les
enchaînements de rencontres DebConf (pour lesquelles l'un de mes collègues
candidat et membre du projet Scud, Andreas Schuldei, mérite beaucoup de
récompenses) renforcent notre sens de la camaraderie, ce qui nous rend en
fin de compte plus productifs et plus résistants aux turbulences
extérieures. En tant que responsable du projet Debian, je conserverai ces
valeurs, essentielles à notre identité, au centre de mes travaux pour
résoudre nos problèmes les plus pressants. Dans de nombreuses occasions, je
pense que ces valeurs peuvent nous aider à trouver la voie vers des
solutions. Un axiome essentiel de tout rôle d'intendance est
« laissez-le dans un meilleur état que lorsque vous l'avez
trouvé ». En tant que responsable, je suis déterminé à entretenir
cette essence vitale pour notre projet, essence qui a conservé mon
engagement toutes ces années.
</li>
</ol>
<p>
Je vous remercie de votre participation aux élections cette année. C'est un
honneur de servir le projet Debian et ses idéaux.
</p>
</div>
<h2>Réfutation</h2>
<div>
<p>
Je me suis toujours trouvé dans une situation un peu inconfortable avec la
partie « réfutation » de la campagne pour l'élection du responsable
du projet Debian, partie demandée par le secrétaire du projet. Je ne cherche
pas à défier les affirmations ou la sincérité d'un quelconque de mes
cocandidats. Se présenter à l'élection du responsable du projet Debian et se
soumettre au haut niveau d'examen que le processus implique demande déjà pas
mal de hardiesse. En conséquence, j'aimerais présenter mes réflexions sur les
forces des autres candidats, plutôt que d'essayer de faire ressortir leurs
faiblesses.
</p>
<p>
Je pense que j'ai beaucoup de choses en commun avec Matthew Garrett dans le
sens ou nous avons tous deux de fortes personnalités. Aucun de nous ne se
dérobe pour relever le défi d'un <i>status quo</i>. J'admire l'exubérance que
Matthew apporte dans son travail pour le projet Debian.
</p>
<p>
Anthony Towns a une longue histoire avec le projet et a été intimement impliqué
dans certaines parties les plus importantes de son infrastructure. Je pense
qu'il apporte une « vue de l'intérieur » nécessaire aux délibérations
de cette année. Anthony et moi nous ressemblons aussi car nous apprécions tous
deux le genre d'engagement qu'offre un bon débat.
</p>
<p>
J'ai beaucoup de respet pour Andreas Schuldei qui est mon camarade dans le
projet d'un groupe de responsables. J'apprécie beaucoup son investissement pour
s'assurer que les aspects sociaux du projet Debian restent aussi bon que les
aspects techniques.
</p>
<p>
Je ne connais pas très bien Angus Lees, mais quelqu'un qui a la patience
d'entretenir des modules Perl détient des qualités que je n'ai
pas. <code>:)</code>
</p>
<p>
Jonathan Walther a été très important, je crois, pour nous aider à mieux
comprendre qui nous sommes et qui nous ne sommes pas. Je dois aussi confesser
qu'étant donné ce que j'entretiens, j'envie un codéveloppeur qu'un n'a aucun
bogue en cours contre ses paquets. Je ne pense même pas en rêve à un tel état.
</p>
<p>
Tous ces candidats ont quelque chose à nous offrir, mais je crois que je
conviens le mieux pour les défis qu'affrontera le prochain responsable du
projet Debian. Je me prépare pour ce rôle de puis plus longtemps que mes
adversaires. D'autres approches ont été prises, mais le travail à venir
requiert la combinaison d'assurance, de franchise et de responsabilité que
j'apporte. Avec le soutien de mes coéquipiers et de tous les développeurs, je
suis convaincu que je peux nous sortir des pires difficultés qui nous font
face. Avec votre soutien, je pense que nous serons tous capable de nous
regarder dans un miroir en mars 2006 et de ressentir un sentiment tout à
fait justifier de fierté. Je vous demande humblement de voter pour moi.
</p>
</div>
#use wml::debian::template title="Programme d'Angus Lees" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.2" maintainer="Nicolas Bertolissio" #include "$(ENGLISHDIR)/vote/style.inc" <h1 class="title">Programme d'Angus Lees</h1> <h2>Qui est Angus Lees ?</h2> <p> La plupart d'entre vous n'a probablement jamais entendu parler de moi. Je suis devenu développeur Debian en 2000 après avoir utilisé Linux depuis 1995. J'ai 28 ans, je suis marié et j'ai trois enfants. Je travaille comme développeur dans une petite entreprise qui produit des routeurs gérés à partir de Debian. J'entretiens quelques paquets Perl, dont le plus connu est Defoma ; mais je n'en suis pas l'auteur original alors veuillez ne pas m'en tenir rigueur. </p> <p> J'essaye de ne pas passer trop de temps en courriels ou sur IRC, d'où ma discrétion dans Debian d'un point de vue mondial. En Australie, cependant, j'essaye de rencontrer des gens à chaque fois que je peux et j'ai fait des présentations lors de <a href="http://www.debconf.org/miniconf3/";>\ miniconférences Debian</a> passées ainsi que d'autres événements Debian en Australie. J'aimerais penser que la plupart des développeurs Debian australiens puisse mettre un visage sur mon nom. </p> <h2>Pourquoi suis-je candidat au poste de responsable du projet Debian ?</h2> <p> Tous les ans, chaque candidat au poste de responsable du projet Debian énumère les problèmes que rencontre Debian et met en avant des belles solutions qu'il promet d'implanter en tant que responsable du projet Debian. C'est invariablement suivi d'une discussion montrant que la position du responsable du projet Debian ne comporte pas réellement de pouvoir direct et que presque toutes ces solutions peuvent être implantées tout aussi facilement par le développeur Debian moyen. En fait, la constitution dit clairement que le responsable du projet Debian devrait représenter les points de vue du projet et non mettre en avant les siens. </p> <p> La principale fonction du responsable du projet Debian telle que je la vois est d'agir comme une potiche — juste un contact pour présenter Debian au monde extérieur. En conséquence, il me semble que les plus importantes des qualités d'un bon responsable du projet sont de la disponibilité, des compétences en communication écrite et orale, de la personnalité et de l'expérience de développeur Debian. </p> <p> Je pense que les développeurs les plus proches des problèmes ou des comités et des délégués désignés sont plus à même de s'occuper des problèmes particuliers. Entre autres choses, j'ai quelques idées sur la manière d'améliorer la communication à l'intérieur de Debian et j'essayerai d'insuffler une attitude de tolérance et une communication plus efficace aux listes de diffusion. J'espère que cela permettra de s'occuper plus facilement des problèmes plus larges, tels que le caractère libre. Cependant, de manière générale, je sens que Debian fonctionne à peu près et je ne suis <em>pas</em> candidat au poste de responsable du projet Debian parce que j'attends de cette position qu'elle me donne le pouvoir de changer cela. </p> <p> Je suis un orateur correct qui peut communiquer sur les procédés, les idéaux et le renom de Debian aux autres. Je suis indépendant — je ne m'implique pas dans les trolls, je ne suis lié à aucune faction à l'intérieur de Debian, et je ne travaille pas pour une entreprise qui a un intérêt particulier dans Debian. Je m'entends facilement avec les gens et j'ai de l'expérience dans la gestion d'organismes bénévoles. </p> <p> En bref, je suis candidat à l'élection du responsable du projet Debian car je crois que je peux faire un travail extraordinaire. </p> <h2>Mais que pensez-vous de… ?</h2> <p> Cela étant dit, je réalise que vous ne pouvez pas avoir confiance en quelqu'un que vous ne pouvez pas prévoir et que personne ne va voter pour quelqu'un en qui il n'a pas confiance. Alors pour fournir un peu de matière, je débattrai de ce que je pense de quelques problèmes de Debian. Comme je l'ai indiqué ci-dessus, je n'ai pas forcément les bonnes solutions et je ne prévois certainement pas d'utiliser un quelconque privilège de responsable du projet Debian pour les mettre en avant. Pour être bien clair que cela ne devrait pas être directement lié à l'élection du responsable du projet Debian, je les ai placés sur une <a href="http://people.debian.org/~gus/debian-thoughts.html";>\ page séparée</a>. Je serais heureux de compléter ou de préciser tout point si quelqu'un pense que mon avis pourrait affecter son vote. </p> <p> Si je ne poste pas sur les listes Debian souvent, je suis les problèmes sur les listes de diffusion de Debian et de SPI et je débats souvent de ces sujets avec d'autres développeurs Debian autour d'une bière. Si vous regardez les débats animés sur les listes de diffusion de Debian, vous verrez la même douzaine de noms se répéter sans cesse mais rarement le mien. Je crois que je suis capable de représenter la « majorité silencieuse » des développeurs Debian, majorité qui suit une ligne médiane quelque part, pense que Debian est en général sur la bonne voie et souhaite simplement continuer à faire du bon travail. </p> <h2>Votez Angus Lees comme responsable du projet Debian</h2> <p> En gardant à l'esprit les réalités de la position de responsable du projet Debian, j'espère que vous voterez en fonction de la capacité et de l'à-propos, pas simplement de la réputation. </p> <h2>Réfutation</h2> <p> Il est intéressant de noter que pratiquement tous les points soulevés dans les programmes des autres candidats et les questions posées sur debian-vote concernent des problèmes internes à Debian. Bien qu'il soit bon que ces discussions se tiennent de façon si constructive, il est dommage que l'élection du responsable du projet Debian soit vue comme le moment pour les soulever. Il est naïf de s'en tenir au fait que le candidat qui propose une solution est nécessairement la meilleure personne pour l'implanter. Toutes les discussions et presque toutes les solutions ne tirent aucun bénéfice de l'autorité du responsable du projet Debian et pourraient être implantées à n'importe quel moment par tout développeur. </p> <p> Je dois desservir une mention particulière, deux des candidats de cette année sont membre de l'« équipe scud ». Au premier coup d'œil, cela semble une idée raisonnable — les équipes ont été utiles dans d'autres domaines de Debian auparavant. Il ne faut cependant pas longtemps pour réaliser que les responsables du projet Debian précédents n'ont jamais pris de décision seuls et que l'équipe n'a pas de bénéfice réel par rapport aux pratiques existantes. En fait, je suis inquiet car tenter de formaliser cette disposition apport de nouveaux problèmes, comme la résolution des désaccords, des domaines de responsabilité flous, un processus de sélection des membres de l'équipe opaque et plus de distance entre le développeur moyen et la « direction ». En bref : avec l'équipe scud, <em>c'est</em> une cabale. </p> <p> Le rôle interne du responsable du projet Debian est très important mais des similitudes des programmes de chaque candidat, nous pouvons voir que l'identification des questions clefs, telles que la communication et la publication de Sarge, n'est pas si difficile que cela. En prenant une approche calme, compréhensible et raisonnée, les solutions sont aussi raisonnablement directes et cohérentes. À moins que vous n'ayant une raison de croire qu'un candidat particulier aura des difficultés à travailler à une solution avec les autres développeurs, je ne pense pas qu'il soit efficace d'essayer de comparer les candidats sur ces questions. </p> <p> Il est bien plus difficile de juger si un candidat convient pour les devoirs <em>externes</em> du responsable du projet Debian. Cette partie n'a pas été évoquée par les autres candidats, mais en tant que responsable du projet Debian je crois qu'il est important de voyager et de montrer Debian aux personnes extérieures au projet. Malheureusement, il est très difficile de prédire comment un candidat se représentera et représentera Debian sans l'avoir rencontrer en personne. Comme cela dépend fortement de la personnalité et de l'aptitude à prendre la parole, je suis désolé de ne pas avoir de preuve codable par MIME (NdT : une manière de coder des types de données, par exemple des fichiers joints à un courriel) pour démontrer en plus de cette déclaration que je crois convenir pour ces tâches et vous permettre d'effectuer vous-même la comparaison entre les candidats. </p> <p> En résumé, lorsque vous déposerez votre bulletin, je vous invite instamment à choisir votre responsable du projet Debian en fonction des qualités intrinsèques des candidats, comme la personnalité, l'indépendance et les compétences, plutôt que de voter en fonction de solutions éphémères aux sujets chauds du moment. </p>
#use wml::debian::template title="Programme de Matthew Garrett" BARETITLE="true" NOHEADER="true"
#use wml::debian::translation-check translation="1.3" maintainer="Nicolas Bertolissio"
#include "$(ENGLISHDIR)/vote/style.inc"
<h1 class="title">Programme de Matthew Garrett</h1>
<h2>Introduction</h2>
<p>
Je m'appelle Matthew Garrett et je suis candidat au poste de responsable du
projet Debian. Je suis développeur Debian depuis 2002. À l'intérieur de
Debian, j'ai été impliqué dans l'entretien de paquets, dans le portage de
Debian vers des noyaux non-Linux et dans des discussions concernant les
problèmes techniques et philosophiques environnant le projet. Cela comprend des
négociations avec des détenteurs de droit d'auteur pour essayer d'obtenir des
logiciels sous une licence libre compatible avec les principes du logiciel
libre selon Debian, l'analyse du caractère libre (ou non) de licences et la
défense de ce que je considère comme des standards libres appropriés pour
Debian. Je représente Debian au bureau consultatif de Gnome, je fais la liaison
avec des représentants de Sun, Novell, Red Hat, IBM et d'autres. À ce sujet,
j'ai obtenu l'engagement que Gnome ne dépende pas de fonctionnalités Java non
libres. À l'extérieur de Debian, j'ai été développeur principal du projet
dasher (une application d'accessibilité), j'ai travaillé à améliorer l'état du
support par Linux de la suspension et la reprise avec l'interface avancée de
configuration et de gestion de l'énergie (<i>ACPI</i>) et je contribue au
projet Gnome.
</p>
<p>
Dans la vie, je suis doctorant en biologie calculatoire au
département de génétique de l'université de Cambridge. J'ai l'intention
d'utiliser mes compétences au bénéfice des forces du bien.
</p>
<h2>Les sujets que doit affronter Debian</h2>
<h3>Communication</h3>
<p>
La communication interne de Debian est pauvre actuellement. Les standards de
communications qu'attendent les équipes qui sont responsables de la plupart de
l'infrastructure du projet ne sont pas clairs. En même temps, les informations
sont parfois demandées d'une manière qui n'encourage pas les équipes à
répondre. L'ensemble de cela fait que tout le monde est mécontent de la
communication.
</p>
<p>
Vous pouvez retrouver dans ce problème des débats aussi classiques que pourquoi
des paquets ne sont pas encore construits pour certaines architectures,
pourquoi quelqu'un n'a pas été accepté comme responsable et beaucoup d'autres.
Ces disputes produisent rarement des discussions utiles, consument du temps qui
pourrait être dépensé ailleurs et entretiennent la perception d'une atmosphère
agressive dans Debian. Le manque de communication engendre aussi chez les gens
une mauvaise image de ce qui se trouve entre l'état actuel de Debian et notre
version publiée. Notre mauvaise communication est le seul et le plus important
des problèmes que le projet doit affronter actuellement. Il doit être corrigé.
</p>
<h3>Consensus</h3>
<p>
Debian est un projet de logiciels libres. La discussion sur la résolution
générale qui a modifié le contrat social (et bien plus de débat que vous ne
pourriez l'imaginer sur debian-legal) montre que les gens ont des critères très
différents de ce que « libre » signifie dans ce cas. J'ai constamment
défendu mes convictions sur la liberté contre la ligne la plus dure des
définitions qui ont été développées, mais il n'est pas facile de savoir laquelle
de ces définitions correspond au plus près à ce que pensent les développeurs.
</p>
<p>
Une divergence fondamentale de ce type entraîne encore plus de débat, mais il
n'y a actuellement aucun moyen pour déterminer quelle est la bonne définition.
Depuis que le contrat social a été écrit, le monde a changé et les questions
pour lesquelles nous nous battons maintenant n'avaient jamais été imaginées en
ce temps-là. L'une des conséquences est que nous sommes incapables de nous
mettre d'accord sur l'acceptation (ou pas) de licences qui cherchent à protéger
les gens des poursuites sur les brevets. Et peut-être pire, le manque d'accord
sur ce en quoi nous croyons rend plus difficile la pression pour nos
convictions. Si je suis élu, je ferai tout mon possible pour aider Debian à
atteindre un accord sur ce en quoi nous croyons.
</p>
<h3>Autres</h3>
<p>
Ce ne sont pas les seuls problèmes que rencontre Debian et je crois que la
plupart des autres problèmes sont la conséquence de ceux-ci. Nous avons échoué
à publier une version car des nouvelles questions n'arrêtent pas de se poser.
Avec une communication adéquate, une grande partie de ce délai aurait pu être
évitée. L'approche des questions de licence par Debian est souvent critiquée,
mais il nous est difficile de répondre car nous manquons d'un consensus
suffisant à l'intérieur même du projet.
</p>
<p>
Il se pourrait bien que certains autres problèmes ne soient la conséquence
d'aucune des deux questions que j'ai soulevées — la communication et
le consensus. Quoi qu'il en soit, je crois qu'ils sont assez négligeables en
comparaison. Nous devrions nous concentrer à corriger les carences principales
avant de nous inquiéter d'une multitude d'autres plus mineures.
</p>
<h2>Ce que je ferai pour cela</h2>
<h3>Améliorer la communication</h3>
<p>
Après les élections, je contacterai chaque équipe pour discuter de la façon
qu'elle considère la meilleure pour communiquer avec le reste du projet. Cette
information sera documentée et rendue publique. Ensuite, s'il y a des plaintes
sur la communication inadéquate d'une équipe, j'examinerai la question et ferai
ce que je pourrai pour m'assurer que la situation ne se reproduise pas. Dans le
cas où une équipe faillirait à maintenir une communication adéquate avec le
reste du projet, je ferai tout ce qui sera nécessaire pour m'assurer que le
problème sera corrigé. Il est inacceptable que le développement soit ralenti
parce que certaines personnes ne sont pas sûres de ce qui se passe. Quoi qu'il
en soit, il est également inacceptable que des développeurs abusent des membres
d'une équipe. Les développeurs qui sont incapables de communiquer de façon
raisonnable ne doivent pas s'attendre à recevoir de retours utiles, et cela
doit être accepté par la communauté.
</p>
<p>
Dans le passé, Debian était plus petit et la communication entre les personnes
était plus facile. Maintenant nous avons grossi au point qu'il est parfois
difficile de se rappeler que chaque personne impliquée est un bénévole. Cela
ne modifie en rien l'importance de la communication et ce doit être le travail
du responsable du projet de s'assurer que cette communication vitale existe.
</p>
<h3>Construire un consensus pour l'avenir</h3>
<p>
Après la publication de Sarge, j'engagerai un débat sur le contrat social. Il
sera scindé en deux parties :
</p>
<ul>
<li>
<p>
une discussion sur les standards que Debian devrait suivre.
</p>
<p>
J'introduirai de nouveaux sujets de discussion à des intervalles
réguliers. Les anciens fils de discussion sur debian-project ont montré
que le débat sur des questions comme l'acceptabilité des licences de
brevets peut se tenir de façon sécurisante avec un rapport signal sur bruit
important. J'ai donc confiance en la possibilité d'arriver à des
conclusions raisonnables ;
</p>
</li>
<li>
<p>
la détermination du fait que le contrat social actuel reflète ce que nous
souhaitons que Debian soit et, sinon, de ce qu'il faudrait modifier.
</p>
<p>
Je m'attends à ce que cela découle naturellement de la première partie.
Dans la plupart des cas, le sens du contrat social est clair. S'il y a un
signe clair que le point de vue consensuel est en désaccord avec ce sens,
toutes les modifications requises devraient être assez évidentes.
</p>
</li>
</ul>
<p>
S'il devenait clair que le contrat social actuel ne reflétait pas les
convictions des gens à propos de Debian, alors je travaillerais à écrire une
version préliminaire de résolution générale pour le modifier. Je chercherais à
m'assurer que les répercussions de toutes les modifications soient bien
comprises <em>avant</em> de procéder au vote, afin d'éviter une controverse sur
les résultats ensuite. Bien que ce processus entraîne sans aucun doute de longs
débats enflammés, je pense qu'ils réduiront les désaccords sur ce que Debian
représente à l'avenir.
</p>
<h3>La publication des versions</h3>
<p>
Au moment où j'écris ces lignes, cela fait 31 mois que la dernière
version de Debian a été publiée, en juillet 2002. Cela n'est pas
acceptable. L'équipe de publication a été entravée par des problèmes de
communications entre les équipes, ce qui a fait que des problèmes bloquant la
publication n'ont pas pu être découverts avant qu'il ne soit trop tard pour
les éviter. Je travaillerai avec l'équipe de publication pour m'assurer que les
soucis potentiels soient exprimés clairement à l'avance et pour m'assurer que
l'on travaillera activement dessus. Une meilleure communication n'entraînera
pas directement une publication plus rapide, mais elle permettra de montrer
quels progrès ont besoin d'être réalisés avant que la publication ne
survienne.
</p>
<p>
Veuillez remarquer que des publications plus rapides engendreront d'autres
problèmes, augmentant le nombre de versions que nous devrons entretenir en même
temps. Je me rapprocherai de l'équipe de sécurité et du gestionnaire de la
version stable pour m'assurer que nos utilisateurs ne soient pas obligés de
faire trop de mises à jour ou ne doivent utiliser une distribution qui n'ait
plus de support de la sécurité.
</p>
<h2>Pourquoi je souhaite faire cela</h2>
<p>
Je ne crois pas que le responsable du projet Debian devrait être responsable de
la gestion quotidienne de Debian. Je ne crois pas non plus que le responsable
du projet Debian devrait décider de la direction que devrait prendre le projet.
Je crois que ces responsabilités incombent aux développeurs du projet et aux
équipes qui ont autorité sur diverses sections de la distribution. Le rôle du
responsable du projet Debian devrait être de s'assurer qu'il est possible pour
chacun de tenir son rôle. Je crois que la meilleure manière d'y arriver est de
réduire les opportunités de conflits à l'intérieur du projet, d'améliorer la
communication, la transparence et le consensus. Les objectifs que j'ai
soulignés ci-dessus sont généraux, mais je crois fortement qu'ils sont les plus
importants dont le projet ait à s'occuper et je crois qu'ils seront réalisés le
plus facilement grâce aux pouvoirs conférés au responsable du projet Debian.
<h2>Pourquoi moi ?</h2>
<p>
À la fois dans et hors de Debian, j'ai montré ma capacité à engager des
discussions sans confrontation. J'ai de bonnes relations avec les membres de la
majorité des équipes de délégués dans Debian, ce qui m'a permis de travailler
sur de la documentation pour fournir des informations sur leurs rôles et leurs
responsabilités au sein de Debian. J'ai représenté Debian avec succès auprès de
figures de l'industrie, m'assurant que nos préoccupations étaient entendues.
</p>
<p>
En résumé, je crois qu'atteindre un consensus et communiquer sont les défis les
plus importants que rencontre Debian actuellement, et qu'en tant que
responsable du projet Debian je serai capable de les relever.
</p>
<h2>Réfutation</h2>
<p>
Trois des autres candidats ont débattu de la façon dont le responsable du
projet Debian devrait effectivement déléguer des tâches. Anthony Towns
dit :
</p>
<blockquote>
J'ai la conviction que Debian pourrait s'améliorer ici simplement en donnant
aux délégués une autorité claire pour prendre des décisions dans leurs domaines
d'expertise, ainsi qu'en acceptant que l'on puisse persuader et convaincre les
délégués et les responsables de paquets que quelque chose pourrait être fait
d'une certaine façon.
</blockquote>
<p>
Et la proposition « Scud » de Branden Robinson et d'Andreas Schuldei
de désigner une équipe de délégués pour remplir de nombreux rôles du
responsable du projet Debian ont été largement débattus.
</p>
<p>
Il est vrai qu'il faudrait fournir aux délégués l'autorité de prendre des
décisions, et s'attendre à ce que la bonne décision puisse être prise sans
recevoir de critiques indues. Cependant, les délégués ont besoin d'être
responsables devant le projet entier, pas seulement le responsable du projet.
Il est tout à fait raisonnable que les développeurs demandent comment les
délégués sont arrivés à prendre certaines décisions, et tout à fait juste de
s'attendre à recevoir des réponses raisonnables. Si cela devait conduire à des
demandes inacceptables comparées à la disponibilité des délégués, nous devrions
nous saisir des causes principales du problème en nous assurant que les
délégués aient plus de ressources disponibles. Le manque de temps ne devrait
pas être une excuse pour le manque de responsabilité envers tout le projet.
</p>
<p>
Le projet Scud est une courageuse tentative pour résoudre les problèmes
historiques de communication entre les délégués, le responsable du projet
Debian et le reste du projet en élargissant la position de responsable du
projet Debian. Cependant j'ai quelques inquiétudes sur les mécanismes engagés.
Le rôle du responsable du projet est de s'assurer que la bonne personne fait le
bon travail, pas de s'occuper de ce travail lui-même. Andreas dit :
</p>
<blockquote>
des tâches plus petites sont déléguées au membre de l'équipe le plus
approprié.
</blockquote>
<p>
Au lieu de cela, je dirais que ces tâches devraient être déléguées au membre du
<em>projet</em> le plus approprié. Désigner des délégués à l'avance de cette
façon fait courir le risque de réduire la capacité du responsable du projet à
choisir la personne la plus appropriée pour ce travail en rendant plus
difficile la justification du choix de délégués supplémentaires.
</p>
<p>
Plutôt que de nommer une équipe à l'avance, je choisirai les délégués en
fonction des besoins comme décrit dans la constitution. Restreindre mon choix à
l'avance ne semble pas être la façon la meilleure de résoudre les problèmes
lorsqu'ils surviennent.
</p>
<p>
Comme je l'ai souligné dans mon programme, mes priorités sont d'améliorer la
communication et le consensus à l'intérieur du projet. Je ne crois pas que
fournir plus de pouvoir à un petit ensemble de personnes soit la manière la
meilleure pour résoudre ces problèmes. Le pouvoir devrait être distribuer à
travers tout le projet, pas concentré sur un petit sous-ensemble.
</p>
Attachment:
signature.asc
Description: Digital signature