POSS Chap 8 Part 2
Un article de Framalang Wiki.
Sommaire |
[modifier] Share Management Tasks as Well as Technical Tasks
Share the management burden as well as the technical burden of running the project. As a project becomes more complex, more and more of the work is about managing people and information flow. There is no reason not to share that burden, and sharing it does not necessarily require a top-down hierarchy either—what happens in practice tends to be more of a peer-to-peer network topology than a military-style command structure.
Sometimes management roles are formalized, and sometimes they happen spontaneously. In the Subversion project, we have a patch manager, a translation manager, documentation managers, issue managers (albeit unofficial), and a release manager. Some of these roles we made a conscious decision to initiate, others just happened by themselves; as the project grows, I expect more roles to be added. Below we'll examine these roles, and a couple of others, in detail (except for release manager, which was already covered in the section called “Release manager” and the section called “Dictatorship by Release Owner” earlier in this chapter).
As you read the role descriptions, notice that none of them requires exclusive control over the domain in question. The issue manager does not prevent other people from making changes in the issues database, the FAQ manager does not insist on being the only person to edit the FAQ, and so on. These roles are all about responsibility without monopoly. An important part of each domain manager's job is to notice when other people are working in that domain, and train them to do the things the way the manager does, so that the multiple efforts reinforce rather than conflict. Domain managers should also document the processes by which they do their work, so that when one leaves, someone else can pick up the slack right away.
Sometimes there is a conflict: two or more people want the same role. There is no one right way to handle this. You could suggest that each volunteer post a proposal (an « application ») and have all the committers vote on which is best. But this is cumbersome and potentially awkward. I find that a better technique is just to ask the multiple candidates to settle it among themselves. They usually will, and will be more satisfied with the result than if a decision had been imposed on them from the outside.
[modifier] Partager les tâches de gestion aussi bien que les tâches techniques
Partagez les tâches de management aussi bien que les tâches techniques pour la bonne marche du projet. A mesure que le projet se complexifie votre travail s'orientera de plus en plus vers la gestion des volontaires et du flot d'information. Il n'y a pas de raison que vous ne partagiez pas cette charge, le partage ne nécessite pas forcément d'instaurer une hiérarchie verticale non plus, en pratique elle ressemblera plus à l'organisation d'un réseau pair à pair qu'à une hiérarchie militaire.
Parfois les rôles de gestion sont attribués formellement, d'autres fois ça se fait spontanément. Dans le projet Subversion nous avons un responsable correctifs, un responsable traduction, des responsables documentation, des responsables parutions (bien que ce soit de manière officieuse) et un responsable difficultés. Parmi ces rôles, la création de certains a été décidée, d'autres se sont créés d'eux mêmes. Quand le projet se développe il est normal que de nouveaux rôles se dessinent. Dans ce qui suit nous allons détailler ces rôles, ainsi que d'autres, plus précisément (à l'exception du responsable difficultés, que nous avons déjà traité dans la partie « Responsable difficultés » et dans la partie « La dictature du propriétaire de parution » précédemment dans ce chapitre).
A mesure que vous lisez la description des rôles vous remarquerez qu'aucun ne requiert le contrôle complet sur un domaine en question. Le responsable parutions n'empêche personne de faire des changements dans la base de donnée des parutions, le responsable FAQ ne s'impose pas comme la seule personne à pouvoir modifier la FAQ, etc. Il s'agit de trouver l'équilibre pour endosser les responsabilités sans exercer un contrôle exclusif. Une part importante du travail de tout responsable est de repérer ceux qui travaillent dans son domaine et de les former à faire les choses à sa manière afin que les efforts multiples s'additionnent plutôt que d'entrer en conflit. Les responsables devraient documenter leur manière de travailler afin que quand l'un d'eux quitte le projet quelqu'un puisse immédiatement lui succéder.
Il se peut qu'il y ait des conflits : une place convoitée par deux personnes ou plus. Il n'existe pas une bonne manière pour résoudre ce problème. Vous pouvez proposer que chaque volontaire établisse un projet (une « candidature ») et que tous les participants votent pour élire le meilleur. Mais c'est embarrassant et cela peut devenir gênant. Je trouve qu'une meilleure manière de faire est de demander aux différents candidats de régler ça entre eux. Ils y arriveront en général et ils seront plus satisfaits du résultat que si la décision leur avait été imposée de l'extérieur.
[modifier] Patch Manager
In a free software project that receives a lot of patches, keeping track of which patches have arrived and what has been decided about them can be a nightmare, especially if done in a decentralized way. Most patches arrive as posts to the project's development mailing list (though some may appear first in the issue tracker, or on external Web sites), and there are a number of different routes a patch can take after arrival.
Sometimes someone reviews the patch, finds problems, and bounces it back to the original author for cleanup. This usually leads to an iterative process—all visible on the mailing list—in which the original author posts revised versions of the patch until the reviewer has nothing more to criticize. It is not always easy to tell when this process is done: if the reviewer commits the patch, then clearly the cycle is complete. But if she does not, it might be because she simply didn't have time, or doesn't have commit access herself and couldn't rope any of the other developers into doing it.
Another frequent response to a patch is a freewheeling discussion, not necessarily about the patch itself, but about whether the concept behind the patch is good. For example, the patch may fix a bug, but the project prefers to fix that bug in another way, as part of solving a more general class of problems. Often this is not known in advance, and it is the patch that stimulates the discovery.
Occasionally, a posted patch is met with utter silence. Usually this is due to no developer having time at that moment to review the patch, so each hopes that someone else will do it. Since there's no particular limit to how long each person waits for someone else to pick up the ball, and meanwhile other priorities are always coming up, it's very easy for a patch to slip through the cracks without any single person intending for that to happen. The project might miss out on a useful patch this way, and there are other harmful side effects as well: it is discouraging to the author, who invested work in the patch, and it makes the project as a whole look a bit out of touch, especially to others considering writing patches.
The patch manager's job is to make sure that patches don't « slip through the cracks. » This is done by following every patch through to some sort of stable state. The patch manager watches every mailing list thread that results from a patch posting. If it ends in a commit of the patch, he does nothing. If it goes into a review/revise iteration, ending with a final version of the patch but no commit, he files an issue pointing to the final version, and to the mailing list thread around it, so that there is a permanent record for developers to follow up on later. If the patch addresses an existing issue, he annotates that issue with the relevant information, instead of opening a new issue.
When a patch gets no reaction at all, the patch manager waits a few days, then follows up asking if anyone is going to review it. This usually gets a reaction: a developer may explain that she doesn't think the patch should be applied, and give the reasons why, or she may review it, in which case one of the previously described paths is taken. If there is still no response, the patch manager may or may not file an issue for the patch, at his discretion, but at least the original submitter got some reaction.
Having a patch manager has saved the Subversion development team a lot of time and mental energy. Without a designated person to take responsibility, every developer would constantly have to worry « If I don't have time to respond to this patch right now, can I count on someone else doing it? Should I try to keep an eye on it? But if other people are also keeping an eye on it, for the same reasons, then we'd have needlessly duplicated effort. » The patch manager removes the second-guessing from the situation. Each developer can make the decision that is right for her at the moment she first sees the patch. If she wants to follow up with a review, she can do that—the patch manager will adjust his behavior accordingly. If she wants to ignore the patch completely, that's fine too; the patch manager will make sure it isn't forgotten.
Because this system works only if people can depend on the patch manager being there without fail, the role should be held formally. In Subversion, we advertised for it on the development and users mailing lists, got several volunteers, and took the first one who replied. When that person had to step down (see the section called “Transitions” later in this chapter), we did the same thing again. We've never tried having multiple people share the role, because of the communications overhead that would be required between them; but perhaps at very high volumes of patch submission, a multiheaded patch manager might make sense.[modifier] Responsable correctifs
Dans un projet de logiciel libre qui reçoit de nombreux correctifs, suivre tous les correctifs qui ont été soumis et ce qui a été décidé à leur propos peut être un vrai cauchemar, particulièrement si cela est réalisé de manière décentralisée. La plupart des correctifs sont envoyés au travers de la liste de diffusion des développeurs (certains peuvent aussi apparaître en premier sur le suivi de bogues ou sur un autre site Web) et les voies que peut emprunter un correctif après son arrivée sont multiples.
Parfois quelqu'un inspecte le correctif, y trouve un problème et le renvoi à son auteur pour y remédier. Cela donne généralement naissance à un processus itératif, parfaitement visible sur la liste de diffusion, dans lequel l'auteur renvoi des versions revues du correctif jusqu'à ce que le relecteur ne trouve plus rien à critiquer. Ce n'est pas toujours simple de déterminer quand ce processus est arrivé à son terme. Si le relecteur met la modification sur le site alors le cycle est clairement achevé. Mais s'il ne le fait pas ça peut être qu'il n'a simplement pas eu le temps ou qu'il n'a pas l'accès nécessaire et n'a pas pu entrer en contact avec un autre développeur pour qu'il le fasse.
La soumission d'un correctif peut aussi être à l'origine d'une discussion libre, pas forcément à propos du correctif lui même, mais sur le concept sous-jacent, savoir s'il est bon ou mauvais. Il peut, par exemple, corriger un bogue, mais le projet préfère régler ce bogue d'une autre manière, au sein de la résolution d'un problème plus général. Le fond de la discussion n'est pas prévisible par avance et c'est le correctif qui stimule la découverte.
A l'occasion, un correctif proposé ne soulève aucune réaction. En général cela est dû au manque de temps des développeurs à ce moment précis pour inspecter le correctif et chacun espère que quelqu'un d'autre le fera. Comme cette période n'a pas de limites déterminées, chacun attend que ce soit un autre qui prenne les choses en main et comme en même temps d'autres tâches importantes arrivent sans cesse, un correctif peut facilement passer au travers des mailles du filet sans que personne ne l'ait vraiment voulu. De cette manière le projet peut passer à côté d'un correctif utile et il y a aussi d'autres effets secondaires dangereux : l'auteur qui a fourni des efforts pour faire ce correctif est découragé et le projet peut sembler un peu déconnecté, en particulier aux yeux de ceux qui envisagent d'écrire des correctifs.
Le travail du responsable correctifs est de s'assurer qu'aucun correctif ne « passe au travers des mailles du filet ». Il faut pour cela suivre chaque correctif jusqu'à ce qu'il atteigne une sorte d'état stable. Le responsable correctifs surveille tous les sujets des listes de diffusion liés à la publication de correctifs. Si le sujet abouti à la sortie du correctif alors il n'a rien à faire. S'il entre dans un processus itératif d'inspection/amélioration s'achevant sur une version finale non distribuée il remplit un rapport de problème pointant vers la version finale et vers la liste de diffusion concernée afin qu'il y ait un toujours un certain nombre de développeurs pour le suivre par la suite. Si le correctif répond à un problème existant, il ajoute une note au rapport avec les informations pertinentes plutôt que de commencer un nouveau rapport.
Quand un correctif ne suscite aucune réaction du tout, le responsable correctifs patiente quelques jours puis demande si quelqu'un compte l'inspecter. En général il obtiendra une réponse: un développeur peut expliquer qu'il ne pense pas que le correctif devrait être appliqué, en donnant ses raisons ou qu'il pourrait le contrôler, dans quel cas on en revient à l'un des mécanisme précédemment décrit. S'il n'y a toujours pas de réponse le responsable correctifs peut, ou peut ne pas, remplir un rapport pour ce correctif, à sa discrétion, mais au moins la personne l'ayant soumis recevra une réaction.
Avoir un responsable correctifs a permis d'économiser beaucoup de temps et d'énergie à l'équipe de développement de Subversion. Sans une personne désignée pour prendre cette responsabilité, tous les développeurs se demanderaient sans cesse « Si je n'ai pas le temps de répondre à ce correctif maintenant, est-ce que je peux compter sur les autres pour le faire ? Devrais-je essayer de garder un œil dessus ? Mais si pour les mêmes raisons d'autres personnes font de même, on va alors dupliquer cet effort inutilement ». Le responsable correctifs dispense de ce jeu de « et si... ». Chaque développeur peut prendre la décision qui est la bonne pour lui au moment où il découvre le correctif. S'il veut s'engager dans une inspection il peut le faire, le responsable correctifs agira en conséquence. S'il veut ignorer complètement le correctif ce n'est pas grave, le responsable correctifs est là pour s'assurer qu'il ne tombera pas complètement dans l'oubli. Puisque ce système ne fonctionne que si les gens peuvent se reposer sur le responsable correctifs qui doit toujours être là sans faute, ce rôle devrait rester formel. Dans Subversion nous avions envoyé nos annonces aux listes de diffusion des développeurs et des utilisateurs, plusieurs réponses sont arrivées et nous avons choisi le plus rapide. Quand cette personne a dû abdiquer (voir la section nommée « Transitions » plus loin dans ce chapitre), nous avons recommencé. Nous n'avons pas tenté d'avoir plusieurs personnes partageant ce rôle à cause de la transparence qui serait requise dans leurs conversations. Mais peut-être que pour de très gros volumes de correctifs soumis, partager ce poste entre plusieurs personnes serait plus logique.[modifier] Translation Manager
In software projects, « translation » can refer to two very different things. It can mean translating the software's documentation into other languages, or it can mean translating the software itself—that is, having the program display errors and help messages in the user's preferred language. Both are complex tasks, but once the right infrastructure is in place, they are largely separable from other development. Because the tasks are similar in some ways, it may make sense (depending on your project) to have a single translation manager handle both, or it may be better to have two different managers.
In the Subversion project, we have one translation manager handle both. He does not actually write the translations himself, of course—he may help out on one or two, but as of this writing, he would need to speak ten languages (twelve counting dialects) in order to work on all of them! Instead, he manages teams of volunteer translators: he helps them coordinate among each other, and he coordinates between the teams and the rest of the project.
Part of the reason the translation manager is necessary is that translators are a different demographic from developers. They sometimes have little or no experience working in a version control repository, or indeed with working as part of a distributed volunteer team at all. But in other respects they are often the best kind of volunteer: people with specific domain knowledge who saw a need and chose to get involved. They are usually willing to learn, and enthusiastic to get to work. All they need is someone to tell them how. The translation manager makes sure that the translations happen in a way that does not interfere unnecessarily with regular development. He also serves as a sort of representative of the translators as a unified body, whenever the developers must be informed of technical changes required to support the translation effort.
Thus, the position's most important skills are diplomatic, not technical. For example, in Subversion we have a policy that all translations should have at least two people working on them, because otherwise there is no way for the text to be reviewed. When a new volunteer shows up offering to translate Subversion to, say, Malagasy, the translation manager has to either hook him up with someone who posted six months ago expressing interest in doing a Malagasy translation, or else politely ask the volunteer to go find another Malagasy translator to work with as a partner. Once enough people are available, the manager sets them up with the proper kind of commit access, informs them of the project's conventions (such as how to write log messages), and then keeps an eye out to make sure they adhere to those conventions.
Conversations between the translation manager and the developers, or between the translation manager and translation teams, are usually held in the project's original language—that is, the language from which all the translations are being made. For most free software projects, this is English, but it doesn't matter what it is as long as the project agrees on it. (English is probably best for projects that want to attract a broad international development community, though.)
Conversations within a particular translation team usually happen in their shared language, however, and one of the other tasks of the translation manager is to set up a dedicated mailing list for each team. That way the translators can discuss their work freely, without distracting people on the project's main lists, most of whom would not be able to understand the translation language anyway.
Internationalization Versus Localization
Internationalization (I18N) and localization (L10N) both refer to the process of adapting a program to work in linguistic and cultural environments other than the one for which it was originally written. The terms are often treated as interchangeable, but in fact they are not quite the same thing. As http://en.wikipedia.org/wiki/G11n writes:
The distinction between them is subtle but important: Internationalization is the adaptation of products for potential use virtually everywhere, while localization is the addition of special features for use in a specific locale.
For example, changing your software to losslessly handle Unicode (http://en.wikipedia.org/wiki/Unicode) text encodings is an internationalization move, since it's not about a particular language, but rather about accepting text from any of a number of languages. On the other hand, making your software print all error messages in Slovenian, when it detects that it is running in a Slovenian environment, is a localization move.
Thus, the translation manager's task is principally about localization, not internationalization.[modifier] Responsable traduction
Dans les projets de logiciels, « traduction » peut avoir deux significations très différentes. Ça peut signifier traduire la documentation du logiciel dans d'autres langues comme cela peut désigner la traduction du logiciel lui même, c'est à dire, faire que le programme affiche les erreurs et les messages d'aide dans la langue choisie par l'utilisateur. Les deux tâches sont complexes mais, une fois que la bonne infrastructure est en place, elles sont bien dissociables du reste du développement. Parce que ces tâches sont semblables sous certains aspects vous pouvez n'avoir qu'un seul responsable traduction pour les deux, mais il peut aussi être plus intéressant d'avoir deux responsables différents.
Dans le projet Subversion nous avons un responsable traduction qui s'occupe des deux. Il ne traduit pas vraiment lui même, même s'il peut bien sûr y aider de temps en temps, mais en plus de sa langue maternelle il devrait parler dix langues (douze si on compte les dialectes) pour pouvoir travailler sur chacune ! Ce qu'il fait plutôt est du management des équipes de traducteurs volontaires : il les aide à se coordonner entre eux et il fait le lien entre les équipes et le reste du projet.
Le responsable traduction est utile car les traducteurs sont une catégorie bien distincte des développeurs. Parfois ils n'ont pas ou peu d'expérience du travail autour d'un dépôt de gestion de version ou même du travail au sein d'une équipe éparse de volontaires. Mais à d'autres égards ce sont souvent les meilleurs volontaires : des gens, avec un savoir particulier dans un domaine, qui ont entrevu un besoin et ont décidé de participer. En général ils sont désireux d'apprendre et enthousiastes au travail. Ils ont juste besoin de quelqu'un pour leur dire comment mener à bien ce travail. Le responsable traduction s'assure que la traduction se passe sans créer d'interférence inutile avec le développement classique. Son rôle est également d'être une sorte de représentant des traducteurs lorsque les développeurs doivent être informés d'une modification technique nécessaire pour aider l'effort de traduction.
Les compétences les plus importantes à avoir ne sont donc pas techniques mais diplomatiques. Par exemple, dans Subversion nous avons une règle qui veut que pour chaque traduction il devrait y avoir deux personnes, parce que sinon il n'y a aucune moyen de relire le texte. Quand un nouveau volontaire débarque en proposant de faire la traduction de Subversion, en malgache par exemple, le responsable traduction doit soit le mettre en relation avec quelqu'un ayant posté six mois auparavant avec le même désir de faire une traduction malgache soit lui demander poliment de trouver un autre traducteur malgache pour en faire son partenaire de travail. Une fois que suffisamment de gens sont disponibles le responsable traduction leur donne l'accès nécessaire, les informe des règles du projet (comme par exemple comment écrire un message dans le registre), puis garde un œil sur eux pour voir s'ils suivent bien ces règles.
Les échanges entre le responsable traduction et les développeurs, ou entre le responsable traduction et les équipes de traductions se font en général dans la langue maternelle du projet, c'est à dire, la langue depuis laquelle toutes les traductions sont réalisées. Pour la plupart des projets de logiciel libre c'est l'anglais, mais cela importe peu du moment que c'est en accord avec le projet (l'anglais est sûrement la langue la plus indiquée pour les projets désirant attirer une importante communauté de développeurs internationaux).
Les conversations au sein d'une équipe de traduction en particulier se font en général dans la langue commune cependant et l'une des tâches dévolues au responsable traduction et de mettre en place des listes de diffusions qui leurs sont dédiées. Ainsi, les traducteurs peuvent discuter plus librement, sans déranger les gens sur les listes principales du projet, la plupart d'entre eux n'en comprendraient pas le contenu de toute manière.
Internationalisation et Localisation
L'internationalisation (I18N) et la localisation (L10N) font toutes les deux partie du processus d'adaptation du programme pour fonctionner dans un environnement linguistique et culturel autre que celui dans lequel il a été écrit à l'origine. On pense souvent que ces termes sont interchangeables, mais en fait ce n'est pas vraiment la même chose. On peut trouver sur la page http://fr.wikipedia.org/wiki/Internationalisation_de_logiciel :
La distinction entre les deux est subtile mais importante : l'internationalisation est l'adaptation des produits pour une utilisation potentielle partout, alors que la localisation est l'ajout de fonctionnalités particulières pour l'usage d'une région particulière.
Par exemple, modifier votre logiciel pour prendre en charge l'encodage de texte Unicode (http://fr.wikipedia.org/wiki/Unicode) sans perte c'est de l'internationalisation puisque ça ne concerne pas une langue en particulier mais plutôt l'acceptation de textes dans n'importe quelle langue. D'un autre côté, faire que votre logiciel affiche tous les messages d'erreur en slovénien lorsqu'il détecte qu'il fonctionne dans un environnement slovénien est une localisation. Donc, le rôle principal du responsable de traduction concerne la localisation et non l'internationalisation.
[modifier] Documentation Manager
Keeping software documentation up-to-date is a never-ending task. Every new feature or enhancement that goes into the code has the potential to cause a change in the documentation. Also, once the project's documentation reaches a certain level of completeness, you will find that a lot of the patches people send in are for the documentation, not for the code. This is because there are many more people competent to fix bugs in prose than in code: all users are readers, but only a few are programmers.
Documentation patches are usually much easier to review and apply than code patches. There is little or no testing to be done, and the quality of the change can be evaluated quickly just by review. Since the quantity is high, but the review burden fairly low, the ratio of administrative overhead to productive work is greater for documentation patches than for code patches. Furthermore, most of the patches will probably need some sort of adjustment, in order to maintain a consistent authorial voice in the documentation. In many cases, patches will overlap with or affect other patches, and need to be adjusted with respect to each other before being committed.
Given the exigencies of handling documentation patches, and the fact that the code base needs to be constantly monitored so the documentation can be kept up-to-date, it makes sense to have one person, or a small team, dedicated to the task. They can keep a record of exactly where and how the documentation lags behind the software, and they can have practiced procedures for handling large quantities of patches in an integrated way.
Of course, this does not preclude other people in the project from applying documentation patches on the fly, especially small ones, as time permits. And the same patch manager (see the section called “Patch Manager” earlier in this chapter) can track both code and documentation patches, filing them wherever the development and documentation teams want them, respectively. (If the total quantity of patches ever exceeds one human's capacity to track, though, switching to separate patch managers for code and documentation is probably a good first step.) The point of a documentation team is to have people who think of themselves as responsible for keeping the documentation organized, up-to-date, and consistent with itself. In practice, this means knowing the documentation intimately, watching the code base, watching the changes others commit to the documentation, watching for incoming documentation patches, and using all these information sources to do whatever is necessary to keep the documentation healthy.[modifier] Responsable documentation
Maintenir la documentation du logiciel à jour est une tâche sans fin. Chaque nouvelle fonctionnalité ou amélioration ajoutée au code est une source potentielle de modification de la documentation. Aussi, lorsque la documentation du projet atteint un certain niveau d'achèvement vous remarquerez que beaucoup de correctifs envoyés par les gens concernent la documentation et non pas le code. Cela résulte simplement du fait que bien plus de gens sont plus compétents pour corriger la prose que le code : tous les utilisateurs sont des lecteurs, mais seulement un faible pourcentage d'entre eux sont des programmeurs.
Les correctifs pour la documentation sont en général plus simple à inspecter et à appliquer que les correctifs pour le code. Puisque leur nombre est élevé, mais le travail d'inspection faible, le ratio travail administratif sur travail productif est plus élevé pour les correctifs de la documentation que pour le code. De plus, la plupart des correctifs demanderont sûrement quelques ajustements, de manière à assurer une cohérence de ton tout au long de la documentation. Dans beaucoup de cas les correctifs se chevaucheront ou auront une influence sur d'autres et doivent être ajustés en fonction des ceux-ci avant d'être validés.
Compte tenu des exigences liées au traitement des correctifs de la documentation et du fait que la base du code doit sans cesse être surveillée afin que la documentation reste à jour, il est logique d'avoir une personne, ou une petite équipe, employée à cette tâche. Ils savent exactement où et dans quelle mesure la documentation a pris du retard sur le logiciel et ils peuvent avoir des procédures avancées pour traiter de grandes quantités de correctifs. Bien sûr, cela n'empêche personne d'autre dans le projet d'apporter des correctifs à la documentation à la volée, en particulier des petites corrections quand le temps le permet. Et le responsable correctifs (voir la section appelée « Responsable correctifs » plus tôt dans ce chapitre) peut suivre à la fois les correctifs pour le code et ceux pour la documentation, les archivant là ou les équipes de développement ou de documentation en ont besoin (si la quantité de correctifs dépasse une limite humainement gérable, séparer la tâche du responsable correctifs entre deux responsables, code et documentation, sera peut-être un bon premier pas). L'équipe de documentation doit maintenir la cohésion entre les gens se sentant responsables de la traduction afin qu'ils soient organisés, cohérents et toujours à jour. En pratique, cela passe par une connaissance intime de la documentation, une surveillance étroite du code de base et des modifications apportées par les autres à la documentation, le suivi des correctifs pour la documentation entrants et l'utilisation de toutes ces informations pour faire tout ce qui est nécessaire pour garder la documentation en bonne santé.
[modifier] Issue Manager
The number of issues in a project's bug tracker grows in proportion to the number of people using the software. Therefore, even as you fix bugs and ship an increasingly robust program, you should still expect the number of open issues to grow essentially without bound. The frequency of duplicate issues will also increase, as will the frequency of incomplete or poorly described issues.
Issue managers help alleviate these problems by watching what goes into the database, and periodically sweeping through it looking for specific problems. Their most common action is probably to fix up incoming issues, either because the reporter didn't set some of the form fields correctly, or because the issue is a duplicate of one already in the database. Obviously, the more familiar an issue manager is with the project's bug database, the more efficiently she will be able to detect duplicate issues—this is one of the main advantages of having a few people specialize in the bug database, instead of everyone trying to do it ad hoc. When the group tries to do it in a decentralized manner, no single individual acquires a deep expertise in the content of the database.
Issue managers can also help map between issues and individual developers. When there are a lot of bug reports coming in, not every developer may read the issue notification mailing list with equal attention. However, if someone who knows the development team is keeping an eye on all incoming issues, then she can discreetly direct certain developers' attention to specific bugs when appropriate. Of course, this has to be done with a sensitivity to everything else going on in development, and to the recipient's desires and temperament. Therefore, it is often best for issue managers to be developers themselves.
Depending on how your project uses the issue tracker, issue managers can also shape the database to reflect the project's priorities. For example, in Subversion we schedule issues into specific future releases, so that when someone asks « When will bug X be fixed? » we can say « Two releases from now, » even if we can't give an exact date. The releases are represented in the issue tracker as target milestones, a field available in IssueZilla.[21] As a rule, every Subversion release has one major new feature and a list of specific bug fixes. We assign the appropriate target milestone to all the issues planned for that release (including the new feature—it gets an issue too), so that people can view the bug database through the lens of release scheduling. These targets rarely remain static, however. As new bugs come in, priorities sometimes get shifted around, and issues must be moved from one milestone to another so that each release remains manageable. This, again, is best done by people who have an overall sense of what's in the database, and how various issues relate to each other.
Another thing issue managers do is notice when issues become obsolete. Sometimes a bug is fixed accidentally as part of an unrelated change to the software, or sometimes the project changes its mind about whether a certain behavior is buggy. Finding obsoleted issues is not easy: the only way to do it systematically is by making a sweep over all the issues in the database. Full sweeps become less and less feasible over time, however, as the number of issues grows. After a certain point, the only way to keep the database sane is to use a divide-and-conquer approach: categorize issues immediately on arrival and direct them to the appropriate developer's or team's attention. The recipient then takes charge of the issue for the rest of its lifetime, shepherding it to resolution or oblivion as necessary. When the database is that large, the issue manager becomes more of an overall coordinator, spending less time looking at each issue herself and more time getting it into the right person's hands.[modifier] Responsable difficultés
Le nombre de problèmes dans le suivi de bogues augmente proportionnellement au nombre de personnes qui utilisent le logiciel. Par conséquent, même si vous corrigez les bogues et proposez un programme de plus en plus solide, vous devez toujours vous attendre à une augmentation du nombre de problèmes non traités, n'ayant pas nécessairement de liens entre eux. La fréquence des doublons augmentera aussi, tout comme la fréquence des descriptions mauvaises ou incomplètes des problèmes.
Les responsables difficultés aident à soulager ces problèmes en surveillant ce qui entre dans la base de donnée et en la parcourant entièrement régulièrement à la recherche de problèmes particuliers. Leur activité la plus commune est certainement d'arranger les rapports de problème entrants, soit parce que le rapporteur n'a pas rempli certains champs du formulaire correctement ou parce que le rapport est la copie d'un autre déjà archivé. De manière évidente, plus le responsable difficultés est familier avec la base de données de bogue du projet plus il sera à même de détecter efficacement les doublons, à ce titre, que quelques personnes se spécialisent dans la base de données de bogue vous procurera un avantage par rapport à la situation où chacun essai d'apporter sa contribution. Quand le groupe tente de le faire de manière décentralisée personne n'acquiert une grande connaissance du contenu de la base de données.
Les responsables difficultés peuvent aussi aider à relier les problèmes à des développeurs précis. Quand beaucoup de rapports de bogues arrivent, tous les développeurs peuvent ne pas lire la liste de diffusion des notifications de problèmes avec la même attention. Cependant, si quelqu'un ayant une bonne connaissance de l'équipe de développement surveille tous les rapports entrants il peut diriger l'attention des développeurs au cas par cas sur des bogues particuliers lorsque c'est utile. Bien sûr, ceci doit être fait en tenant compte de tout ce qui se passe dans le développement et en fonction des envies et du tempérament du destinataire. Par conséquent il vaut souvent mieux que les responsables difficultés soient eux-mêmes des développeurs.
Selon l'utilisation que fait votre projet du suivi de problèmes, les responsables difficultés peuvent modeler la base de données pour y faire transparaître les priorités du projet. Par exemple, dans Subversion nous prévoyons quelle version réglera quel problème afin que lorsque quelqu'un demande « Quand sera réglé le problème X ? » nous pouvons répondre « Dans deux versions », même si nous ne donnons pas de date exacte. Les sorties sont représentées dans le suivi de problèmes comme des jalons à atteindre, un champ disponible dans IssueZilla.[21] La règle en vigueur est que chaque nouvelle version de Subversion apporte une nouvelle fonctionnalité principale ainsi qu'une liste de correctifs pour des bogues particuliers. Nous prévoyons pour chaque version quels problèmes seront réglés en posant des objectifs (nouvelle fonctionnalité comprise, elle devient un problème aussi), afin que les gens puissent consulter la base de données du point de vue des sorties prévues. En général cependant ces objectifs sont modifiés. A mesure que de nouveaux bogues sont rapportés, les priorités sont réorganisées et les problèmes doivent être déplacés d'un jalon à un autre afin que chaque version reste faisable. Ceci, encore une fois, est mieux effectué par des personnes ayant une vue d'ensemble du contenu de la base de données et des liens entre les problèmes.
Un autre rôle des responsables difficultés est de remarquer quand les problèmes deviennent obsolètes. Parfois un bogue est réparé accidentellement lors d'une modification du logiciel sans rapport avec le bogue ou parfois le projet peut changer sa vision sur un comportement jugé jusque là comme déficient. Débusquer les problèmes obsolètes n'est pas simple : la seule manière de procéder est de passer en revue toute la base de données consciencieusement. Les révisions complètes deviennent plus fastidieuses avec le temps et l'augmentation du nombre de problèmes. Au delà d'un certain point, la seule manière de conserver une base de données saine est d'utiliser la tactique de « diviser pour mieux régner » : classer les problèmes immédiatement quand ils sont rapportés et les rediriger vers le bon développeur ou la bonne équipe. Le destinataire prend alors la responsabilité du problème ad vitam æternam, le menant vers une résolution ou vers l'oubli selon la situation. Quand la base de données devient si importante, le responsable difficultés se mue alors en coordinateur d'ensemble, il passe moins de temps à s'occuper du problème lui même qu'à le rediriger vers la bonne personne.
[modifier] FAQ Manager
FAQ maintenance is a surprisingly difficult problem. Unlike most other documents in a project, whose content is planned out in advance by the authors, a FAQ is a wholly reactive document (see Maintaining a FAQ). No matter how big it gets, you still never know what the next addition will be. And because it is always added to piecemeal, it is very easy for the document as a whole to become incoherent and disorganized, and even to contain duplicate or semi-duplicate entries. Even when it does not have any obvious problems like that, there are often unnoticed interdependencies between items—links that should be made but aren't—because the related items were added a year apart.
The role of a FAQ manager is twofold. First, she maintains the overall quality of the FAQ by staying familiar with at least the topics of all the questions in it, so that when people add new items that are duplicates of, or related to, existing items, the appropriate adjustments can be made. Second, she watches the project mailing lists and other forums for recurring problems or questions, and to write new FAQ entries based on this input. This latter task can be quite complex: one must be able to follow a thread, recognize the core questions raised in it, post a proposed FAQ entry, incorporate comments from others (since it's impossible for the FAQ manager to be an expert in every topic covered by the FAQ), and sense when the process is finished so the item can at last be added.
The FAQ manager usually also becomes the default expert in FAQ formatting. There are a lot of little details involved in keeping a FAQ in shape (see the section called “Treat all resources like archives” in Chapter 6, Communications); when random people edit the FAQ, they will sometimes forget some of these details. That's okay, as long as the FAQ manager is there to clean up after them.
Various free software is available to help with the process of FAQ maintenance. It's fine to use it, as long as it doesn't compromise the quality of the FAQ, but beware of over-automation. Some projects try to fully automate the process of FAQ maintenance, allowing everyone to contribute and edit FAQ items in a manner similar to a wiki (see the section called “Wikis” in Chapter 3, Technical Infrastructure). I've seen this happen particularly with Faq-O-Matic (http://faqomatic.sourceforge.net/), though it may be that the cases I saw were simply abuses that went beyond what Faq-O-Matic was originally intended for. In any case, while complete decentralization of FAQ maintenance does reduce the workload for the project, it also results in a poorer FAQ. There's no one person with a broad view of the entire FAQ, no one to notice when certain items need updating or become obsolete entirely, and no one keeping watch for interdependencies between items. The result is a FAQ that often fails to provide users what they were looking for, and in the worst cases misleads them. Use whatever tools you need to to maintain your project's FAQ, but never let the convenience of the tools seduce you into compromising the quality of the FAQ.
See Sean Michael Kerner's article, The FAQs on FAQs, at http://osdir.com/Article1722.phtml, for descriptions and evaluations of Open Source FAQ maintenance tools.[modifier] Responsable FAQ
L'entretien de la FAQ est un problème étonnamment difficile. Contrairement à la majeur partie des autres documents du projet, dont le contenu est planifié à l'avance par leurs auteurs, une FAQ est un document très réactif (voir « Entretenir une FAQ »). Peu importe la taille atteinte, vous ne savez jamais quel sera le prochain ajout. Et parce qu'elle est complétée pièce par pièce, le document complet peut facilement devenir incohérent et désorganisé, voire même contenir des entrées en double ou très semblables. Même quand vous n'êtes pas confrontés à ces problèmes il y a souvent des liens entre les questions, des liens qui devraient être faits mais qui ne le sont pas car les entrées ont été faites à une année d'intervalle.
Le rôle du responsable FAQ est double. En premier il assure la qualité globale de la FAQ en restant au minimum au courant des sujets de toutes les questions, ainsi quand des gens ajoutent de nouvelles questions déjà posées, ou liées à d'autres déjà posées, il peut réaliser les corrections nécessaires. En deuxième, il surveille les listes de diffusion du projet et les forums pour repérer les problèmes ou les questions récurrents puis il crée une nouvelle entrée à la FAQ en fonction. Cette tâche peut être plutôt compliquée : la personne doit être capable de suivre un sujet, reconnaître le cœur du problème qui y est soulevé, proposer une nouvelle entrée pour la FAQ, tenir compte des commentaires des autres (puisqu'il est impossible que le responsable FAQ soit expert dans tous les domaines couverts par la FAQ) et sentir quand le processus est achevé et que l'entrée peut être ajoutée.
Le responsable FAQ devient en général l'expert de la mise en page de la FAQ par défaut. De nombreux petits détails sont à prendre en compte dans la mise en forme de la FAQ (voir la section appelée « Traiter toutes les ressources comme des archives » dans le Chapitre 6, Communication) ; quand une personne modifie la FAQ elle oubliera souvent certains de ces détails. Ce n'est pas grave tant que le responsable FAQ passe derrière pour corriger ces erreurs.
Différents logiciels libres aidant à l'entretien de la FAQ sont disponibles. Vous pouvez les utiliser tant qu'ils ne compromettent pas la qualité de la FAQ, faites attention à l'abus d'automatisation. Certains projets tentent de rendre l'entretien de la FAQ entièrement automatique, permettant à chacun de contribuer à la FAQ et d'en modifier les entrées, à la manière d'un wiki (voir la section appelée « Wikis » dans le Chapitre 3, Infrastructure technique). C'est particulièrement visible avec le Faq-O-Matic (http://faqomatic.sourceforge.net/), bien que les exemples que j'ai vus pouvaient être dus à une sur-automatisation, ce pour quoi Faq-O-Matic n'est pas prévu à l'origine. Quoi qu'il en soit, alors qu'un entretien de la FAQ complètement décentralisé peut réduire la charge de travail du projet vous devrez vous contentez d'une FAQ de plus mauvaise qualité. Personne n'a une vue d'ensemble de la FAQ, personne ne peut remarquer les articles qui nécessitent une mise à jour ou qui sont devenus complètement obsolètes et personne ne surveille les liens entre les questions. Au final la FAQ parviendra rarement à fournir aux utilisateurs l'aide qu'ils étaient venu chercher et dans le pire des cas les induira en erreur. Utilisez tous les outils nécessaires à l'entretien de la FAQ du projet, mais ne laissez pas l'aspect pratique de ces outils vous pousser à réduire la qualité de la FAQ. Vous pouvez lire l'article de Sean Michael Kerner : La FAQ des FAQ à l'adresse http://osdir.com/Article1722.phtml, vous y trouverez des descriptions et des évaluations d'outils Open Source pour l'entretien d'une FAQ.
