Bug tracking is a broad topic; various aspects of it are discussed throughout this book. Here I'll try to concentrate mainly on setup and technical considerations, but to get to those, we have to start with a policy question: exactly what kind of information should be kept in a bug tracker?
Vaste sujet que le suivi de bogues, au travers de ce livre nous en abordons différents aspects. Ici je me concentrerai principalement sur l'installation et les considérations techniques, mais avant d'aborder ces points nous devons commencer avec une question de règles : quel genre d'informations exactement doivent être conservées dans le système de suivi de bogues ?
The term bug tracker is misleading. Bug tracking systems are also frequently used to track new feature requests, one-time tasks, unsolicited patches—really anything that has distinct beginning and end states, with optional transition states in between, and that accrues information over its lifetime. For this reason, bug trackers are also called issue trackers, defect trackers, artifact trackers, request trackers, trouble ticket systems, etc. See Appendix B, Free Bug Trackers for a list of software.
Le terme suivi de bogue est trompeur. Les systèmes de suivi de bogues sont souvent utilisés aussi pour les demandes de nouvelles fonctionnalités, des tâches ponctuelles, des correctifs non-sollicités, vraiment tout ce qui peut avoir un état initial et un état final différent, avec des états de transitions optionnels et qui accumule des informations au cours de son existence. Pour cette raison, les systèmes de suivi de bogues sont également appelés systèmes de suivi de problèmes, suivi de défauts, suivis d'artéfacts, suivi de requêtes, file d'attente des problèmes, etc. Voir l'Annexe B, Système de suivi de bogues libres pour une liste de logiciels.
In this book, I'll continue to use "bug tracker" for the software that does the tracking, because that's what most people call it, but will use issue to refer to a single item in the bug tracker's database. This allows us to distinguish between the behavior or misbehavior that the user encountered (that is, the bug itself), and the tracker's record of the bug's discovery, diagnosis, and eventual resolution. Keep in mind that although most issues are about actual bugs, issues can be used to track other kinds of tasks too.
The classic issue life cycle looks like this:
Dans ce livre je continuerai à utiliser "système de suivi de bogues" pour désigner le logiciel qui s'occupe du suivi, parce que c'est ainsi que la plupart des gens l'appellent, mais je parlerai de problème pour désigner un objet particulier dans la base de donnée du système de suivi de bogues. Cela nous permet de faire la distinction entre le comportement, ou le mauvais comportement, auquel l'utilisateur à fait face (c'est à dire, le bogue en lui-même) et l'historique de découverte de bogues du système, du diagnostique et de la résolution finale. N'oubliez pas que bien que la plupart des problèmes se rapportent à de vrais bogues, les problèmes peuvent être utilisés pour suivre d'autres types de tâches aussi.
Le cycle de vie classique d'un problème ressemble à cela :
1.
Someone files the issue. They provide a summary, an initial description (including a reproduction recipe, if applicable; see the section called
“Treat Every User as a Potential Volunteer” in Chapter 8, Managing Volunteers for how to encourage good bug reports), and whatever other information
the tracker asks for. The person who files the issue may be totally unknown to the project—bug reports and feature requests are as likely to come
from the user community as from the developers.
Once filed, the issue is in what's called an open state. Because no action has been taken yet, some trackers also label it as unverified and/or
unstarted. It is not assigned to anyone; or, in some systems, it is assigned to a fake user to represent the lack of real assignation.
At this point, it is in a holding area: the issue has been recorded, but not yet integrated into the project's consciousness.
2.
Others read the issue, add comments to it, and perhaps ask the original filer for clarification on some points.
3.
The bug gets reproduced. This may be the most important moment in its life cycle. Although the bug is not actually fixed yet, the fact that someone
besides the original filer was able to make it happen proves that it is genuine, and, no less importantly, confirms to the original filer that
they've contributed to the project by reporting a real bug
4.
The bug gets diagnosed: its cause is identified, and if possible, the effort required to fix it is estimated. Make sure these things get recorded in
the issue; if the person who diagnosed the bug suddenly has to step away from the project for a while (as can often happen with volunteer developers),
someone else should be able to pick up where she left off.
In this stage, or sometimes the previous one, a developer may "take ownership" of the issue and assign it to herself (the section called
“Distinguish clearly between inquiry and assignment” in Chapter 8, Managing Volunteers examines the assignment process in more detail).
The issue's priority may also be set at this stage. For example, if it is so severe that it should delay the next release, that fact needs
to be identified early, and the tracker should have some way of noting it.
5.
The issue gets scheduled for resolution. Scheduling doesn't necessarily mean naming a date by which it will be fixed. Sometimes it just means
deciding which future release (not necessarily the next one) the bug should be fixed by, or deciding that it need not block any particular release.
Scheduling may also be dispensed with, if the bug is quick to fix.
6.
The bug gets fixed (or the task completed, or the patch applied, or whatever). The change or set of changes that fixed it should be recorded in
a comment in the issue, after which the issue is closed and/or marked as resolved.
1. Quelqu'un enregistre le problème. Il fournit un résumé, une description basique (en incluant la recette pour reproduire le bogue s'il y en a une, voir la section nommée "Considérez tous les utilisateurs comme des volontaires potentiels" dans le Chapitre 8, Gérer les volontaires pour savoir comment encourager les rapports de bogue) et tout autre information que demande le système de suivi. La personne qui enregistre le problème peut être complètement étrangère aux rapports de bogues du projet et les requêtes de fonctionnalités pourront aussi bien provenir de la communauté d'utilisateurs que des développeurs.
Une fois enregistré, le problème est dans ce qu'on appelle un état ouvert. Parce qu'aucune action n'a été prise encore, certains systèmes le classent dans non vérifié et/ou non commencé. Il n'est assigné à personne, ou, dans certains systèmes, il est assigné à un utilisateur factice pour représenter le manque d'assignation concrète. A ce point, il est dans une zone d'attente : le problème a été enregistré, mais pas encore intégré à la conscience du projet.
2. D'autres lisent le problème, y ajoutent des commentaires et, si besoin est, demandent des clarifications sur certains points à celui qui a fait l'entrée.
3. Le bogue est reproduit. C'est peut-être le moment le plus important dans son cycle de vie. Même si le bogue n'est pas corrigé encore, le fait que quelqu'un d'autre que l'auteur de l'entrée ait été capable de le reproduire prouve son existence et, de manière toute aussi importante, confirme à l'auteur qu'il a contribué au projet en rapportant un vrai bogue.
4. Le bogue est diagnostiqué : ses causes sont identifiées et, si possible, l'effort requit pour le corriger est estimé. Assurez vous que tout ceci soit enregistré dans le problème, si la personne qui a fait le diagnostique du bogue doit soudainement quitter le projet pour un certain temps (comme cela arrive souvent avec les développeurs volontaires), quelqu'un d'autre pourra continuer le travail sur les bases de ce qui avait été fait.
A cette étape, ou parfois dans les précédentes, un développeur peut "prendre possession" du problème et se l'assigner (la section nommée "Distinguer clairement requête et assignation" dans le Chapitre 8, Gérer les volontaires éclaire plus en détail le processus d'assignation). La priorité du problème peut aussi être décidée à cette étape. Par exemple, si c'est grave au point de retarder la prochaine sortie, ceci doit être identifié tôt et le suivi devrait fournir un moyen de le noter.
5. Un calendrier est prévu pour la résolution du problème. Prévoir ne signifie par nécessairement donner une date pour laquelle le problème sera corrigé. Parfois c'est simplement qu'il a été décidé dans quelle future version (par forcément la prochaine) le bogue devrait être corrigé ou qu'on a décidé qu'il n'est pas nécessaire de se fixer une version particulière. On peut se passer d'une prévision si le bogue peut être corrigé rapidement.
6. Le bogue est corrigé (ou la tâche accomplie ou le correctif appliqué, peu importe). La modification ou l'ensemble des modifications qui l'ont corrigé devrait être enregistrée(s) dans un commentaire du problème, après quoi le problème est clos et/ou marqué comme résolu.
There are some common variations on this life cycle. Sometimes an issue is closed very soon after being filed, because it turns out not to be a bug at all, but rather a misunderstanding on the part of the user. As a project acquires more users, more and more such invalid issues will come in, and developers will close them with increasingly short-tempered responses. Try to guard against the latter tendency. It does no one any good, as the individual user in each case is not responsible for all the previous invalid issues; the statistical trend is visible only from the developers' point of view, not the user's. (In the section called “Pre-Filtering the Bug Tracker” later in this chapter, we'll look at techniques for reducing the number of invalid issues.) Also, if different users are experiencing the same misunderstanding over and over, it might mean that that aspect of the software needs to be redesigned. This sort of pattern is easiest to notice when there is an issue manager monitoring the bug database; see the section called “Issue Manager” in Chapter 8, Managing Volunteers.
Certaines variantes de ce cycle de vie sont classiques. Il arrive qu'un incident soit clos très rapidement après avoir été enregistré parce qu'il s'avert que ce n'est pas un bogues du tout mais plutôt une mauvaise compréhension de la part de l'utilisateur. A mesure qu'un projet fédère plus d'utilisateurs vous verrez de plus en plus ce type d'incidents non valides arriver et les développeurs les fermeront avec de moins en moins de tact. Essayez de contenir cette dernière tendance. Cela n'apporte rien de bon à personne, un utilisateur particulier n'est pas responsable des mauvais rapports précédents, cette augmentation n'est que visible du point de vue des développeurs, pas de celui des utilisateurs. (Dans la section nommée "Filtrer le système de suivi de bogues en amont" plus loin dans ce chapitre nous aborderons les techniques pour réduire le nombre de rapports non valides.) Il faut voir également que si plusieurs utilisateurs se retrouvent avec la même incompréhension sans arrêt il pourrait être bon de repenser cette partie du logiciel. Ce genre de répétition est détectée plus aisément si un responsable incident surveille la base de donnée de bogues, voir la section appelée "Responsable incidents" dans le Chapitre 8, Gérer les volontaires.
Another common life cycle variation is for the issue to be closed as a duplicate soon after Step 1. A duplicate is when someone files an issue that's already known to the project. Duplicates are not confined to open issues: it's possible for a bug to come back after having been fixed (this is known as a regression), in which case the preferred course is usually to reopen the original issue and close any new reports as duplicates of the original one. The bug tracking system should keep track of this relationship bidirectionally, so that reproduction information in the duplicates is available to the original issue, and vice versa.
Une autre modification courante du cycle de vie pour un incident est d'être clos peu après la première étape car c'est un doublon. Un doublon est un incident enregistré par quelqu'un alors qu'il est déjà connu du projet. Les doublons ne sont pas confinés aux incidents ouverts : il est possible qu'un bogue revienne après avoir été corrigé (on appelle cela une régression), dans ce cas la voie choisie est en général de ré-ouvrir l'incident d'origine et de fermer tout nouveau rapport qui serait un doublon du premier. Le système de suivi de bogue devrait garder en mémoire les relations dans les deux sens, afin que les informations de reproduction dans les duplicats soient disponibles dans l'incident originel et vice versa.
A third variation is for the developers to close the issue, thinking they have fixed it, only to have the original reporter reject the fix and reopen it. This is usually because the developers simply don't have access to the environment necessary to reproduce the bug, or because they didn't test the fix using the exact same reproduction recipe as the reporter.
Aside from these variations, there may be other small details of the life cycle that vary depending on the tracking software. But the basic shape is the same, and while the life cycle itself is not specific to Open Source software, it has implications for how Open Source projects use their bug trackers.
Une troisième variation peut se produire quand les développeurs ferment l'incident, pensant qu'ils ont réglé le problème seulement pour que le rapporteur original rejette la correction et le ré-ouvre. C'est en général parce que les développeurs n'ont simplement pas accès aux ressources nécessaires pour reproduire le bogue ou parce qu'ils n'ont pas testé le correctif en employant le même recette de reproduction que le rapporteur. En plus de ces variations d'autres petits détails du cycle de vie peuvent varier selon le logiciel de suivi. Mais de manière général c'est toujours pareil et même si le cycle de vie n'est pas particulier aux logiciels Open Source il a des implications sur l'usage que font les projets Open Source de leur système de suivi de bogues.
As Step 1 implies, the tracker is as much a public face of the project as the mailing lists or Web pages. Anyone may file an issue, anyone may look at an issue, and anyone may browse the list of currently open issues. It follows that you never know how many people are waiting to see progress on a given issue. While the size and skill of the development community constrains the rate at which issues can be resolved, the project should at least try to acknowledge each issue the moment it appears. Even if the issue lingers for a while, a response encourages the reporter to stay involved, because she feels that a human has registered what she has done (remember that filing an issue usually involves more effort than, say, posting an e-mail). Furthermore, once an issue is seen by a developer, it enters the project's consciousness, in the sense that that developer can be on the lookout for other instances of the issue, can talk about it with other developers, etc.
The need for timely reactions implies two things:
Comme l'Etape 1 le laisse penser, le système de suivi est, au même titre que les listes de diffusion et les pages Webs, la face visible du projet. N'importe qui peut rapporter un problème , n'importe qui peut jeter un œil à un incident et n'importe qui peut naviguer la liste des incidents actuellement ouverts. La conséquence est que vous ne savez jamais combien de personnes attendent de voir des améliorations pour un problème particulier. Alors que la taille et les compétences de la communauté de développement détermine la vitesse de résolution des problèmes, le projet devrait au minimum tenter de reconnaître les incidents à mesure qu'ils apparaissent. Même si le problème traîne pendant un moment, une réponse encourage le rapporteur à rester engagé parce qu'il voit qu'un être humain a enregistré ce qu'il a fait (souvenez vous que rapporter un problème demande en général plus d'effort que, par exemple, envoyer un e-mail). De plus, une fois qu'un problème est repéré par un développeur, le projet en prend conscience, dans le sens où le développeur peut guetter d'autres exemples du problème, peut en parler aux autres développeurs, etc.
Répondre rapidement vous demandera deux choses :
*
The tracker must be connected to a mailing list, such that every change to an issue, including its initial filing, causes a mail to go out
describing what happened. This mailing list is usually different from the regular development list, since not all developers may want to receive
automated bug mails, but (just as with commit mails) the Reply-to header should be set to the development mailing list.
*
The form for filing issues should capture the reporter's e-mail address, so she can be contacted for more information. (However, it should not
require the reporter's e-mail address, as some people prefer to report issues anonymously. See the section called “Anonymity and involvement”
later in this chapter for more on the importance of anonymity.)
Le système de suivi doit être lié à une liste de diffusion afin que chaque changement apporté à un incident, y compris sa création, envoie un mail décrivant les modifications. Cette liste de diffusion est en général distincte des listes de développement habituelles puisque tous les développeurs ne veulent pas forcément recevoir des mails de bogues automatisés, mais (tout comme les mails de commit) le bandeau "Répondre à" devrait renvoyer vers la liste de développement.
Le fichier pour envoyer un incident devrait inclure l'adresse e-mail du rapporteur afin qu'il puisse être contacté pour demander plus d'informations (Cependant, l'adresse e-mail ne devrait pas être obligatoire comme certaines personnes préfères rapporter les bogues anonymement. Voir la section nommée "Anonymat et engagement" plus loin dans ce chapitre pour plus de détails sur l'importance de l'anonymat).
Interaction with Mailing Lists / Interaction avec les listes de diffusion
Make sure the bug tracker doesn't turn into a discussion forum. Although it is important to maintain a human presence in the bug tracker, it is not fundamentally suited to real-time discussion. Think of it rather as an archiver, a way to organize facts and references to other discussions, primarily those that take place on mailing lists.
Assurez vous que le système de suivi de bogues ne se transforme pas en un forum de discussion. Bien qu'il soit important de garder une présence humaine dans le système de suivi, il n'est pas exactement fait pour mener des discussions en temps réel. Essayez de le voir plutôt comme un archiveur, une façon d'organiser les faits et les références à d'autres discussions, principalement celles développées dans les listes de discussions.
There are two reasons to make this distinction. First, the bug tracker is more cumbersome to use than the mailing lists (or than real-time chat forums, for that matter). This is not because bug trackers have bad user interface design, it's just that their interfaces were designed for capturing and presenting discrete states, not free-flowing discussions. Second, not everyone who should be involved in discussing a given issue is necessarily watching the bug tracker. Part of good issue management (see the section called “Share Management Tasks as Well as Technical Tasks” in Chapter 8, Managing Volunteers) is to make sure each issue is brought to the right peoples' attention, rather than requiring every developer to monitor all issues. In the section called “No Conversations in the Bug Tracker” in Chapter 6, Communications, we'll look at ways to make sure people don't accidentally siphon discussions out of appropriate forums and into the bug tracker.
Il y a deux raisons pour faire cette distinction. En premier lieu, le système de suivi de bogues est moins commode à utiliser que les listes de diffusion (ou que les salons de discussion en temps réel d'ailleurs). Ce n'est pas parce que les systèmes de suivi ont une interface mal conçue, c'est simplement que leur interface a été conçue pour capturer et présenter des états séparés, pas des discussions continues. En second, tous ceux qui devraient être impliqués dans la discussion à propos d'un problème particulier ne suivent pas forcément le système de suivi. Une bonne gestion des incidents demande de s'assurer que chaque problème est porté à l'attention des bonnes personnes, plutôt que de demander à tous les développeurs de suivre tous les problèmes (voir la section appelée "Partager les tâches de gestion aussi bien que les tâches techniques" dans le Chapitre 8, Gérer les volontaires). Dans la section "Pas de conversations dans le système de suivi de bogues" dans le Chapitre 6, Communication nous étudierons comment s'assurer que les gens ne siphonnent pas accidentellement les discussions hors du bon forum vers le système de suivi.
Some bug trackers can monitor mailing lists and automatically log all e-mails that are about a known issue. Typically they do this by recognizing the issue's identifying number in the subject line of the mail, as part of a special string; developers learn to include these strings in their mails to attract the tracker's notice. The bug tracker may either save the entire e-mail, or (even better) just record a link to the mail in the regular mailing list archive. Either way, this is a very useful feature; if your tracker has it, make sure both to turn it on and to remind people to take advantage of it.
Certains systèmes de suivi de bogues peuvent surveiller les listes de diffusions et enregistrer tous les e-mails se rapportant à un problème connu. Ils font en général cela en reconnaissant le numéro d'identification des incidents dans la sujet du mail, au sein d'un "string"* particulier, les développeurs apprennent à inclure ces "strings" dans les e-mails pour attirer l'attention du système. Le système de suivi peut soit sauvegarder l'e-mail entier soit (et c'est mieux) simplement enregistrer un lien vers le mail dans l'archive habituelle de la liste de diffusion. Dans tous les cas, c'est une fonctionnalité très utile, si votre système la possède assurez vous de l'activer et de rappeler aux gens de s'en servir.
\* string dans le sens ligne de texte
Pre-Filtering the Bug Tracker / Filtrer le système de suivi de bogues en amont
Most issue databases eventually suffer from the same problem: a crushing load of duplicate or invalid issues filed by well-meaning but inexperienced or ill-informed users. The first step in combatting this trend is usually to put a prominent notice on the front page of the bug tracker, explaining how to tell if a bug is really a bug, how to search to see if it's already been filed, and finally, how to effectively report it if one still thinks it's a new bug.
La plupart des bases de données d'incidents souffrent au final du même problème : un nombre écrasant de doublons ou d'incidents invalides enregistrés par des utilisateurs bien intentionnés mais inexpérimentés ou mal informés. La première chose à faire pour combattre cette tendance est en général de mettre une note d'information bien en vue sur la première page du système de suivi qui indique comment différencier un bogue de ce qui n'en est pas un, comment faire des recherches pour savoir s'il n'a pas déjà été enregistré et, finalement, comme en rapporter un de manière efficace si l'on pense toujours avoir affaire à un nouveau bogue.
This will reduce the noise level for a while, but as the number of users increases, the problem will eventually come back. No individual user can be blamed for it. Each one is just trying to contribute to the project's well-being, and even if their first bug report isn't helpful, you still want to encourage them to stay involved and file better issues in the future. In the meantime, though, the project needs to keep the issue database as free of junk as possible.
Cela devrait vous donner un peu de répits, mais avec l'augmentation du nombre d'utilisateurs le problème finira par revenir. Aucun utilisateur individuellement n'y est pour quelque chose. Chacun essaie simplement de contribuer au bien du projet, même si leur premier rapport de bogue n'est pas d'une grande aide vous devez quand même les encourager à rester impliqué et à mieux s'y prendre dans le futur. Parallèlement pourtant, le projet a besoin de garder une base de données d'incidents aussi propre que possible.
The two things that will do the most to prevent this problem are: making sure there are people watching the bug tracker who have enough knowledge to close issues as invalid or duplicates the moment they come in, and requiring (or strongly encouraging) users to confirm their bugs with other people before filing them in the tracker.
Les deux choses qui vous aideront le plus à prévenir ce problème sont : s'assurer que les personnes qui surveillent le système de suivi de bogues sont celles qui ont assez de connaissance pour fermer les incidents invalides ou en doubles à mesure qu'ils arrivent et imposer (ou encouragez fortement) aux utilisateurs de faire confirmer leurs bogues par d'autres personnes avant de les enregistrer.
The first technique seems to be used universally. Even projects with huge issue databases (say, the Debian bug tracker at http://bugs.debian.org/, which contained 315,929 issues as of this writing) still arrange things so that someone sees each issue that comes in. It may be a different person depending on the category of the issue. For example, the Debian project is a collection of software packages, so Debian automatically routes each issue to the appropriate package maintainers. Of course, users can sometimes misidentify an issue's category, with the result that the issue is sent to the wrong person initially, who may then have to reroute it. However, the important thing is that the burden is still shared—whether the user guesses right or wrong when filing, issue watching is still distributed more or less evenly among the developers, so each issue is able to receive a timely response.
La première technique semble être largement répandue. Même les projets avec des bases de données énormes (par exemple, le système de suivi de bogues du projet Debian à l'adresse http://bugs.debian.org/ qui contient 315 929 incidents au moment de l'écriture) arrive à arranger les choses pour que quelqu'un puisse voir chaque incident quand il est enregistré. Plusieurs personnes peuvent assurer ce rôle selon le type d'incident. Par exemple, le projet Debian est un ensemble de paquets logiciels, donc Debian redirige automatiquement l'incident vers les personnes qui s'occupent du paquet. Evidemment, les utilisateurs peuvent parfois se tromper de catégorie quand ils enregistrent un bogue, l'incident sera donc envoyé en premier à la mauvaise personne qui devra alors à son tour le rediriger. Malgré tout, ce qui importe ici est que la charge de travail est partagée, que l'utilisateur ait vu juste ou pas quand il a fait l'enregistrement, la surveillance des incidents est toujours partagée plus ou moins équitablement entre les développeurs, ainsi chaque problème peut recevoir une réponse rapide.
The second technique is less widespread, probably because it's harder to automate. The essential idea is that every new issue gets "buddied" into the database. When a user thinks he's found a problem, he is asked to describe it on one of the mailing lists, or in an IRC channel, and get confirmation from someone that it is indeed a bug. Bringing in that second pair of eyes early can prevent a lot of spurious reports. Sometimes the second party is able to identify that the behavior is not a bug, or is fixed in recent releases. Or she may be familiar with the symptoms from a previous issue, and can prevent a duplicate filing by pointing the user to the older issue. Often it's enough just to ask the user "Did you search the bug tracker to see if it's already been reported?" Many people simply don't think of that, yet are happy to do the search once they know someone's expecting them to.
La deuxième technique est moins répandue, sûrement parce qu'elle est plus dure à automatiser. L'idée essentielle est que chaque nouvel incident doit être "parrainé" dans la base de données. Quand un utilisateur pense avoir découvert un problème, on lui demande de le décrire dans une des listes de diffusion ou dans un canal IRC et d'obtenir la confirmation par quelqu'un d'autre que c'est bien un bogue. Faire entrer ce second avis rapidement peut vous économiser beaucoup de faux rapports. Parfois la deuxième personne est capable de dire si ce comportement est un bogue ou pas ou s'il a été corrigé dans une version plus récente. Ou il peut bien connaître les symptômes d'un bogue précédent et peut éviter un doublon en dirigeant l'utilisateur vers l'incident précédent. Il est souvent suffisant de simplement demander à l'utilisateur "As-tu fait une recherche dans le système de suivi de bogues vous voir s'il n'avait pas déjà été rapporté ?". Nombreux sont ceux qui n'y pensent pas et qui pourtant seront content de faire cette recherche quand ils savent que c'est ce qui est attendu de leur part.
The buddy system can really keep the issue database clean, but it has some disadvantages too. Many people will file solo anyway, either through not seeing, or through disregarding, the instructions to find a buddy for new issues. Thus it is still necessary for volunteers to watch the issue database. Furthermore, because most new reporters don't understand how difficult the task of maintaining the issue database is, it's not fair to chide them too harshly for ignoring the guidelines. Thus the volunteers must be vigilant, and yet exercise restraint in how they bounce unbuddied issues back to their reporters. The goal is to train each reporter to use the buddying system in the future, so that there is an ever-growing pool of people who understand the issue-filtering system. On seeing an unbuddied issue, the ideal steps are:
Le système de parrainage peut être très efficace pour maintenir la base de données en ordre, mais il a ses inconvénients également. De nombreuses personnes continueront à faire des rapports dans leur coin, par dédain pour les instructions pour trouver un parrain pour les nouveaux incidents ou parce qu'ils ne les auront pas vues. De plus, parce que la plupart des nouveaux rapporteurs ne comprennent pas la difficulté de maintenir la base de données d'incidents propre ce n'est pas juste de les réprimander trop durement pour avoir ignoré les directives. C'est pourquoi les volontaires doivent être vigilants et en même temps se montrer souples quand ils renvoient un incident non parrainé à son rapporteur. Le but est d'entraîner chaque rapporteur à utiliser le système de parrainage dans le futur afin qu'il y ait un un nombre grandissant de personnes qui comprennent le système de filtres des incidents. Quand vous découvrez un incident non parrainé voici les étapes d'une réaction idéale :
1.
Immediately respond to the issue, politely thanking the user for filing, but pointing them to the buddying guidelines (which should, of course,
be prominently posted on the Web site).
2.
If the issue is clearly valid and not a duplicate, approve it anyway, and start it down the normal life cycle. After all, the reporter's now been
informed about buddying, so there's no point wasting the work done so far by closing a valid issue.
3.
Otherwise, if the issue is not clearly valid, close it, but ask the reporter to reopen it if they get confirmation from a buddy. When they do,
they should put a reference to the confirmation thread (e.g., a URL into the mailing list archives).
1. Répondez immédiatement au problème, remerciez poliment l'utilisateur pour sa contribution, mais dirigez le vers les règles de parrainage (qui devraient évidemment être bien en évidence sur le site Web).
2. Si l'incident est valide et n'est pas un doublon, approuvez le malgré tout et lancez le sur son cycle de vie normal. Après tout la personne ayant fait le rapport est maintenant au courant du parrainage, il n'y a donc pas de raison de perdre le travail accompli en fermant un rapport valide.
3. Autrement, s'il n'est pas évident que le rapport soit valide, fermez le mais demandez au rapporteur de le rouvrir s'il obtient la confirmation d'un parrain. Quand il l'obtient, il devrait mettre une référence au sujet où il a obtenu confirmation (c'est à dire, une URL des archives de la liste de diffusion).
Remember that although this system will improve the signal/noise ratio in the issue database over time, it will never completely stop the misfilings. The only way to prevent misfilings entirely is to close off the bug tracker to everyone but developers—a cure that is almost always worse than the disease. It's better to accept that cleaning out invalid issues will always be part of the project's routine maintenance, and to try to get as many people as possible to help.
See also the section called “Issue Manager” in Chapter 8, Managing Volunteers.
Souvenez vous que bien que ce système améliorera le rapport signal/bruit de fond dans la base de données des incidents avec le temps, il n'empêchera pas complètement les mauvais rapports. Le seul moyen de les éviter entièrement est de fermer le système de suivi de bogues à tous sauf aux développeurs, un remède qui est presque toujours pire que le mal. Il vaut mieux accepter le fait que faire un peu de ménage fera toujours partie de l'entretien de routine du projet et essayer d'obtenir l'aide d'autant de personnes que possible.
Voir aussi la section appelée "Responsable incident"̎ dans le Chapitre 8, Gérer les volontaires.
