Nous réalisons dans le cadre d'un cours à l'ENST une petite enquête sur les bug-squashing parties (bsp) de Debian. Il nous serait très utile d'obtenir des informations de première main; pourriez-vous parcourir le questionnaire ci-dessous et répondre aux questions qui vous semblent pertinentes ? Bien entendu, toute autre information (ou suggestion de question) que vous pourriez nous communiquer concernant les bsp sera la bienvenue. En particulier, si vous connaissez d'autres personnes susceptibles de répondre à nos questions, cela nous permettrait d'affiner l'enquête. Merci d'avance pour votre aide. Aurélien Chanudet Alain Frisch Sylvain Leroy Marc Menem 0. Cette enquête donnera lieu à un compte-rendu; avez-vous une objection à ce que certaines de vos réponses soient citées ? Souhaitez-vous qu'elles le soient anonymement ? (vous pouvez bien entendu préciser au cas par cas dans chaque réponse) I. Debian et vous ----------------- 1. Quel rôle jouez-vous dans Debian ? Depuis combien de temps ? De quels packages vous occupez-vous ? 2. Comment en êtes-vous venu à vous impliquer dans Debian ? 3. Y a-t-il eu des retombées de votre participation à Debian dans votre vie professionnelle ? En attendez-vous ? II. Les bug-squashing parties ----------------------------- 1. Histoire des bsp: quand sont-elles apparues ? Sous quelle forme ? Sous quelle impulsion ? Y a-t-il quelque part une "archive" des bsp, avec les annonces, comptes-rendus et statistiques de bugs résolus ? 2. Quelles releases/packages sont concernés ? À quel moment dans le cycle des distributions interviennent les bsp ? 3. Quel est le déroulement exact ? Les participants préparent-ils leur intervention, y a-t-il un ordre du jour établi, ou cela se decide-t-il au fur et à mesure ? Y a-t-il des règles particulières lors de la discussion, des conventions implicites ou explicites ? 4. Qui décide des dates ? Qui s'occupe des annonces ? Est-ce un processus communautaire (sur debian-devel) ? Quel rôle joue Debian-qa dans l'organisation des bsp ? 5. Quels types de bugs sont concernés ? Qu'est-ce qu'un bug critique, et qui est compétent pour déclarer critique un bug ? Les bugs sont-ils toujours résolus en direct ? Est-il courant qu'un groupe qui s'est penché sur un bug continue à y travailler en collaboration après la fin d'une bsp ? 6. S'agit-il exclusivement de bugs spécifiques à la distribution Debian ? Est-ce que les corrections peuvent concerner les distributions originales des programmes ? Le cas échéant, comment les informations sont elles remontées aux programmeurs ? 7. Combien y a-t-il en général de participants ? Observe-t-on un évolution dans le "taux de participation" ? Quels types de membres de la communauté Debian sont invités à participer et quels sont leurs contributions respectives ? 8. Les logs sont-ils conservés ? Si oui, sont-ils publics ? 9. Se passe-t-il autre chose que les investigations et résolutions de bugs (discussions techniques plus générales, bavardage, ...) ? Y a-t-il un "arbitre" pour éviter que les discussions divergent ou s'enflamment ? 10. Y a-t-il des bsp In Real Life ? III. Efficacité --------------- 1. Quel jugement portez-vous sur l'efficacité des bsp ? Auriez-vous des propositions à faire pour l'améliorer l'efficacité? Les corrections de bug effectuées lors d'une bsp ont-elles un niveau de qualité comparables aux autres corrections (risque de bâcler le travail pour aller vite, ou au contraire plus grande attention car travail plus visible) ? 2. L'interactivité d'IRC est-elle un élément important dans l'efficacité des bsp ? IRC est-il adapté à des discussions techniques (difficultés à suivre la trame du discours, à pointer un bout de code, à retrouver une discussion sur un sujet précis, ...) ? Pensez-vous que des outils techniques pourraient améliorer les choses (intégrer un chat directement dans l'outil de suivi de bugs) ? Avez-vous des idées ou des propositions dans ce sens ? 3. Y a-t-il une émulation particulière, comme s'il s'agissait d'un "concours" ? 4. Que pensez-vous du "format" temporel des bsp ? Comment s'est fixée la durée actuelle (3 jours) ? Selon vous, l'efficacité serait-elle affectée par un allongement sensible ? 5. Pensez-vous que le modèle des bsp pourrait se généraliser et être bénéfique à d'autres développements open-source de grande taille ? Est-ce selon vous un complément important d'un outil classique de suivi de bugs dans le cadre d'une politique de qualité logicielle ? Connaissez-vous des analogues dans d'autres projets (open-source ou non) ? IV. Questions humaines ---------------------- 1. Un responsable de package peut-il s'opposer à ce que l'on touche à son package lors d'une bsp ? S'agit-il d'une opposition formelle? Cela est-il codifié ? Respecté ? Quelles sont les raisons avancées pour ce genre d'opposition ? Qu'en pensez-vous ? Les bsp ne remettent-elles pas en cause la politique "un paquet - un unique mainteneur" (alors que pour certains projets comme KDE, ou comme XFree86 ça represente un travail énorme et ça peut traîner) ? 2. Pouvez-vous citer des exemples de conflits provoqués lors d'une bsp (avec un responsable de package, entre participants qui ne sont pas d'accord, ...) ? Comment se sont-ils réglés ? 3. Y a-t-il un rôle social joué par les bsp ? Contribuent-elles à créer un esprit communautaire, à faire se rencontrer des gens qui s'occupent de packages différents, à créer des "groupes de travail" sur des points techniques ? 4. Un membre de la communauté Debian est-il incité à participer aux bsp ? La participation joue-t-elle un rôle implicite dans la réputation, la reconnaissance des pairs ?