[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

[rfr] webwml://vote/2000/leadership_debate/ben-speech.wml



-- 
#use wml::debian::template title="Déclaration préliminaire de Ben Collin"
#use wml::debian::translation-check translation="1.1" maintainer="Nicolas Bertolissio"

<p>
Ce que j'aimerai faire ici est en fait une vue d'ensemble de la faàon dont je
vois l'état actuel de Debian en tant que projet et que groupe. Au cours des
ans, le projet a crû dans tous les domaines, et commence à montrer certains des
défauts de notre structure. Voici les choses dont il faudra s'occuper dans les
années qui viennent pour que nous restions la force formidable de source ouvert
que nous étions. Fournir l'ensemble de logiciels le plus vaste pour l'nombre
d'architectures le plus grand est ce que nous faisons de mieux. Sans parler de
la stabilité et de la disponibilite supérieures de Debian.
</p>

<p>
Les domaines clés où nous avons des problèmes sont plus dans l'administration
et la collaboration. Par collaboration, je pense à la collaboration entre les
groupes, et par administration, je pense à la colle qui lie ces groupes et leur
fournit cohésion et productivité.
</p>

<p>
Aujourd'hui nous avons un seul «&nbsp;Dieu&nbsp;» comme le contrôle donné à
chaque responsable. Ils décident de ce qui arriver aux paquets qu'ils
contrôlent et quand. Nous ne pouvons pas modifier cela. Quoi qu'il en soit,
nous avons vraiment besoin de poursuivre dans cette voie. Nous commençons ç
voir le développement de nombreux sous-projets dans le projet Debian. Ces
projets, peu importe s'ils sont bien définis, n'ont pas d'infrastructure dans
les travaux actuels de Debian. Ces groupes ne sont pas même reconnus dans notre
constitution, ni dans notre modèle de développement. J'aimerais voir ces
groupes de travail prendre. La structure d'un groupe de base a besoin d'être
défini dans notre modèle de développement, en donnant à chaque groupe le
responsabilité de définir les spécificités de son modèle de développement.
Chaque groupe devrait également avoir des contacts prinmaires et secondaires
afin que les personnes clés du projet (le responsable du projet Debian, le
responsable de publication, les administrateur ftp, etc...) aient un unique
contact dans le groupe pour prendre des décisions. Quand bien même chaque
groupe devrait être reconnu, je pense que certains groupes pourront être
définis comme persistents. Ces groupes (pour les disquettes d'amorçage, les
porteurs, et...) seront impliqués dans des rencontres publiques régulières avec
les responsable du projet Debian et d'autres responsables du projet pour
s'assurer que tout est sur la bonne voie.
</p>

<p>
L'un des autres domaines clés dont on a, je pense, besoin de s'occuper et le
processus d'acceptation de nouveaux membres dans le groupe. Je sais bien que
Dale Sheetz a travaillé à la réouverture du processus du nouveau responsable.
Je loue ses efforts et ses soins attentifs pour le remettre en service. Quoi
qu'il en soit, ce n'est que la première étape pour résoudre certains problèmes
avec les nouveaux responsables. Je crois que nous avons besoin de plus
d'abstraction entre les «&nbsp;nouveaux&nbsp;» développeurs et les séniors
«&nbsp;depuis longtemps&nbsp;». Ce que je suggère, c'est qu'on donne des droits
limités aux nouveaux responsables lorsqu'ils nous rejoignent pour la première
fois (pas trop limités afin qu'ils puissent réaliser le travail que nous
acceptons qu'ils fassent). Ces limitations peuvent être de plusieurs niveaux.
Tout d'abord, ne pas leur permettre de faire des mises à jour indépendantes
d'autres paquets. Je pense que nous avons trop de problèmes avec les nouveaux
responsables qui, quand bien même ils ont l'intention de bien faire, causent
des dommages dans les paquets principaux. Ces limitations peuvent être faites
de plusieurs façons, même en leur permettant de faire des mises à jour
indépendantes _si_ leur fichier de modifications est signé par un développeur
«&nbsp;sénior&nbsp;» (très utile lors des fêtes de chasse au bogues). Nous
aurons besoins de critères pour qu'un dévelopeur devienne un
«&nbsp;senior&nbsp;» (évidemment tous les développeurs actuels seront considéré
comme des «&nbsp;séniors&nbsp;» si cela est mise en &oelig;uvre, une sort de
clause du grand-père&nbsp;:).
</p>

<p>
Enfin, mais pas en dernier dans mon agenda, vient la visibilité de Debian. Bien
des fois nous voyons que peu de gens (hors du cercle du source ouvert) savent
vraiment ce qu'est Debian et de quoi il s'agit. Je pense que nous avons
réellement besoin d'un groupe de personnes qui puisse nous porter sous les
projecteurs. Bien évidemment, aujourd'hui l'équipe de presse correspond à cette
description, mais je ne pense pas que nous ayons constaté de vrai initiative de
sa part (je ne sais pas s'il s'agir d'un manque d'intérêt de leur part, ou d'un
manque dans la charte sur ce qu'est sensé faire ce groupe). Nous devrions
également chercher à gagner notre autotsuffisance en rendant les CD disponibles
directement. Nous avons de nombreux développeurs qui souhaitent s'occuper de
cela. Donnons-leur un petit montant à dépenser pour cela, et plaçons les
bénéfices à la banque pour les dépenses futures (nous avons vraiment besoin de
commencer à acheter notre propre matériel).
</p>

<p>
C'est tout pour le moment, je viens juste de définir mes initiatives, mais j'ai
vraiment l'espoir de pouvoir finallement faire la différence en tant que votre
responsable du projer.
</p>

Attachment: signature.asc
Description: Digital signature


Reply to: