POSS Chap 6 Part 5
Un article de Framalang Wiki.
[modifier] No Conversations in the bogue Tracker
In any project that's making active use of its bogue tracker, there is always a danger of the tracker turning into a discussion forum itself, even though the mailing lists would really be better. Usually it starts off innocently enough: someone annotates an issue with, say, a proposed solution, or a partial patch. Someone else sees this, realizes there are problems with the solution, and attaches another annotation pointing out the problems. The first person responds, again by appending to the issue...and so it goes.
The problem with this is, first, that the bogue tracker is a pretty cumbersome place to have a discussion, and second, that other people may not be paying attention—after all, they expect development discussion to happen on the development mailing list, so that's where they look for it. They may not be subscribed to the issue changes list at all, and even if they are, they may not follow it very closely.
But exactly where in the process did something go wrong? Was it when the original person attached her solution to the issue—should she have posted it to the list instead? Or was it when the second person responded in the issue, instead of on the list?
There isn't one right answer, but there is a general principle: if you're just adding data to an issue, then do it in the tracker, but if you're starting a conversation, then do it on the mailing list. You may not always be able to tell which is the case, but just use your best judgement. For example, when attaching a patch that contains a potentially controversial solution, you might be able to anticipate that people are going to have questions about it. So even though you would normally attach the patch to the issue (assuming you don't want to or can't commit the change directly), in this case you might choose to post it to a mailing list instead. At any rate, there eventually will come a point in the exchange where one party or the other can tell that it is about to go from mere appending of data to an actual conversation—in the example that started this section, that would be the second respondent, who on realizing that there were problems with the patch, could predict that a real conversation is about to ensue, and therefore that it should be held in the appropriate medium.
To use a mathematical analogy, if the information looks like it will be quickly convergent, then put it directly in the bogue tracker; if it looks like it will be divergent, then a mailing list or IRC channel would be a better place.
This doesn't mean there should never be any exchanges in the bogue tracker. Asking for more details of the reproduction recipe from the original reporter tends to be a highly convergent process, for instance. The person's response is unlikely to raise new issues; it's simply going to flesh out information already filed. There's no need to distract the mailing list with that process; by all means, take care of it with a series of comments in the tracker. Likewise, if you're fairly sure that the bogue has been misreported (i.e., is not a bogue), then you can simply say so right in the issue. Even pointing out a minor problem with a proposed solution is fine, assuming the problem is not a showstopper for the entire solution.
On the other hand, if you're raising philosophical issues about the bogue's scope or the software's proper behavior, you can be pretty sure other developers will want to be involved. The discussion is likely to diverge for a while before it converges, so do it on the mailing list.
Always link to the mailing list thread from the issue, when you choose to post to the mailing list. It's still important for someone following the issue to be able to reach the discussion, even if the issue itself isn't the forum of discussion. The person who starts the thread may find this laborious, but Open Source is fundamentally a writer-responsible culture: it's much more important to make things easy for the tens or hundreds of people who may read the bogue than for the three or five people writing about it.
It's fine to take important conclusions or summaries from the list discussion and paste them into the issue, if that will make things convenient for readers. A common idiom is to start a list discussion, put a link to the thread in the issue, and then when the discussion finishes, paste the final summary into the issue (along with a link to the message containing that summary), so someone browsing the issue can easily see what conclusion was reached without having to click to somewhere else. Note that the usual "two masters" data duplication problem does not exist here, because both archives and issue comments are usually static, unchangeable data anyway.
Pas de discussions dans le système de suivi de bogues
Dans tous les projets qui font un usage actif d'un système de suivi de bogues existe le danger que celui-ci devienne un forum de discussion en lui-même, malgré l'intérêt que présentent les listes de diffusion. Généralement cela commence innocemment : quelqu'un note un problème et, disons, propose une solution ou un correctif partiel. Quelqu'un d'autre le remarque, se rend compte que la solution proposée n'a pas que du bon et attache une autre note indiquant ces problèmes. La première personne répond en ajoutant une note sur la question... et ainsi de suite.
Le problème est que, premièrement, le système de suivi de bogues est un endroit trop encombré pour y mener une discussion et, deuxièmement, les autres peuvent ne pas y prêter attention car ils s'attendent à ce que les discussions sur le développement aient lieu sur la liste « développement », c'est donc là qu'ils regarderont. Il est possible qu'ils ne soient même pas abonnés à la liste « résolution de problèmes » et, même s'ils le sont, ils ne suivent peut-être pas de près ce qu'il s'y passe.
Mais à quel moment précis du processus quelque chose est allé de travers ? Est-ce quand la personne du début a ajouté sa solution à l'endroit où le problème était décrit : aurait-elle dû plutôt la poster sur la liste ? où est-ce quand la deuxième personne a répondu au même endroit plutôt que sur la liste ?
Il n'y a pas qu'une bonne réponse, mais il existe un principe général : si vous ajoutez des données sur un sujet faites-le sur le système de suivi, mais si vous démarrez une discussion faites-le sur la liste. Vous ne serez peut-être pas toujours en mesure de déterminer dans quelle catégorie ranger votre intervention, mais suivez votre jugement. Par exemple, au moment de joindre un correctif qui contient une solution qui peut prêter à controverse, vous devez anticiper le fait que les gens auront des questions à poser. Donc, même si vous auriez trouvé normal de joindre le correctif à la description du problème (en supposant que vous ne voulez ou ne pouvez pas valider le changement directement), vous devriez plutôt choisir de le poster sur la liste de diffusion. De toute façon, les échanges aboutiront à un point où l'une des parties dira que cela va plus loin que l'ajout pur et simple de données et qu'il faut une vraie discussion; dans l'exemple qui ouvre cette partie, ce serait à celui qui répond en deuxième, en comprenant qu'il y a des problèmes sur le correctif, de prévoir qu'il en découlera une vraie discussion et qu'elle doit avoir lieu sur le support approprié.
Pour utiliser une analogie mathématique : si l'information semble rapidement convergente, mettez la directement dans le système de suivi de bogues ; si elle a l'air divergente, la liste de discussion ou le canal IRC semblent mieux appropriés.
Ceci ne veut pas dire qu'il ne devrait jamais y avoir d'échanges dans le système de suivi. Demander des détails supplémentaires sur la façon de reproduire le bogue au rapporteur initial est un processus hautement convergent, par exemple. La réponse de la personne a peu de chances de soulever de nouvelles questions ; cela ne fait qu'étayer l'information référencée précédemment. Il n'y a pas lieu de perturber la liste avec ce processus. Essayez au maximum de régler cette question par une série de commentaires à même le système de suivi. De même, si vous êtes certain qu'un bogue a été rapporté à tort (c'est-à-dire qu'il ne s'agit pas d'un bogue), vous pouvez le dire directement sur le système de suivi. Même souligner un problème mineur à propos d'une solution proposée est acceptable, du moment que le problème en question ne compromet pas l'ensemble de la solution.
D'un autre côté, si vous soulevez des questions philosophiques sur la portée d'un bogue ou sur le comportement correct du logiciel vous pouvez être sûr que d'autres développeurs voudront y participer. La discussion divergera vraisemblablement pendant un moment avant de converger de nouveau : menez-la donc sur la liste.
Donnez toujours des liens vers le système de suivi quand vous choisissez de poster sur la liste. Il est important que tous ceux qui suivent le bogue puissent accéder à la discussion même si l'endroit où il est rapporté n'est pas le lieu où se tient la discussion. La personne qui démarre le fil de discussion trouvera sans doute cela pénible, mais le milieu du logiciel libre est fondamentalement une culture de la responsabilité par l'écrit : il est bien plus important de faciliter le travail aux dizaines ou centaines de personnes qui liront le bogue qu'aux trois ou quatre qui écrivent dessus.
On peut aussi extraire des conclusions ou des résumés importants de la liste de discussion pour les coller dans le système de suivi si cela aide les lecteurs. Un usage courant consiste à commencer une discussion dans la liste en mettant un lien vers le rapport de bogue, puis, une fois la discussion finie, de coller le résumé dans le système de suivi (avec un lien vers le message qui contient le résumé, pour que ceux qui parcourent le suivi puissent voir facilement la conclusion à laquelle on est arrivé sans avoir à cliquer ailleurs. Notez que le problème courant des « deux originaux », problème de duplication des données, n'existe pas ici, car aussi bien les archives que les commentaires de bogue sont généralement des données statiques, non modifiables de toute façon.
