Voici les fichiers à relire (ouf...) --
#use wml::debian::template title="Programme d'Anthony Towns" 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'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 intelligentse des nouveaux venus et ne perdent pas plein de temps à revenir sur d'anciens sujets classés ou sur du hors sujet ; </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 ; </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 ; </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. </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 je pense 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. </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. </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 libre 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. </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 commencer à 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 proposer à 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 quelque temps déjà — je suis plus intéressé (et efficace) dans la conception initiale et l'implantation que sur l'entretient à 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 c'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>
#use wml::debian::template title="Programme d'Andreas Schuldei" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.2" 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é à 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 des 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 surchauffer 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étail 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 importantes 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, les risques 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'entretient 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 leur motivation 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 capable 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 est 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é les relations et le tons 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 dont les gens veulent, dans Debian comme dans tous les endroits ou 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 /> <h2>Réfutation</h2> <p> À venir. </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 responsables 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>
#use wml::debian::template title="Programme de Branden Robinson" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.2" 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és 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 directions 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 semble 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 demandes 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 ont été publiquement enregistrés 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'autre 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 rencontre DebConf (pour lesquelles l'un de mes collègues candidat et membre du projet Scud, Andreas Schuldei, mérite beaucoup de récompense) renforcent notre sens de la camaraderie, ce qui nous rend en fin de compte plus productifs et plus résistant 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>
#use wml::debian::template title="Programme de Jonathan Walther" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.1" maintainer="Nicolas Bertolissio" #include "$(ENGLISHDIR)/vote/style.inc" <h1 class="title">Programme de Jonathan Walther</h1> <h2>PUBLIER TÔT, PUBLIER SOUVENT</h2> <p> De nombreux utilisateurs ont abandonné Debian, ou choisi d'autres distributions sans même essayer Debian avant. Avec un cycle de publication régulier et cohérent comme celui d'OpenBSD, nous pouvons susciter un élan de popularité bien au-delà de celle dont nous jouissons déjà. Le mouvement engendre le mouvement, et en gérant soigneusement l'envoi d'impulsions, nous pouvons éblouir le monde avec une distribution qui sera attendue avec impatience aussi bien par des utilisateurs en bureautique que des gourous de serveurs. </p> <p> J'ai rejoint Debian en 1998 car c'était la meilleure des distributions GNU/Linux de la planète. Elle l'est toujours. Elle a simplement besoin d'être un peu dépoussiérée. Au cours des ans, j'ai vu notre dur labeur amorti lorsque d'autres l'ont incorporé dans des produits fantastiques comme Knoppix, Fink ou Ubuntu. En tant que responsable du projet Debian, ma première préoccupation sera notre calendrier de publication. J'ai montré par le passé ma capacité à éditer des logiciels dans les temps, selon le programme prévu. Le projet Xouvert, une version extraite du code source de X11, a été publiée deux fois, à six mois d'intervalle. Beaucoup de nos objectifs les plus ambitieux n'ont pas été atteints, mais nous avions une version qui fonctionnait directement, dans les temps, les deux fois. </p> <p> Avec la zone d'archive de Debian, nous avons toujours quelque chose à publier. Nous n'aurons pas besoin de faire le moindre compromis avec nos standards de haute qualité. Si un nouveau logiciel n'est pas prêt à entrer dans l'édition stable, il n'y rentrera tous simplement pas. Avec un cycle de publication régulier, ce n'est pas un problème ; il y a toujours une nouvelle édition six moins plus tard. Ubuntu et Xouvert ont tous deux emprunté le concept de six mois d'OpenBSD. C'est prouvé, ça fonctionne, et cela transformera Debian en une fabrique monstre de bonté logicielle. </p> <h2>AU SUJET DE LA PARITÉ</h2> <p> Récemment, la disproportion entre le nombre de développeurs de sexe masculin et féminin dans Debian a soulevé de plus en plus d'intérêt. Dès que je serai élu, je chargerai les personnes suivantes d'examiner en profondeur notre processus du nouveau responsable et de produire un compte-rendu sur les obstacles qui empêchent les femmes d'entrer dans Debian, ainsi que des recommandations pour les éliminer. </p> <ul> <li>Sandra Chua</li> <li>Helen Faulkner</li> <li>Carla Schroder,</li> <li>Erinn Clark</li> <li>Margarita Manterola</li> <li>Jutta Wrage</li> <li>Matthew Palmer</li> <li>Michael Banck,</li> <li>Matt Zimmerman</li> <li>Luk Claes</li> <li>Enrico Zini</li> <li>Christian Perrier</li> </ul> <p> Ils auront trois mois pour préparer leur rapport qui sera posté sur le site de Debian afin d'être utilisé dans de futures résolutions générales. </p> <p> J'inviterai personnellement les experts sur les inégalités sexuelles Gloria Steinem et Germaine Greer à présider ce comité et à participer autant qu'elles le souhaitent. Leurs conclusions et leurs réponses seront incluses sur le site de Debian. </p> <h2>QUI EST DJW ?</h2> <p> J'ai commencé à programmer sur un Commodore 64 en 1987, puis j'ai passé une licence en Pascal, en C et en C++ dans une grande école. Lorsqu'internet est arrivé dans mon école en 1993, je suis tombé sur Linux et le logiciel libre presque immédiatement, et j'ai su que c'était l'avenir. Les places de programmeurs étaient rares pour les jeunes programmeurs de logiciels libres dans les grands territoires du Nord du Canada, alors j'ai fait du stop en Amérique du Nord en rencontrant d'autres développeurs Debian, cherchant du travail, et développant mes compétences de programmeur avec les livres de <a href="http://www.kohala.com/start/">Richard Stevens</a>. Enfin je me suis installé dans la <a href="http://vancouver.ca/aboutvan.htm">Grande Ville</a> (NdT Vancouver) en 1998 et j'ai pris part à de nombreux projets intéressant depuis. </p> <p> Je brasse ma propre bière biologique et j'aime inviter des amis et des collègues développeurs à la boire. Une bière n'est pas une bière sans débats spirituels sur de nombreux sujets. Lorsqu'ils vivaient dans ma ville, j'ai hébergé les rassemblements ratpoison. Ratpoison est un gestionnaire de fenêtres si léger et si dépouillé que vous pensez utiliser la console Linux. Ai-je mentionné que j'ai horreur de ce qui prend de la place ? </p> <h2>APTITUDE ET CAPACITÉ À DIRIGER</h2> <p> Ma personnalité selon le test de Meyers-Brigg est <a href="http://reactor-core.org/~djw/entj.html">ENTJ</a>, la personne née pour diriger naturellement. En complément, je suis un orateur doué, plaisant, poli et j'écoute très bien les autres. Ce sont toutes les qualités qui peuvent construire ou détruire un responsable du projet Debian et qui ont un impact direct sur le projet. Le sens de l'humour est également important, et le mien est plus gros qu'un éléphant. Même un fusil à éléphant ne peut pas le détruire ! </p> <p> Mon expérience de la prise de parole en public comprend des présentations au groupe d'utilisateurs Linux local, ainsi que des exposés publics professionnels et paroissiaux. En tant que Canadien c'est peut-être un talent naturel, mais j'excelle à encourager le consensus, même dans des environnements hostiles. </p> <p> J'obtiens des résultats. Le standard des <a href="http://reactor-core.org/ogg-tagging.html">étiquettes Ogg</a> s'est très largement répandu ces dernières années car c'était un besoin voulu par une communauté d'utilisateurs. Si je ne l'avais pas porté, ce ne serait pas arrivé. Lorsqu'OpenBSD a décidé de ne pas fournir de support multiprocesseur pour la plate-forme PowerPC à cause du manque de matériel, j'ai lancé une souscription massive. Vous pouvez voir le résultat de son succès <a href="http://www.dalerahn.com/~drahn/G5rcpt.jpg">ici</a>. Je concentre mes efforts là où ils peuvent faire le plus de bien. Cette année, ils peuvent apporter le plus de bien en tant que votre responsable du projet Debian. </p> <p> Compassion, tolérance et humilité sont essentielles pour que tout projet avance correctement. Si l'une de ces qualités devait me manquer, je suis certain qu'on me le ferait remarquer rapidement. Quels que soient mes autres défauts, vous pouvez être sûr que j'écouterai toujours ce que vous avez à dire. En tant que responsable du projet Debian, je pourrais être amener à prendre des décisions que vous désapprouveriez, mais votre opinion comptera toujours. </p> <p> Ce qui rend Debian fantastique est que nous sommes une équipe. Nous avons de nombreux membres expérimentés avec des décennies d'expérience de la conception, et un engagement dévoué à travailler ensemble qui a su franchir les barrières des langues, des culture et des opinions politiques. En tant que responsable du projet Debian, je suis le candidat idéal pour représenter la diversité de visions et d'intérêts qui forment notre projet. </p> <p> Rendez-vous au scrutin ! </p>
#use wml::debian::template title="Programme de Matthew Garrett" BARETITLE="true" NOHEADER="true" #use wml::debian::translation-check translation="1.1" 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 étudiant de doctorat 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és, 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 sures 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 volontaire. 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és 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 dans 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 publications 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 besoins 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 au pouvoir 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>
Attachment:
signature.asc
Description: Digital signature