POSS Chap 8

De Framalang Wiki.

Sommaire

1 Chapter 8. Managing Volunteers
2 Forks / Les fourches
- 2.1 Handling a Fork / Gérer une fourche
- 2.2 Initiating a Fork / Amorcer une fourche

Chapter 8. Managing Volunteers

Getting people to agree on what a project needs, and to work together to achieve it, requires more than just a genial atmosphere and a lack of obvious dysfunction. It requires someone, or several someones, consciously managing all the people involved. Managing volunteers may not be a technical craft in the same sense as computer programming, but it is a craft in the sense that it can be improved through study and practice.

This chapter is a grab-bag of specific techniques for managing volunteers. It draws, perhaps more heavily than previous chapters, on the Subversion project as a case study, partly because I was working on that project as I wrote this and had all the primary sources close at hand, and partly because it's more acceptable to cast critical stones into one's own glass house than into others'. But I have also seen in various other projects the benefits of applying—and the consequences of not applying—the recommendations that follow; when it is politically feasible to give examples from some of those other projects, I will do so.

Speaking of politics, this is as good a time as any to drag that much-maligned word out for a closer look. Many engineers like to think of politics as something other people engage in. « I'm just advocating the best course for the project, but she's raising objections for political reasons. » I believe this distaste for politics (or for what is imagined to be politics) is especially strong in engineers because engineers are bought into the idea that some solutions are objectively superior to others. Thus, when someone acts in a way that seems motivated by outside considerations—say, the maintenance of his own position of influence, the lessening of someone else's influence, outright horse-trading, or avoiding hurting someone's feelings—other participants in the project may get annoyed. Of course, this rarely prevents them from behaving in the same way when their own vital interests are at stake.

If you consider « politics » a dirty word, and hope to keep your project free of it, give up right now. Politics are inevitable whenever people have to cooperatively manage a shared resource. It is absolutely rational that one of the considerations going into each person's decision-making process is the question of how a given action might affect his own future influence in the project. After all, if you trust your own judgement and skills, as most programmers do, then the potential loss of future influence has to be considered a technical result, in a sense. Similar reasoning applies to other behaviors that might seem, on their face, like « pure » politics. In fact, there is no such thing as pure politics: it is precisely because actions have multiple real-world consequences that people become politically conscious in the first place. Politics is, in the end, simply an acknowledgment that all consequences of decisions must be taken into account. If a particular decision leads to a result that most participants find technically satisfying, but involves a change in power relationships that leaves key people feeling isolated, the latter is just as important a result as the former. To ignore it would not be high-minded, but shortsighted.

So as you read the advice that follows, and as you work with your own project, remember that there is no one who is above politics. Appearing to be above politics is merely one particular political strategy, and sometimes a very useful one, but it is never the reality. Politics is simply what happens when people disagree, and successful projects are those that evolve political mechanisms for managing disagreement constructively.

Parvenir à mettre les gens d'accord sur les besoins du projet et parvenir à les faire travailler ensemble pour atteindre ce but demande plus qu'une atmosphère sympathique et une absence de dysfonctionnements évidents. Il faut qu'une personne, ou plusieurs personnes, prenne(nt) en charge la gestion des volontaires. Gérer les volontaires n'est peut être pas un art technique au même titre que la programmation mais c'est un art dans le sens où cette discipline peut-être améliorée par l'étude et la mise en pratique.

Ce chapitre n'est pas un ensemble de techniques précises prêtes à l'emploi pour diriger les volontaires. Il s'appuie, peut-être plus encore que les autres chapitres, sur le projet Subversion comme cas d'étude. Ceci est dû en partie au fait que je travaillais sur ce projet au moment de l'écriture, j'avais donc un accès direct à la matière première et en partie aussi parce qu'il est plus acceptable de commencer par une auto-critique. Mais j'ai également pu voir dans d'autres projets les conséquences de la mise en application, ou les conséquences de la non mise en application, des recommandations qui suivent. Lorsqu'il est politiquement correct que je cite des exemples parmi d'autres projets je le ferai.

En parlant de politique, quitte à en discuter, autant le faire maintenant et regarder de plus près ce domaine tant décrié. De nombreux ingénieurs pensent que la politique est une chose à laquelle s'adonnent uniquement les autres. « Je ne fais que défendre la meilleure marche à suivre pour le projet, mais elle soulève des objections pour des raisons politiques. » Je pense que ce dégoût de la politique (ou de ce qui est perçu comme tel) est particulièrement fort chez les ingénieurs car ils adhèrent à l'idée que certaines solutions sont objectivement meilleures que d'autres. Ainsi, quand quelqu'un agit d'une manière qui semble motivée par des considérations externes, par exemple la défense de sa propre position d'influence, l'abaissement de l'influence de quelqu'un d'autre, un retournement de veste manifeste ou encore pour éviter de blesser quelqu'un, d'autres personnes dans le projet pourraient en être gênées. Ce qui ne les empêchera évidemment pas de se comporter de la même manière quand leurs propres intérêts vitaux sont en jeu.

Si pour vous « politique » est un mot sale et que vous espérez qu'il ne vienne pas ternir votre projet vous pouvez abandonner dès maintenant. La politique est inévitable quand des gens doivent gérer une ressource partagée coopérativement. Lors d'une prise de décision il est tout à fait normal de prendre en considération les conséquences que cette décision auront sur notre influence future dans le projet. Après tout, si vous avez confiance en votre propre jugement et vos propres compétences, comme la plupart des programmeurs, le risque de perdre de l'influence doit être considéré comme une donnée technique dans un sens. Un raisonnement similaire s'applique à d'autres comportements qui peuvent, de prime abord, sembler purement politiques. En fait le « purement politique » n'existe pas, c'est bien parce que les actions ont des répercussions dans le monde réel que les gens deviennent « politiquement conscients ». La politique n'est rien d'autre finalement que le fait de reconnaître que toutes les conséquences d'une décision doivent être prises en compte. Si une décision en particulier mène à un résultat que les participants trouvent techniquement satisfaisant mais qui modifie les relations au pouvoir et qui donne un sentiment de mise à l'écart à certains personnages clés, alors ce dernier résultat est au moins aussi important que le résultat technique. L'ignorer n'est pas un signe de noblesse d'esprit mais plutôt de manque de clairvoyance.

Alors en lisant les conseils qui suivent, quand vous travaillez sur votre propre projet, souvenez vous que personne n'est au dessus de la politique. Se donner l'air d'être au dessus de la politique n'est qu'une simple stratégie politique, qui peut parfois être très utile, mais dans tous les cas ce n'est jamais une réalité. La politique est simplement le fruit du désaccord entre certaines personnes et les projets qui réussissent sont ceux qui développent des mécanismes politiques pour gérer les désaccords de manière constructive.

Getting the Most Out of Volunteers

Why do volunteers work on free software projects?[19]

When asked, many claim they do it because they want to produce good software, or want to be personally involved in fixing the bugs that matter to them. But these reasons are usually not the whole story. After all, could you imagine a volunteer staying with a project even if no one ever said a word in appreciation of his work, or listened to him in discussions? Of course not. Clearly, people spend time on free software for reasons beyond just an abstract desire to produce good code. Understanding volunteers' true motivations will help you arrange things so as to attract and keep them. The desire to produce good software may be among those motivations, along with the challenge and educational value of working on hard problems. But humans also have a built-in desire to work with other humans, and to give and earn respect through cooperative activities. Groups engaged in cooperative activities must evolve norms of behavior such that status is acquired and kept through actions that help the group's goals.

Those norms won't always arise by themselves. For example, on some projects—experienced Open Source developers can probably name several off the tops of their heads—people apparently feel that status is acquired by posting frequently and verbosely. They don't come to this conclusion accidentally; they come to it because they are rewarded with respect for making long, intricate arguments, whether or not that actually helps the project. Following are some techniques for creating an atmosphere in which status-acquiring actions are also constructive actions.

Tirer le meilleur des volontaires

Pourquoi les volontaires travaillent-ils sur des projets de logiciels libres ?[19]

Quand on le leur demande, beaucoup disent que c'est parce qu'ils veulent produire un bon logiciel ou qu'ils veulent être personnellement impliqués dans la réparation des bogues qui sont importants pour eux. Mais en général ces raisons ne dévoilent pas tout. Après tout, arrivez vous à imaginer un volontaire s'accrochant à un projet même si personne ne le félicite pour son travail ou ne lui prête attention dans une discussion ? Bien sûr que non. Il est évident que les gens passent du temps sur un logiciel libre pour des raisons qui vont au delà du désir de produire un bon code. Comprendre les motivations réelles des volontaires vous aidera à les attirer et à les garder. Le désir de produire un bon logiciel peut faire partie de ces raisons, avec le défi et l'enrichissement personnel qu'apporte le travail sur des problèmes complexes. Mais les humains ont également un désir inné de travailler avec d'autres humains et de donner et recevoir du respect au travers d'activités coopératives. Les groupes impliqués dans des activités coopératives doivent produire des normes de comportement de sorte qu'une position s'acquiert et se maintient par des actions qui servent les objectifs du groupe.

Ces normes ne vont pas toujours survenir par elles mêmes. Par exemple, sur certains projets, les développeurs Open Source expérimentés peuvent certainement en citer quelques uns de mémoire, les gens apparemment ressentent qu'une position s'acquiert en écrivant fréquemment et verbeusement. Ils n'arrivent pas à cette conclusion par accident, ils y parviennent car ils sont récompensés par du respect lorsqu'ils produisent des arguments longs et compliqués, peu importe si ça aide vraiment le projet. Vous trouverez dans les prochains paragraphes quelques techniques pour créer une atmosphère dans laquelle les actions pour obtenir une position sont également constructives.

Delegation

Delegation is not merely a way to spread the workload around; it is also a political and social tool. Consider all the effects when you ask someone to do something. The most obvious effect is that, if he accepts, he does the task and you don't. But another effect is that he is made aware that you trusted him to handle the task. Furthermore, if you made the request in a public forum, then he knows that others in the group have been made aware of that trust too. He may also feel some pressure to accept, which means you must ask in a way that allows him to decline gracefully if he doesn't really want the job. If the task requires coordination with others in the project, you are effectively proposing that he become more involved, form bonds that might not otherwise have been formed, and perhaps become a source of authority in some subdomain of the project. The added involvement may be daunting, or it may lead him to become engaged in other ways as well, from an increased feeling of overall commitment.

Because of all these effects, it often makes sense to ask someone else to do something even when you know you could do it faster or better yourself. Of course, there is sometimes a strict economic efficiency argument for this anyway: perhaps the opportunity cost of doing it yourself would be too high—there might be something even more important you could do with that time. But even when the opportunity cost argument doesn't apply, you may still want to ask someone else to take on the task, because in the long run you want to draw that person deeper into the project, even if it means spending extra time watching over them at first. The converse technique also applies: if you occasionally volunteer for work that someone else doesn't want or have time to do, you will gain his good will and respect. Delegation and substitution are not just about getting individual tasks done; they're also about drawing people into a closer committment to the project.

Déléguer

Déléguer ne se résume pas à la répartition de la charge de travail, c'est également un outil politique et social. Envisagez les conséquences quand vous demandez à quelqu'un de faire quelque chose. La plus évidente est que, s'il accepte, il fera le travail et pas vous. Mais une autre conséquence est qu'il se rend compte que vous lui faite confiance pour mener cette tâche à bien. De plus, si vous en avez fait la demande dans un forum public, il sait que le reste du groupe est averti de la confiance que vous lui accordez. Il peut aussi se sentir forcé d'accepter, ce qui signifie que vous devez formuler la demande de manière à lui laisser la possibilité de décliner avec élégance l'offre s'il ne veut pas vraiment faire le travail. Si la tâche requiert une coordination avec d'autres membres du projet vous lui offrez effectivement de s'impliquer plus, de créer des liens qui n'auraient autrement jamais été forgés et peut-être de devenir une figure d'autorité dans une sous partie du projet. L'implication supplémentaire peut être intimidante comme elle peut amener à s'engager dans d'autres manières en raison d'un sentiment d'engagement plus grand.

En raison de toutes ces conséquences il vaut mieux parfois demander à quelqu'un d'autre de faire quelque chose, même si vous savez que vous pourriez le faire plus rapidement ou mieux vous même. Bien sûr, certains impératifs d'efficacité vous y amèneront : peut-être que le faire vous même serait illogique, il pourrait y avoir quelque chose de plus important que vous pourriez faire à la place. Mais même quand cette considération ne s'applique pas, vous pouvez choisir de demander à quelqu'un d'autre de faire le travail parce que vous cherchez à l'impliquer plus sur le long terme, même si cela signifie que vous devrez passer plus de temps à le surveiller au départ. La technique inverse est également vraie, si vous vous proposez de faire de temps en temps le travail que quelqu'un d'autre ne veut pas ou n'a pas le temps de faire, vous gagnerez sa bonne volonté et son respect. Déléguer et échanger ne sert pas seulement à voir des tâches ponctuelles accomplies, ça sert aussi à impliquer plus encore les gens dans le projet.

Distinguish clearly between inquiry and assignment

Sometimes it is fair to expect that a person will accept a particular task. For example, if someone writes a bug into the code, or commits code that fails to comply with project guidelines in some obvious way, then it is enough to point out the problem and thereafter behave as though you assume the person will take care of it. But there are other situations where it is by no means clear that you have a right to expect action. The person may do as you ask, or may not. Since no one likes to be taken for granted, you need to be sensitive to the difference between these two types of situations, and tailor your requests accordingly.

One thing that almost always causes people instant annoyance is being asked to do something in a way that implies that you think it is clearly their responsibility to do it, when they feel otherwise. For example, assignment of incoming issues is particularly fertile ground for this kind of annoyance. The participants in a project usually know who is expert in what areas, so when a bug report comes in, there will often be one or two people whom everyone knows could probably fix it quickly. However, if you assign the issue over to one of those people without her prior permission, she may feel she has been put into an uncomfortable position. She senses the pressure of expectation, but also may feel that she is, in effect, being punished for her expertise. After all, the way one acquires expertise is by fixing bugs, so perhaps someone else should take this one! (Note that issue trackers that automatically assign issues to particular people based on information in the bug report are less likely to offend, because everyone knows that the assignment was made by an automated process, and is not an indication of human expectations.)

While it would be nice to spread the load as evenly as possible, there are certain times when you just want to encourage the person who can fix a bug the fastest to do so. Given that you can't afford a communications turnaround for every such assignment ("Would you be willing to look at this bug? » « Yes. » « Okay, I'm assigning the issue over to you then. » « Okay."), you should simply make the assignment in the form of an inquiry, conveying no pressure. Virtually all issue trackers allow a comment to be associated with the assignment of an issue. In that comment, you can say something like this:

   Assigning this over to you, jrandom, because you're most familiar with this code. Feel free to bounce this back if you don't have time to look at it, though. (And let me know if you'd prefer not to receive such requests in the future.)

This distinguishes clearly between the request for assignment and the recipient's acceptance of that assignment. The audience here isn't only the assignee, it's everyone: the entire group sees a public confirmation of the assignee's expertise, but the message also makes it clear that the assignee is free to accept or decline the responsibility.

Distinguer clairement requête et assignation

Parfois il est juste d'attendre d'une personne qu'elle accepte une tâche particulière. Par exemple, si quelqu'un ajoute un bogue au code ou produit des lignes de code qui ne correspondent manifestement pas à la ligne directrice du projet, il suffit de signaler le problème et ensuite de montrer que vous attendez que la personne s'en occupe. Mais dans d'autres situations il n'est pas aussi légitime que vous attendiez cette réactivité. La personne peut faire ce que vous lui demandez comme elle peut ne pas le faire. Comme personne n'aime que sa coopération soit considérée comme quelque chose d'assuré, vous devez tenir compte de la différence entre ces deux types de situations et adapter votre demande en conséquence.

Ce qui irritera les gens à cup sûr est qu'on leur demande de faire quelque chose d'une manière impliquant clairement que vous pensez que c'est leur responsabilité de le faire alors qu'ils ne partagent pas ce sentiment. Par exemple, la distribution des tâches à venir est particulièrement sujette à ce type d'irritation. Les participants à un projet savent en général qui est expert dans quel domaine, donc quand un bogue est signalé tout le monde pensera à une ou deux personnes qui pourraient le réparer rapidement. Cependant, si vous assignez cette mission à l'une de ces personnes sans avoir son accord, elle pourrait se sentir mise dans une position inconfortable. La personne ressent la pression des attentes mais elle le prend également comme une punition pour son savoir faire en fait. Après tout, c'est en réparant des bogues que les gens acquièrent de l'expérience, alors peut-être que quelqu'un d'autre pourrait s'occuper de celui-ci ! (Remarquez qu'émettre des rapports de bogues qui assignent automatiquement les problèmes à certaines personnes en se basant sur les informations contenues dans la rapport de bogue risque moins d'offenser parce que chacun sait que la désignation a été faite par un processus automatisé et qu'elle ne traduit pas les attentes d'autres humains)

Alors qu'il serait mieux de répartir la charge de travail aussi équitablement que possible, en certaines occasions vous voudrez surtout encourager la personne qui peut résoudre le bogue le plus vite à le faire. Puisque que vous ne pouvez pas vous permettre un tel revirement de communication pour chaque cas similaire (« Serais tu prêt à jeter un œil à ce bogue ? » « Oui. » « Ok, je te donne alors ce travail. » « Ok. »), vous devriez plutôt formuler la demande comme une requête, sans pression. Quasiment tous les outils de suivi des bogues permettent d'associer un commentaire à l'assignation d'une tâche. Dans ce commentaire, vous pourriez dire quelque chose comme ceci :

  Je te confis cette tâche, A.Nonyme, parce que tu es celui qui est le plus familier avec ce code. Tu es libre de refuser si tu n'as pas le temps de t'y pencher malgré tout (Et fais moi savoir si tu préférerais ne plus recevoir ce genre de demande dans le futur).

Vous séparez ainsi distinctement la proposition d'assignation et l'acceptation par l'intéressé de l'assignation. Le public ici n'est pas seulement la personne en question, c'est tout le monde : le groupe entier a la confirmation publique de l'expérience de l'assigné mais le message indique clairement qu'il est libre d'accepter ou de refuser la responsabilité.

Follow up after you delegate

When you ask someone to do something, remember that you have done so, and follow up with him no matter what. Most requests are made in public forums, and are roughly of the form « Can you take care of X? Let us know either way; no problem if you can't, just need to know. » You may or may not get a response. If you do, and the response is negative, the loop is closed—you'll need to try some other strategy for dealing with X. If there is a positive response, then keep an eye out for progress on the issue, and comment on the progress you do or don't see (everyone works better when they know someone else is appreciating their work). If there is no response after a few days, ask again, or post saying that you got no response and are looking for someone else to do it. Or just do it yourself, but still make sure to say that you got no response to the initial inquiry.

The purpose of publicly noting the lack of response is not to humiliate the person, and your remarks should be phrased so as not to have that effect. The purpose is simply to show that you keep track of what you have asked for, and that you notice the reactions you get. This makes people more likely to say yes next time, because they will observe (even if only unconsciously) that you are likely to notice any work they do, given that you noticed the much less visible event of someone failing to respond.

Le suivi après la délégation

Lorsque vous demandez à quelqu'un de faire quelque chose, souvenez vous que l'avez fait et suivez le travail avec lui quoiqu'il arrive. La plupart des requêtes sont formulées sur des forums publics et suivent à peu près le même modèle « Est-ce que tu peux t'occuper de X ? Fais le nous savoir, c'est pas grave si tu ne peux pas, il faut juste qu'on sache. » Vous recevrez, ou ne recevrez pas, une réponse. Si vous en recevez et qu'elle est négative vous êtes de retour à votre point de départ et vous devrez tenter une autre stratégie vis à vis du problème X. Si la réponse est positive gardez un œil sur le progrès fait dans ce secteur et commentez les avancées faites ou celles qui ne le sont pas (n'importe qui travaille mieux lorsqu'il sait que quelqu'un juge son œuvre). S'il n'y a pas de réponse après quelques jours, répétez votre demande ou écrivez que vous n'avez pas reçu de réponse et que vous êtes à la recherche de quelqu'un d'autre pour cette tâche. Ou faites la vous même, mais assurez vous d'annoncer que vous n'avez pas reçu de réponse après votre première demande.

Le but n'est pas d'humilier la personne en constatant publiquement l'absence de réponse, vos remarques devraient être tournées de telle sorte qu'elles n'aient pas cet effet. Le but est simplement de montrer que vous savez où vous en êtes et que vous prenez en compte les réponses reçues. Les gens seront plus prompt à dire oui la prochaine fois, car ils verront (même si c'est de manière inconsciente) que vous êtes en mesure de remarquer le travail qu'ils fournissent puisque vous avez noté le fait beaucoup moins visible que quelqu'un n'a pas donné de réponse.

Notice what people are interested in

Another thing that makes people happy is to have their interests noticed—in general, the more aspects of someone's personality you notice and remember, the more comfortable he will be, and the more he will want to work with groups of which you are a part.

For example, there was a sharp distinction in the Subversion project between people who wanted to reach a definitive 1.0 release (which we eventually did), and people who mainly wanted to add new features and work on interesting problems but who didn't much care when 1.0 came out. Neither of these positions is better or worse than the other; they're just two different kinds of developers, and both kinds do lots of work on the project. But we swiftly learned that it was important to not assume that the excitement of the 1.0 drive was shared by everyone. Electronic media can be very deceptive: you may sense an atmosphere of shared purpose when, in fact, it's shared only by the people you happen to have been talking to, while others have completely different priorities.

The more aware you are of what people want out of the project, the more effectively you can make requests of them. Even just demonstrating an understanding of what they want, without making any associated request, is useful, in that it confirms to each person that she's not just another particle in an undifferentiated mass.

Remarquer les centres d'intérêts des gens

Une autre chose qui fait plaisir aux gens est que l'on remarque leurs centres d'intérêts. En général mieux vous connaissez et gardez en mémoire les facettes de la personnalité de quelqu'un plus cette personne se sentira à l'aise et plus elle voudra travailler au sein de votre groupe.

Par exemple, il y avait une distinction marquée, dans le projet Subversion, entre ceux qui voulaient atteindre la version 1.0 définitive (ce qui s'est finalement réalisé) et ceux qui voulaient principalement ajouter de nouvelles fonctionnalités et travailler sur des problèmes intéressants mais qui ne se souciaient pas de la date de sortie de la version 1.0. Il n'y a pas de bonne ou de mauvaise approche, il y a simplement deux types de développeurs et les deux abattent beaucoup de travail pour le projet. Mais on a rapidement appris qu'il ne fallait pas supposer que l'excitation de la dernière ligne droite avant la sortie de la version 1.0 était partagée par tous. Les communications électroniques peuvent être très trompeuses, vous pouvez ressentir que vos intentions sont partagées alors qu'en fait ce n'est vrai que pour les personnes avec qui vous étiez en contact et que les autres ont des priorités complètement différentes.

Plus vous serez conscient des attentes des gens vis-à-vis du projet mieux vous serez à même de formuler vos demandes de manière efficace. Rien que le fait de montrer que vous comprenez ce qu'ils désirent, sans faire de requête liée, est utile par le simple fait que ces personnes sont rassurées de savoir qu'elles ne sont pas qu'un simple grain de sable au milieu d'un désert uniforme.

Praise and Criticism

Praise and criticism are not opposites; in many ways, they are very similar. Both are primarily forms of attention, and are most effective when specific rather than generic. Both should be deployed with concrete goals in mind. Both can be diluted by inflation: praise too much or too often and you will devalue your praise; the same is true for criticism, though in practice, criticism is usually reactive and therefore a bit more resistant to devaluation.

An important feature of technical culture is that detailed, dispassionate criticism is often taken as a kind of praise (as discussed in the section called “Recognizing Rudeness” in Chapter 6, Communications), because of the implication that the recipient's work is worth the time required to analyze it. However, both of those conditions—detailed and dispassionate—must be met for this to be true. For example, if someone makes a sloppy change to the code, it is useless (and actually harmful) to follow up saying simply « That was sloppy. » Sloppiness is ultimately a characteristic of a person, not of their work, and it's important to keep your reactions focused on the work. It's much more effective to describe all the things wrong with the change, tactfully and without malice. If this is the third or fourth careless change in a row by the same person, it's appropriate to say that—again without anger—at the end of your critique, to make it clear that the pattern has been noticed.

If someone does not improve in response to criticism, the solution is not more or stronger criticism. The solution is for the group to remove that person from the position of incompetence, in a way that minimizes hurt feelings as much as possible; see the section called “Transitions” later in this chapter for examples. That is a rare occurrence, however. Most people respond pretty well to criticism that is specific, detailed, and contains a clear (even if unspoken) expectation of improvement.

Praise won't hurt anyone's feelings, of course, but that doesn't mean it should be used any less carefully than criticism. Praise is a tool: before you use it, ask yourself why you want to use it. As a rule, it's not a good idea to praise people for doing what they usually do, or for actions that are a normal and expected part of participating in the group. If you were to do that, it would be hard to know when to stop: should you praise everyone for doing the usual things? After all, if you leave some people out, they'll wonder why. It's much better to express praise and gratitude sparingly, in response to unusual or unexpected efforts, with the intention of encouraging more such efforts. When a participant seems to have moved permanently into a state of higher productivity, adjust your praise threshold for that person accordingly. Repeated praise for normal behavior gradually becomes meaningless anyway. Instead, that person should sense that her high level of productivity is now considered normal and natural, and only work that goes beyond that should be specially noticed.

This is not to say that the person's contributions shouldn't be acknowledged, of course. But remember that if the project is set up right, everything that person does is already visible anyway, and so the group will know (and the person will know that the rest of the group knows) everything she does. There are also ways to acknowledge someone's work by means other than direct praise. You could mention in passing, while discussing a related topic, that she has done a lot of work in the given area and is the resident expert there; you could publicly consult her on some question about the code; or perhaps most effectively, you could conspicuously make further use of the work she has done, so she sees that others are now comfortable relying on the results of her work. It's probably not necessary to do these things in any calculated way. Someone who regularly makes large contributions in a project will know it, and will occupy a position of influence by default. There's usually no need to take explicit steps to ensure this, unless you sense that, for whatever reason, a contributor is underappreciated.

Félicitations et critiques

Les félicitations et les critiques ne sont pas antonymes, elles sont très semblables de bien des manières. Toutes les deux sont premièrement des formes d'attention et sont plus efficaces quand elles sont précises plutôt que vagues. Les deux devraient être utilisées à des fins particulières. Les deux perdent de leur valeur en cas de surabondance, louer trop ou trop souvent et vos louanges s'en retrouveront amoindries, il en va de même pour les critiques, bien qu'en pratique elles soient généralement plus marquantes et du coup moins sensibles à la dévaluation.

L'un des aspects important de la culture technique est que les critiques détaillées et objectives sont souvent prises comme une sorte de compliment (comme on a vu dans la section nommée « Reconnaître l'insolence » dans le Chapitre 6, Communication), car elles impliquent que le travail de celui qui les reçoit est suffisamment important pour qu'on prenne du temps pour l'analyser. Cependant, ces deux conditions, c'est-à-dire détaillées et objectives, doivent être remplies pour que ceci soit vérifié. Par exemple, si quelqu'un modifie le code de manière brouillonne il est inutile (et même dangereux) de faire le suivi en disant simplement « C'était brouillon ». Le manque de soin est en fin de compte une caractéristique de la personne, pas de son travail, et il est important que vos réponses portent sur le travail. Il est beaucoup plus efficace de détailler ce qui ne va pas dans les changements, avec tact et sans méchanceté. Si c'est déjà la troisième ou quatrième modification négligente consécutive de cette personne, il est adéquat de dire, encore une fois sans énervement, à la fin de votre commentaire que cette habitude a été remarquée.

Si quelqu'un ne s'améliore pas en réponse aux critiques la solution n'est pas de le critiquer plus ou plus véhément. La solution est que le groupe doit retirer à cette personne la responsabilité de la position pour laquelle elle n'a pas les compétences, en évitant le plus possible de la blesser, référer vous aux exemples de la section « Transitions » plus loin dans ce chapitre. Ceci arrive rarement cependant. La plupart des gens réagissent bien aux critiques précises, détaillées et qui véhiculent (même de manière implicite) une attente d'amélioration.

Les louanges ne blesseront évidemment personne, mais ça ne veut pas dire que leur usage doit être plus libre que celui des critiques. Les louanges sont un outil : avant de les utiliser demandez vous quels sont vos motivations. Une des règles est qu'il n'est pas judicieux de féliciter les gens pour ce qu'ils font d'habitude ou pour ce qui est normal et attendu de leur part dans le groupe. Si vous commenciez ceci il deviendrait difficile de savoir où vous arrêtez : devriez vous féliciter chacun pour avoir fait son travail habituel ? C'est risqué car si vous en oubliez certains ils se demanderont pourquoi. Il vaut bien mieux exprimer son appréciation et sa gratitude avec parcimonie, pour des efforts inhabituels ou non sollicités, avec l'intention d'encourager ce genre de pratique. Lorsqu'un des participants montre une augmentation durable de sa productivité, ajustez vos attentes et vos félicitations en fonction. Des félicitations répétées pour une attitude normale deviennent au fur et à mesure vides de sens de toute façon. Cette personne devrait plutôt ressentir que son activité accrue est maintenant considérée comme normale et naturelle et que c'est seulement son travail plus poussé encore qui sera remarqué.

Ça ne veut pas dire que la participation de cette personne ne devrait pas être reconnue bien sûr. Mais souvenez vous que si le projet est bien construit, tout ce que fait cette personne sera visible de toute façon et le groupe saura (et la personne saura que le groupe sait) tout ce qu'elle fait. Il y a également d'autres manières de reconnaître le travail de quelqu'un que par des félicitations. Vous pourriez mentionner en passant, dans un sujet lié, que la personne a accompli beaucoup de travail dans ce domaine ce qui fait d'elle une référence en la matière dans le groupe, vous pouvez la consulter publiquement pour les questions relatives au code. Ou même mieux : vous pouvez, par la suite, utiliser plus ostensiblement ce qu'elle a fait afin qu'elle voit bien que les autres lui font suffisamment confiance pour s'appuyer sur les résultats de son travail. Tout ceci n'a pas besoin d'être calculé. Celui ou celle qui contribue beaucoup et régulièrement au projet le remarquera et acquerra automatiquement une position influente. Vous n'aurez en général rien de particulier à faire en ce sens, à moins que vous ne sentiez pour une raison ou pour une autre qu'un participant est sous estimé.

Prevent Territoriality

Watch out for participants who try to stake out exclusive ownership of certain areas of the project, and who seem to want to do all the work in those areas, to the extent of aggressively taking over work that others start. Such behavior may even seem healthy at first. After all, on the surface it looks like the person is taking on more responsibility, and showing increased activity within a given area. But in the long run, it is destructive. When people sense a « no trespassing » sign, they stay away. This results in reduced review in that area, and greater fragility, because the lone developer becomes a single point of failure. Worse, it fractures the cooperative, egalitarian spirit of the project. The theory should always be that any developer is welcome to help out on any task at any time. Of course, in practice things work a bit differently: people do have areas where they are more and less influential, and non-experts frequently defer to experts in certain domains of the project. But the key is that this is all voluntary: informal authority is granted based on competence and proven judgement, but it should never be actively taken. Even if the person desiring the authority really is competent, it is still crucial that she hold that authority informally, through the consensus of the group, and that the authority never cause her to exclude others from working in that area.

Rejecting or editing someone's work for technical reasons is an entirely different matter, of course. There, the decisive factor is the content of the work, not who happened to act as gatekeeper. It may be that the same person happens to do most of the reviewing for a given area, but as long as he never tries to prevent someone else from doing that work too, things are probably okay.

In order to combat incipient territorialism, or even the appearance of it, many projects have taken the step of banning the inclusion of author names or designated maintainer names in source files. I wholeheartedly agree with this practice: we follow it in the Subversion project, and it is more or less official policy at the Apache Software Foundation. ASF member Sander Striker puts it this way:

   At the Apache Software foundation we discourage the use of author tags in source code. There are various reasons for this, apart from the legal ramifications. Collaborative development is about working on projects as a group and caring for the project as a group. Giving credit is good, and should be done, but in a way that does not allow for false attribution, even by implication. There is no clear line for when to add or remove an author tag. Do you add your name when you change a comment? When you put in a one-line fix? Do you remove other author tags when you refactor the code and it looks 95% different? What do you do about people who go about touching every file, changing just enough to make the virtual author tag quota, so that their name will be everywhere?

   There are better ways to give credit, and our preference is to use those. From a technical standpoint author tags are unnecessary; if you wish to find out who wrote a particular piece of code, the version control system can be consulted to figure that out. Author tags also tend to get out of date. Do you really wish to be contacted in private about a piece of code you wrote five years ago and were glad to have forgotten?

A software project's source code files are the core of its identity. They should reflect the fact that the developer community as a whole is responsible for them, and not be divided up into little fiefdoms.

People sometimes argue in favor of author or maintainer tags in source files on the grounds that this gives visible credit to those who have done the most work there. There are two problems with this argument. First, the tags inevitably raise the awkward question of how much work one must do to get one's own name listed there too. Second, they conflate the issue of credit with that of authority: having done work in the past does not imply ownership of the area where the work was done, but it's difficult if not impossible to avoid such an implication when individual names are listed at the tops of source files. In any case, credit information can already be obtained from the version control logs and other out-of-band mechanisms like mailing list archives, so no information is lost by banning it from the source files themselves.

If your project decides to ban individual names from source files, make sure not to go overboard. For instance, many projects have a contrib/ area where small tools and helper scripts are kept, often written by people who are otherwise not associated with the project. It's fine for those files to contain author names, because they are not really maintained by the project as a whole. On the other hand, if a contributed tool starts getting hacked on by other people in the project, eventually you may want to move it to a less isolated location and, assuming the original author approves, remove the author's name, so that the code looks like any other community-maintained resource. If the author is sensitive about this, compromise solutions are acceptable, for example:

   # indexclean.py: Remove old data from a Scanley index.
   #
   # Original Author: K. Maru <kobayashi@yetanothere-mailservice.com>
   # Now Maintained By: The Scanley Project <http://www.scanley.org/>
   #                    and K. Maru.
   # 
   # ...

But it's better to avoid such compromises, if possible, and most authors are willing to be persuaded, because they're happy that their contribution is being made a more integral part of the project.

The important thing is to remember that there is a continuum between the core and the periphery of any project. The main source code files for the software are clearly part of the core, and should be considered as maintained by the community. On the other hand, companion tools or pieces of documentation may be the work of single individuals, who maintain them essentially alone, even though the works may be associated with, and even distributed with, the project. There is no need to apply a one-size-fits-all rule to every file, as long as the principle that community-maintained resources are not allowed to become individual territories is upheld.

Éviter le marquage de territoire

Faites attention aux participants qui tentent de revendiquer la propriété exclusive de certains domaines du projet et qui semblent vouloir faire tout le travail sur cette partie, jusqu'à reprendre agressivement la main sur une tâche que d'autres ont commencée. Un tel comportement peut sembler bénéfique à première vue. Après tout, en surface il semble que cette personne ait décidé de prendre plus de responsabilités et accroisse son activité dans un domaine donné. Mais à long terme c'est destructeur. Quand les gens voient un panneau « Défense d'entrer » ils se tiennent à l'écart. Le résultat est que moins d'inspections sont faites sur cette partie et s'en suit une plus grande fragilité, parce que le développeur devient l'unique pierre de voûte. Pire encore, ça créé une rupture dans la collaboration, dans l'esprit égalitaire du projet. En théorie n'importe quel développeur devrait être libre d'aider à n'importe quelle tâche à n'importe quel moment. Bien sûr, en pratique les choses sont légèrement différentes : les gens ont en effet des domaines où leur influence est plus ou moins grande et les non-experts s'en remettent fréquemment aux experts dans certains domaines du projet. Mais ce qui compte est que tout ceci est volontaire : l'autorité informelle est accordée sur des compétences et un jugement éprouvé, mais ça ne doit pas être un processus actif. Même si la personne est effectivement compétente dans le domaine où elle recherche plus d'autorité il est crucial qu'elle maintienne le caractère informelle de cette autorité au travers du consensus du groupe et que son autorité ne la pousse jamais à empêcher les autres de commencer à travailler dans ce domaine.

Rejeter ou modifier le travail de quelqu'un pour des raisons techniques est quelque chose de complètement différent bien sûr. Ici le facteur déterminant est le contenu du travail, pas qui joue le rôle de gardien. Il se peut que ce soit une même personne qui fasse la majeure partie des inspections dans un domaine, mais tout devrait bien se passer tant qu'elle n'essaie pas d'empêcher d'autres personnes de faire ce travail aussi.

Afin de lutter contre le territorialisme naissant, ou même ce qui en prend l'apparence, de nombreux projets ont pris l'initiative de ne plus citer le nom des auteurs ou des responsables dans les fichiers sources. J'approuve complètement cette pratique : nous faisons de même dans le projet Subversion et c'est plus ou moins la politique officiel de l'Apache Software Foundation. Un membre de l'ASF, Sander Striker, l'explique ainsi :

   A l'Apache Software Foundation nous n'encourageons pas l'utilisation d'une signature d'auteur dans le code source. Les raisons sont diverses pour cela et ne se limitent pas qu'aux répercussions légales. Le développement collaboratif c'est avant tout travailler sur des projets en tant que groupe et s'occuper du projet en tant que groupe. Donner sa reconnaissance est une bonne chose et devrait être fait, mais d'une manière qui ne permet pas de fausses attributions, même implicite. Et comment savoir quand ajouter sa signature ? Est-ce que vous signez de votre nom quand vous modifiez un commentaire ? Quand vous ajoutez une amélioration d'une ligne ? Est-ce que vous retirez le nom de l'auteur quand vous devez revoir le code et qu'au final il est transformé à 95% ? Qu'en est-il de ceux qui vont modifier ça et là des documents, juste assez pour atteindre un quota virtuel de travail pour pouvoir ajouter leur signature et ainsi avoir leur nom partout?

   Il y a de meilleurs moyens d'exprimer sa reconnaissance et c'est ceux là que nous privilégions. Du point de vue technique les signatures des auteurs ne sont pas nécessaires, si vous désirez savoir qui a écrit une partie du code en particulier vous pouvez consulter le logiciel de gestion de version pour le trouver. Les signatures périment également. Voulez vous vraiment être contacté en privé à propos d'un morceau de code que vous avez écrit il y a cinq ans et que vous étiez content d'avoir oublié ?

Les fichiers du code source d'un logiciel représentent sa carte d'identité. Ils devraient montrer que c'est la communauté entière de développeurs qui en est à l'origine et ne devraient pas être divisés en plusieurs petits fiefs.

Certaines personnes défendent leur position en faveur du maintien des signatures des développeurs ou de la personne en charge du fichier source pour la seule raison que c'est une manière voyante de mettre en avant ceux qui ont accompli le plus de travail. Cet argument pose deux problèmes. En premier, les signatures soulèvent la question embarrassante de la quantité de travail nécessaire pour avoir le droit d'ajouter son nom. En deuxième, elles fusionnent les questions du mérite avec celle de l'autorité : le travail effectué dans le passé ne donne pas la propriété dans le domaine où il a été fait, mais il est difficile, voir impossible, d'éviter ce genre de méprises lorsque le nom d'individus apparaît en haut des fichiers source. Dans tous les cas, les informations relatives au mérite se trouvent déjà dans les journaux de gestion de version ou d'autres outils discrets comme les archives des listes de diffusion, ainsi on ne perd rien en retirant les signatures des fichiers sources eux-mêmes.

Si votre projet décide de bannir les noms des fichiers sources, assurez vous de ne pas aller trop loin. Par exemple, de nombreux projets ont une zone « contributions » où des outils légers et des scripts d'aide sont conservés, souvent écrits par des gens qui ne sont autrement pas associés au projet. Que ces fichiers contiennent le nom de leurs auteurs est une bonne chose car ils ne sont pas vraiment entretenus par le projet. D'un autre côté, si un outil de ce type est inspecté et amélioré par d'autres dans le projet vous pourriez finalement décider de le déplacer vers un endroit plus en vue et, en supposant que l'auteur original approuve, retirer le nom de l'auteur afin que le code ressemble à n'importe quelle autre ressource entretenue par la communauté. Si l'auteur est tatillon sur ce point, des compromis peuvent être trouvés, par exemple :

  # indexclean.py: Remove old data from a Scanley index.
  #
  # Original Author: K. Maru <kobayashi@yetanothere-mailservice.com>
  # Now Maintained By: The Scanley Project <http://www.scanley.org/>
  #                    and K. Maru.
  # 
  # ...

ou en français :

  # indexclean.py: Nettoie les anciennes données d'un index de Scanley
  #
  # Auteur original: K. Maru <kobayashi@yetanothere-mailservice.com>
  # Maintenant géré par: The Scanley Project <http://www.scanley.org/>
  #                    and K. Maru.
  # 
  # ...

Mais il vaut mieux éviter ce genre de compromis si c'est possible. En général les auteurs sont très ouverts à la persuasion car ils sont contents si leur contribution devient partie intégrante d'un projet.

La chose importante à retenir est qu'il n'y a pas de continuité entre le cœur et la périphérie d'un projet. Les principaux fichiers du code source du logiciel font évidemment partie du cœur et en tant que tels, la communauté doit clairement affirmer qu'elle en assure l'entretien. A l'opposé, des outils d'aide ou des morceaux de documentation peuvent être le fruit du travail d'une personne, qui s'en occupe principalement seul, même si les travaux peuvent être associés au projet et même distribués avec. Vous n'avez pas besoin d'appliquer un modèle unique pour tous les fichiers tant que le principe d'anonymat sur les ressources entretenues par le projet est respecté.

The Automation Ratio

Try not to let humans do what machines could do instead. As a rule of thumb, automating a common task is worth at least ten times the effort a developer would spend doing that task manually one time. For very frequent or very complex tasks, that ratio could easily go up to twenty or even higher.

Thinking of yourself as a « project manager », rather than just another developer, may be a useful attitude here. Sometimes individual developers are too wrapped up in low-level work to see the big picture and realize that everyone is wasting a lot of effort performing automatable tasks manually. Even those who do realize it may not take the time to solve the problem: because each individual performance of the task does not feel like a huge burden, no one ever gets annoyed enough to do anything about it. What makes automation compelling is that that small burden is multiplied by the number of times each developer incurs it, and then that number is multiplied by the number of developers.

Here, I am using the term « automation » broadly, to mean not only repeated actions where one or two variables change each time, but any sort of technical infrastructure that assists humans. The minimum standard automation required to run a project these days was described in Chapter 3, Technical Infrastructure, but each project may have its own special problems too. For example, a group working on documentation might want to have a Web site displaying the most up-to-date versions of the documents at all times. Since documentation is often written in a markup language like XML, there may be a compilation step, often quite intricate, involved in creating displayable or downloadable documents. Arranging a Web site where such compilation happens automatically on every commit can be complicated and time-consuming—but it is worth it, even if it costs you a day or more to set up. The overall benefits of having up-to-date pages available at all times are huge, even though the cost of not having them might seem like only a small annoyance at any single moment, to any single developer.

Taking such steps eliminates not merely wasted time, but the griping and frustration that ensue when humans make missteps (as they inevitably will) in trying to perform complicated procedures manually. Multi-step, deterministic operations are exactly what computers were invented for; save your humans for more interesting things.

La bonne dose d'automatisation

Confiez autant que possible aux machines plutôt qu'aux humains les tâches qu'elles peuvent accomplir. Par expérience, une tâche sera effectuée dix fois plus efficacement si elle est automatisée que si un développeur l'avait faite manuellement. Ce gain peut atteindre à un facteur vingt ou plus encore pour les opérations très fréquentes ou très complexes.

Vous voir comme « dirigeant du projet », plutôt que comme un développeur parmi d'autres, pourrait vous être utile ici. Parfois les développeurs ont trop le nez dans le travail de fond pour avoir une vue d'ensemble et réaliser que tout le monde gaspille son temps à accomplir à la main des fonctions automatisables. Même ceux qui s'en rendent compte peuvent ne pas prendre le temps de résoudre le problème : puisque chaque tâche prise individuellement ne semble par être si fastidieuse personne ne prend jamais la peine d'y changer quelque chose. Ce qui rend l'automatisation attirante est que le somme de ces petites tâches est multiplié par le nombre de fois que chaque développeur doit s'y atteler et que ce chiffre est encore multiplié par le nombre de développeurs.

Ici je prend le terme « automatisation » dans une conception large pour désigner non seulement les actions répétées où une ou deux variables changent chaque fois mais aussi tout type d'infrastructure technique qui aident les humains. Le minimum syndical d'automatisation a été décrit dans le Chapitre 3, Infrastructure technique, mais chaque projet rencontre ses propres obstacles. Par exemple, un groupe travaillant sur la documentation pourrait vouloir un site Web affichant en permanence la dernière version des documents. Comme la documentation est souvent écrite dans un langage apportant une certaine valeur ajoutée il se peut qu'il y ait une étape de compilation, souvent assez complexe, permettant la création de documents affichables ou téléchargeables. Mettre en place un site Web où cette compilation est automatisée à chaque publication des modifications peut être difficile et demander beaucoup de temps, mais ça en vaut la peine, même si ça vous prend un jour ou deux à mettre en place. Que les pages soient constamment à jours vous apportera un gain énorme même si le fait qu'elles ne le soient pas pourra vous sembler n'être qu'un désagrément léger et ponctuel.

Prendre ce genre de mesures n'élimine pas simplement une perte de temps mais aussi les plaintes et la frustration résultantes d'erreurs humaines (et il y en aura forcément) au cours de l'accomplissement manuel de procédures complexes. C'est bien pour réaliser des opérations déterministes en plusieurs étapes que les ordinateurs ont été inventés, laissant plus de temps aux humains pour les choses plus intéressantes.

Automated testing

Automated test runs are helpful for any software project, but especially so for Open Source projects, because automated testing (especially regression testing) allows developers to feel comfortable changing code in areas they are unfamiliar with, and thus encourages exploratory development. Since detecting breakage is so hard to do by hand—one essentially has to guess where one might have broken something, and try various experiments to prove that one didn't—having automated ways to detect such breakage saves the project a lot of time. It also makes people much more relaxed about refactoring large swaths of code, and therefore contributes to the software's long-term maintainability.

Regression Testing

Regression testing means testing for the reappearance of already-fixed bugs. The purpose of regression testing is to reduce the chances that code changes will break the software in unexpected ways. As a software project gets bigger and more complicated, the chances of such unexpected side effects increase steadily. Good design can reduce the rate at which the chances increase, but it cannot eliminate the problem entirely.

As a result, many projects have a test suite, a separate program that invokes the project's software in ways that have been known in the past to stimulate specific bugs. If the test suite succeeds in making one of these bugs happen, this is known as a regression, meaning that someone's change unexpectedly unfixed a previously-fixed bug.

Regression testing is not a panacea. For one thing, it works best for programs with batch-style interfaces. Software that is operated primarily through graphical user interfaces is much harder to drive programmatically. Another problem is that the regression test suite framework itself can often be quite complex, with a learning curve and maintenance burden all its own. Reducing this complexity is one of the most useful things you can do, even though it may take a considerable amount of time. The easier it is to add new tests to the suite, the more developers will do so, and the fewer bugs will survive to release. Any effort spent making tests easier to write will be paid back manyfold over the lifetime of the project.

Many projects have a « Don't break the build! » rule, meaning: don't commit a change that makes the software unable to compile or run. Being the person who broke the build is usually cause for mild embarrassment and ribbing. Projects with regression test suites often have a corollary rule: don't commit any change that causes tests to fail. Such failures are easiest to spot if there are automatic nightly runs of the entire test suite, with the results mailed out to the development list or to a dedicated test-results mailing list; that's another example of a worthwhile automation.

Most volunteer developers are willing to take the extra time to write regression tests, when the test system is comprehensible and easy to work with. Accompanying changes with tests is understood to be the responsible thing to do, and it's also an easy opportunity for collaboration: often two developers will divide up the work for a bugfix, with one writing the fix itself, and the other writing the test. The latter developer may often end up with more work, and since writing a test is already less satisfying than actually fixing the bug, it is imperative that the test suite not make the experience more painful than it has to be.

Some projects go even further, requiring that a new test accompany every bugfix or new feature. Whether this is a good idea or not depends on many factors: the nature of the software, the makeup of the development team, and the difficulty of writing new tests. The CVS (http://www.cvshome.org/) project has long had such a rule. It is a good policy in theory, since CVS is version control software and therefore very risk-averse about the possibility of munging or mishandling the user's data. The problem in practice is that CVS's regression test suite is a single huge shell script (amusingly named sanity.sh), hard to read and hard to modify or extend. The difficulty of adding new tests, combined with the requirement that patches be accompanied by new tests, means that CVS effectively discourages patches. When I used to work on CVS, I sometimes saw people start on and even complete a patch to CVS's own code, but give up when told of the requirement to add a new test to sanity.sh.

It is normal to spend more time writing a new regression test than on fixing the original bug. But CVS carried this phenomenon to an extreme: one might spend hours trying to design one's test properly, and still get it wrong, because there are just too many unpredictable complexities involved in changing a 35,000-line Bourne shell script. Even longtime CVS developers often grumbled when they had to add a new test.

This situation was due to a failure on all our parts to consider the automation ratio. It is true that switching to a real test framework—whether custom-built or off-the-shelf—would have been a major effort.[20] But neglecting to do so has cost the project much more, over the years. How many bugfixes and new features are not in CVS today, because of the impediment of an awkward test suite? We cannot know the exact number, but it is surely many times greater than the number of bugfixes or new features the developers might forgo in order to develop a new test system (or integrate an off-the-shelf system). That task would only take a finite amount of time, while the penalty of using the current test suite will continue forever if nothing is done.

The point is not that having strict requirements to write tests is bad, nor that writing your test system as a Bourne shell script is necessarily bad. It might work fine, depending on how you design it and what it needs to test. The point is simply that when the test system becomes a significant impediment to development, something must be done. The same is true for any routine process that turns into a barrier or a bottleneck.

Les tests automatisés

L'exécution de tests automatisés est utile pour tout projet développant un logiciel, particulièrement pour les projets Open Source, car les tests automatisés (en particulier les tests de non-régression) donnent aux développeurs une plus grande liberté de modification du code dans des domaines qui ne leurs sont pas familiers et donc encouragent l'esprit d'exploration. Parce que la détection à la main des ruptures est si complexe, grossièrement il faut deviner où pourrait se situer la brèche puis faire divers tests pour déterminer si on a vu juste ou non, des moyens automatisés de détection de ces ruptures font gagner beaucoup de temps au projet. Les gens se sentent également plus en confiance pour modifier des pans entiers du code et contribuent donc au suivi du projet sur le long terme.

Les tests de non-régression :

« Test de non-régression » fait référence aux tests menés pour détecter la réapparition de bogues déjà réparés. Le but des tests de non-régression est de réduire les chances que les modifications du code endommagent le logiciel de manière inattendue. La probabilité de voir des effets secondaires se développer augmente régulièrement à mesure que le logiciel croît et devient plus complexe. Le problème peut être réduit, mais pas totalement éliminé, grâce à une bonne conception.

Par conséquent, de nombreux projets disposent d'une gamme de tests, un programme séparé qui demande, à dessein, au logiciel des actions qui sont connues pour provoquer des bogues particuliers. Si la suite de tests parvient à déclencher un bogue on parle de régression, c'est à dire que quelqu'un a court-circuité la solution à un bogue sans le vouloir.

Voir aussi http://fr.wikipedia.org/wiki/Non-r%C3%A9gression

Les tests de non-régression ne sont pas la panacée. D'une part, ils fonctionnent bien pour les programmes en lignes de commandes. Les logiciels qui emploient une interface utilisateur graphique sont bien plus complexes à tester automatiquement. D'autre part la structure de la suite de tests peut être elle même plutôt compliquée et possède sa propre courbe d'apprentissage et sa propre charge de maintenance. En réduire la complexité est l'une des choses les plus utiles que vous puissiez faire, même si ça peut prendre un temps considérable. Plus il est facile d'ajouter de nouveaux tests à la gamme, plus les développeurs le feront et moins il y aura de bogues qui survivront jusqu'à la version finale. Tous les efforts consentis pour rendre les tests plus simples à écrire ne représentent pas grand chose par rapport au bénéfice que vous en tirerez sur la durée de vie du projet.

Beaucoup de projets ont une règle du type « Ne détruisez pas l'architecture ! » qui signifie : ne faites pas de changement qui pourrait empêcher de compiler ou de lancer le programme. Celui qui est responsable de la destruction de l'architecture est généralement sujet à un léger embarra et aux taquineries de ses pairs. Dans les projets ayant une gamme de tests de non-régression il y a souvent un corollaire à cette première règle : ne changez rien qui pourraient faire échouer les tests. De telles erreurs sont plus facilement détectables si toute une batterie de tests de non-régression vérifient l'intégrité du programme automatiquement le soir et envoie les résultats à toute la liste des développeurs ou à une liste de diffusion dédiée : voilà un autre exemple d'automatisation qui vous sera grandement bénéfique.

La plupart des développeurs volontaires sont d'accord pour prendre un peu plus de temps pour écrire les tests de non-régression quand le système est suffisamment clair et facile à utiliser. Les gens comprennent qu'il faut que les changements soient accompagnés de tests, d'autant plus que c'est également une bonne occasion de développer la collaboration : souvent deux développeurs se partageront le travail de réparation d'un bogue, l'un écrivant le correctif et l'autre écrivant le test. Comme ce dernier aura finalement plus de travail et comme en plus l'écriture d'un test est moins vectrice de satisfaction que la réparation du bogue lui même il faut impérativement que la suite de test ne rende pas les choses plus désagréables qu'elles ne le sont déjà.

Certains projets poussent encore plus loin et exigent que chaque correctif ou nouvelle fonction soit accompagné d'un nouveau test. Quannt à dire si c'est une bonne idée ou pas il faut prendre en compte plusieurs éléments : la nature du logiciel, la composition de l'équipe de développement ainsi que la difficulté d'écriture de nouveaux tests. Le projet CVS (http://www.cvshome.org) a pendant longtemps appliqué cette règle. En théorie c'est une bonne règle puisque CVS est un logiciel de gestion de version et qu'il est par conséquent exclu de prendre des risques avec les données des utilisateurs. Le problème dans la pratique est que le test de non-régression de CVS est un énorme script shell fait d'un bloc (ironiquement nommé sanity.sh [NdT : santé mentale]), difficile à lire et à modifier ou compléter. La difficulté d'ajouter des nouveaux tests ainsi que le besoin de lier aux correctifs de nouveaux tests font que CVS n'encourage pas du tout l'écriture de correctifs. Quand je travaillais sur le projet CVS j'ai vu des gens commencer ou même terminer un correctif pour le code du logiciel mais abandonner lorsqu'ils étaient informés qu'ils devaient aussi écrire un nouveau test à ajouter dans sanity.sh.

Il est courant de passer plus de temps à écrire un nouveau test de non-régression qu'à corriger le bogue. Mais CVS avait porté ce phénomène à son paroxysme : les gens pouvaient passer des heures à parfaire leurs tests sans qu'ils ne marchent pour autant car il y a simplement trop de complications imprévisibles lorsqu'on veut changer un script Bourne shell de 35 000 lignes. Même les développeurs anciens traînaient les pieds lorsqu'ils devaient ajouter un nouveau test.

Nous en sommes arrivé à cette situation parce que nous n'avons pas été capable d'envisager le gain que nous aurions pu tirer de l'automatisation. Il est vrai que se tourner vers un véritable cadre de tests, qu'il soit fait par nous même ou qu'on en choisisse un prêt à l'emploi, aurait demandé un effort conséquent.[20] Mais l'avoir négligé a coûté bien plus au projet au fil des ans. Combien de correctifs et de nouvelles fonctionnalités n'ont pas été incorporés au jour d'aujourd'hui dans CVS à cause de l'obstacle que représente une suite de tests mal conçue? On ne peut pas connaître le chiffre exact, mais il est sûrement bien plus élevé que le nombre de correctifs ou de nouvelles fonctionnalités auxquels renonceraient les développeurs pour créer un nouveau système de test (ou en intégrer un prêt à l'emploi). Cette opération ne prendrait qu'un temps limité alors que le handicape lié à l'utilisation de la suite de tests actuelle perdurera si rien n'est fait.

Tout cela ne signifie pas qu'avoir une politique stricte vis à vis de l'écriture des tests est mauvais, ni que l'écriture de votre système de test sous forme d'un script Bourne shell est forcément mauvaise. Cela peut très bien fonctionner selon sa conception et les tests qu'il doit effectuer. Le message est simplement que lorsque le système de test devient un obstacle sérieux au développement vous devez agir. Cela vaut pour tous les procédés routiniers qui se muent en barrière ou en goulot d'étranglement.

Treat Every User as a Potential Volunteer

Each interaction with a user is an opportunity to get a new volunteer. When a user takes the time to post to one of the project's mailing lists, or to file a bug report, he has already tagged himself as having more potential for involvement than most users (from whom the project will never hear at all). Follow up on that potential: if he described a bug, thank him for the report and ask him if he wants to try fixing it. If he wrote to say that an important question was missing from the FAQ, or that the program's documentation was deficient in some way, then freely acknowledge the problem (assuming it really exists) and ask if he's interested in writing the missing material himself. Naturally, much of the time the user will demur. But it doesn't cost much to ask, and every time you do, it reminds the other listeners in that forum that getting involved in the project is something anyone can do.

Don't limit your goals to acquiring new developers and documentation writers. For example, even training people to write good bug reports pays off in the long run, if you don't spend too much time per person, and if they go on to submit more bug reports in the future—which they are more likely to do if they got a constructive reaction to their first report. A constructive reaction need not be a fix for the bug, although that's always the ideal; it can also be a solicitation for more information, or even just a confirmation that the behavior is a bug. People want to be listened to. Secondarily, they want their bugs fixed. You may not always be able to give them the latter in a timely fashion, but you (or rather, the project as a whole) can give them the former.

A corollary of this is that developers should not express anger at people who file well-intended but vague bug reports. This is one of my personal pet peeves; I see developers do it all the time on various Open Source mailing lists, and the harm it does is palpable. Some hapless newbie will post a useless report:

   Hi, I can't get Scanley to run. Every time I start it up, it just errors. Is anyone else seeing this problem?

Some developer—who has seen this kind of report a thousand times, and hasn't stopped to think that the newbie has not—will respond like this:

   What are we supposed to do with so little information? Sheesh. Give us at least some details, like the version of Scanley, your operating system, and the error.

This developer has failed to see things from the user's point of view, and also failed to consider the effect such a reaction might have on all the other people watching the exchange. Naturally a user who has no programming experience, and no prior experience reporting bugs, will not know how to write a bug report. What is the right way to handle such a person? Educate them! And do it in such a way that they come back for more:

   Sorry you're having trouble. We'll need more information in order to figure out what's happening here. Please tell us the version of Scanley, your operating system, and the exact text of the error. The very best thing you can do is send a transcript showing the exact commands you ran, and the output they produced. See http://www.scanley.org/how_to_report_a_bug.html for more.

This way of responding is far more effective at extracting the needed information from the user, because it is written to the user's point of view. First, it expresses sympathy: You had a problem; we feel your pain. (This is not necessary in every bug report response; it depends on the severity of the problem and how upset the user seemed.) Second, instead of belittling her for not knowing how to report a bug, it tells her how, and in enough detail to be actually useful—for example, many users don't realize that « show us the error » means « show us the exact text of the error, with no omissions or abridgements. » The first time you work with such a user, you need to be specific about that. Finally, it offers a pointer to much more detailed and complete instructions for reporting bugs. If you have successfully engaged with the user, she will often take the time to read that document and do what it says. This means, of course, that you have to have the document prepared in advance. It should give clear instructions about what kind of information your development team wants to see in every bug report. Ideally, it should also evolve over time in response to the particular sorts of omissions and misreports users tend to make for your project.

The Subversion project's bug reporting instructions are a fairly standard example of the form (see Appendix D, Example Instructions for Reporting Bugs). Notice how they close with an invitation to provide a patch to fix the bug. This is not because such an invitation will lead to a greater patch/report ratio—most users who are capable of fixing bugs already know that a patch would be welcome, and don't need to be told. The invitation's real purpose is to emphasize to all readers, especially those new to the project or new to free software in general, that the project runs on volunteer contributions. In a sense, the project's current developers are no more responsible for fixing the bug than is the person who reported it. This is an important point that many new users will not be familiar with. Once they realize it, they're more likely to help make the fix happen, if not by contributing code then by providing a more thorough reproduction recipe, or by offering to test fixes that other people post. The goal is to make every user realize that there is no innate difference between herself and the people who work on the project—that it's a question of how much time and effort one puts in, not a question of who one is.

The admonition against responding angrily does not apply to rude users. Occasionally people post bug reports or complaints that, regardless of their informational content, show a sneering contempt at the project for some failing. Often such people are alternately insulting and flattering, such as the person who posted this to a Subversion mailing list:

   Why is it that after almost 6 days there still aren't any binaries posted for the windows platform?!? It's the same story every time and it's pretty frustrating. Why aren't these things automated so that they could be available immediately?? When you post an « RC » build, I think the idea is that you want users to test the build, but yet you don't provide any way of doing so. Why even have a soak period if you provide no means of testing??

Initial response to this rather inflammatory post was surprisingly restrained: people pointed out that the project had a published policy of not providing official binaries, and said, with varying degrees of annoyance, that he ought to volunteer to produce them himself if they were so important to him. Believe it or not, his next post started with these lines:

   First of all, let me say that I think Subversion is awesome and I really appreciate the efforts of everyone involved. [...]

...and then he went on to berate the project again for not providing binaries, while still not volunteering to do anything about it. After that, about 50 people just jumped all over him, and I can't say I really minded. The « zero-tolerance » policy toward rudeness advocated in the section called “Nip Rudeness in the Bud” in Chapter 2, Getting Started applies to people with whom the project has (or would like to have) a sustained interaction. But when someone makes it clear from the start that he is going to be a fountain of bile, there is no point making him feel welcome.

Such situations are fortunately quite rare, and they are noticeably rarer in projects that make an effort to engage users constructively and courteously from their very first interaction.

Considérez tous les utilisateurs comme des volontaires potentiels

Chaque contact avec un utilisateur est une chance de convaincre un nouveau volontaire. Lorsqu'un utilisateur prend le temps d'écrire sur des listes de diffusion du projet ou de remplir un rapport de bogue il se distingue et montre un plus fort potentiel d'investissement que la plupart des utilisateurs (dont le projet n'entendra jamais parler). Vous devez répondre à ce premier signe : s'il a décrit un bogue, remerciez le pour son rapport et demandez lui s'il voudrait le corriger lui même. S'il a écrit pour dire qu'une question importante manque à la FAQ ou signaler une carence dans la documentation du programme, reconnaissez le problème (en supposant qu'il existe effectivement) et demandez lui s'il serait intéressé par l'écriture des passages manquants. Évidemment, la plupart du temps les utilisateurs déclineront. Mais ça ne coûte rien de demander et chaque fois que vous le faites vous rappelez à tous les lecteurs de ce forum que prendre part au projet est quelque chose que tout le monde peut faire.

Ne restreignez pas vos objectifs au recrutement de nouveaux développeurs ou de nouveaux auteurs de la documentation. Par exemple, entraîner simplement les gens à écrire de bons rapports de bogues porte ses fruits sur le long terme si vous ne passez pas trop de temps sur chaque cas et s'ils continuent à envoyer des rapports de bogue dans le futur, ce qui est plus probable si leur premier rapport a reçu des critiques constructives. Une réaction constructive n'est pas forcément un correctif du bogue, même si ça serait toujours idéal, ils veulent qu'on les écoute, ensuite seulement ils veulent que le bogue soit corrigé. Vous n'aurez pas nécessairement la capacité de répondre à ce deuxième désir dans un bref délai, mais vous (ou plutôt, le projet entier) peut satisfaire le premier.

Il en découle que les développeurs ne devraient pas montrer leur irritation aux gens qui remplissent des rapports de bogue avec de bonnes intentions mais qui manquent de précision. C'est ma bête noire personnelle, je remarque que des développeurs le font tout le temps sur les listes de diffusion ouvertes et les dommages causés sont palpables. Quelques débutants malheureux posteront des rapports inutiles :

  Salut, je n'arrive pas à faire marcher Scanley. A chaque fois que je le lance il plante. Est-ce que quelqu'un d'autre rencontre ce problème?

Un développeur, qui a déjà vu ce genre de rapport des milliers de fois , mais qui ne pense pas que ce n'est pas le cas du débutant, répondra quelque chose comme ceci :

  Qu'est ce que qu'on est sensé faire avec si peu d'informations ? Mince ! Donne nous au moins quelques détails, ta version de Scanley, ton système d'exploitation et l'erreur.

Ce développeur n'est pas parvenu à voir les choses du point de vue de l'utilisateur et n'a pas pris en considération les effets qu'une telle réaction peut avoir sur les autres personnes spectatrices de l'échange. Naturellement, un utilisateur qui n'a aucune expérience de la programmation et qui n'a jamais rapporté de bogue ne saura pas comment écrire un rapport de bogue. Quelle est la bonne manière de traiter ce type de personne ? Éduquez les ! Donnez leur envie de revenir :

  Désolé que tu rencontres des problèmes. Nous aurons besoin de plus d'informations pour comprendre ce qui t'arrive. S'il te plaît, indique nous ta version de Scanley, ton système d'exploitation et le message d'erreur exact. Le mieux que tu puisses faire est de nous envoyer une copie de ce que tu as exactement tapé et le résultat obtenu. Réfère toi à http://www.scanley.org/how_to_report_a_bug.html pour plus de précisions.

Cette manière de répondre est bien plus efficace pour obtenir les informations nécessaires de l'utilisateur, parce que c'est écrit de son point de vue. Premièrement, vous montrez de la sympathie : Tu as eu un problème, nous comprenons ta douleur (Ce n'est pas nécessaire dans tous les cas, ça dépend de la gravité du problème et de l'agacement que l'utilisateur montre). Deuxièmement, plutôt que de rabaisser la personne parce qu'elle ne sait pas comment rapporter un bogue cette réponse lui indique comment faire et fournit les détails nécessaires pour que cela soit vraiment utile, de nombreux utilisateurs par exemple ne réalisent pas que « montre nous l'erreur » veut dire « montre nous le message d'erreur exact, sans commettre d'omissions ou faire de raccourcis ». La première fois que vous serez en contact avec un tel utilisateur vous devez être clair à ce sujet. Finalement cette réponse fournit un lien possible vers des instructions plus précises et détaillées à propos des rapports de bogue. Si vous avez fait ce qu'il faut, l'utilisateur prendra souvent le temps de lire ce document et se conformera aux directives qui s'y trouvent. Vous devez donc évidemment le mettre à disposition. Il devrait donner des instructions claires à propos du type d'informations dont votre équipe de développement a besoin pour étudier tous les rapports de bogue. Idéalement, il devrait évoluer avec le temps en réponse aux omissions et manquements spécifiques que les utilisateurs seront susceptibles de faire.

Les instructions concernant les rapports de bogue du projet Subversion représentent un exemple assez standard dans ce domaine (voir Annexe D, Exemples et instructions pour les rapports de bogues). Remarquez la manière de conclure avec une invitation à produire un correctif pour réparer le bogue. Ce n'est pas parce qu'une telle invitation vous apportera un meilleur rapport correctif/bogue, la plupart des utilisateurs capables de réparer les bogues savent déjà qu'un correctif serait le bienvenu, on n'a pas besoin de le leur dire. L'invitation a pour but de rappeler à tous les lecteurs, en particuliers aux nouveaux venus dans le projet ou dans le monde des logiciels libres en général, que le projet dépend des contributions de volontaires. Dans un sens, les développeurs ne sont pas plus responsables de la réparation des bogues que la personne l'ayant signalé. C'est un aspect important avec lequel de nombreux volontaires ne sont pas familiers. Une fois qu'ils le réalisent il y a de meilleures chances qu'ils aident à la réalisation du correctif, à moins qu'ils ne participent au développement du code en fournissant une méthode de reproduction plus complète ou en proposant de tester les correctifs que les autres personnes proposent. Le but est que tous les utilisateurs comprennent qu'il n'y a pas de barrière imperméable entre eux et les gens travaillant sur le projet, que tout est question d'effort qu'on est prêt à consentir, pas de qui on est.

Les remontrances contre les réponses agressives ne s'appliquent pas dans le cas d'utilisateurs grossiers. De temps à autres des gens enverront des rapports de bogue ou des plaintes qui, contenu informatif mis à part, font preuve de mépris envers un manquement du projet. Souvent ces gens alternent entre insultes et flatteries, comme dans ce message écrit pas un utilisateur sur une liste de diffusion de Subversion :

  Comment ça se fait qu'après 6 jours il n'y ait toujours pas d'exécutable pour les plateformes Windows ?!? C'est toujours la même histoire et c'est plutôt frustrant. Pourquoi est ce que ces choses ne sont pas automatisées pour qu'il soit disponible immédiatement ?? Quand vous sortez une version « RC », je pense que le but est que les utilisateurs testent la version, mais vous ne fournissez aucun moyen de le faire. Pourquoi prendre la peine d'avoir une période de mise à l'épreuve si vous ne fournissez aucun moyen de tester ??

Les premières réponses à ce message plutôt provocateur ont été étonnamment modérées : les gens ont mis en avant le fait que le projet avait pour règle de ne pas fournir d'exécutables officiels et ont dit, avec différents degrés d'irritation, qu'il devrait plutôt se porter volontaire pour les faire lui même s'ils sont si important à ses yeux. Que vous le croyez ou non sa réponse commençait par ces lignes :

  Tout d'abord laissez moi vous dire que je pense que Subversion est génial et je suis reconnaissant des efforts fournis par les gens impliqués. [...]

...et puis son message continue par des admonestations contre le fait que le projet ne fournissait toujours pas d'exécutable, sans pour autant se porter volontaire pour y remédier. Après cela, environ 50 personnes lui sont tombées dessus et je ne peux pas dire que ça m'ait vraiment dérangé. La politique de tolérance zéro évoquée dans la section « Tuez la vulgarité dans l'œuf » dans le Chapitre 2, Bien démarrer s'applique pour les gens avec qui le projet a (ou voudrait avoir) une relation durable. Mais quand quelqu'un montre clairement dès le départ qu'il ne sera qu'un puits d'amertume il n'y a pas de raison qu'il se sente bien accueilli.

[19] This question was studied in detail, with interesting results, in a paper by Karim Lakhani and Robert G. Wolf, entitled Why Hackers Do What They Do: Understanding Motivation and Effort in Free/Open Source Software Projects. See http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.

[20] Note that there would be no need to convert all the existing tests to the new framework; the two could happily exist side by side, with old tests converted over only as they needed to be changed.

[19] Cette question a été étudiée en détail, avec des résultats intéressants, dans un papier de Karim Lakhani et Robert G. Wolf, intitulé « Pourquoi les hackers font ce qu'ils font : Comprendre les motivations et les efforts des projets de logiciels libres/Open Source ». Voir http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.

[20] Remarquez que vous n'avez pas besoin de convertir tous les tests existants au nouveau format ; les deux peuvent très bien coexister, les anciens tests étant convertis seulement lorsqu'ils ont besoin d'être modifiés.

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.

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.

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.

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.

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.

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.

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.

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é.

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.

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.

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.

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.

[21] IssueZilla is the issue tracker we use; it is a descendant of BugZilla.

[21] Issuezilla est le système de repérage de problème que nous utilisons, c'est un descendant de BugZilla.

Transitions

From time to time, a volunteer in a position of ongoing responsibility (e.g., patch manager, translation manager, etc.) will become unable to perform the duties of the position. It may be because the job turned out to be more work than he anticipated, or it may be due to completely external factors: marriage, a new baby, a new employer, or whatever.

When a volunteer gets swamped like this, he usually doesn't notice it right away. It happens by slow degrees, and there's no point at which he consciously realizes that he can no longer fulfill the duties of the role. Instead, the rest of the project just doesn't hear much from him for a while. Then there will suddenly be a flurry of activity, as he feels guilty for neglecting the project for so long and sets aside a night to catch up. Then you won't hear from him for a while longer, and then there might or might not be another flurry. But there's rarely an unsolicited formal resignation. The volunteer was doing the job in his spare time, so resigning would mean openly acknowledging to himself that his spare time is permanently reduced. People are often reluctant to do that.

Therefore, it's up to you and the others in the project to notice what's happening—or rather, not happening—and to ask the volunteer what's going on. The inquiry should be friendly and 100% guilt-free. Your purpose is to find out a piece of information, not to make the person feel bad. Generally, the inquiry should be visible to the rest of the project, but if you know of some special reason why a private inquiry would be better, that's fine too. The main reason to do it publicly is so that if the volunteer responds by saying that he won't be able to do the job anymore, there's a context established for your next public post: a request for a new volunteer to fill that role.

Sometimes, a volunteer is unable to do the job he's taken on, but is either unaware or unwilling to admit that fact. Of course, anyone may have trouble at first, especially if the responsibility is complex. However, if someone just isn't working out in the task they've taken on, even after everyone else has given all the help and suggestions they can, then the only solution is for her to step aside and let someone new have a try. And if the person doesn't see this herself, she'll need to be told. There's basically only one way to handle this, I think, but it's a multistep process and each step is important.

First, make sure you're not crazy. Privately talk to others in the project to see if they agree that the problem is as serious as you think it is. Even if you're already positive, this serves the purpose of letting others know that you're considering asking the person to step aside. Usually no one will object to that—they'll just be happy you're taking on the awkward task, so they don't have to!

Next, privately contact the volunteer in question and tell him, kindly but directly, about the problems you see. Be specific, giving as many examples as possible. Make sure to point out how people had tried to help, but that the problems persisted without improving. You should expect this email to take a long time to write, but with this sort of message, if you don't back up what you're saying, you shouldn't say it at all. Say that you would like to find a new volunteer to fill the role, but also point out that there are many other ways to contribute to the project. At this stage, don't say that you've talked to others about it; nobody likes to be told that people were conspiring behind her back.

There are a few different ways things can go after that. The most likely reaction is that he'll agree with you, or at any rate not want to argue, and be willing to step down. In that case, suggest that he make the announcement himself, and then you can follow up with a post seeking a replacement.

Or, he may agree that there have been problems, but ask for a little more time (or for one more chance, in the case of discrete-task roles like release manager). How you react to that is a judgement call, but whatever you do, don't agree to it just because you feel like you can't refuse such a reasonable request. That would prolong the agony, not lessen it. There is often a very good reason to refuse the request, namely, that there have already been plenty of chances, and that's how things got to where they are now. Here's how I put it in a mail to someone who was filling the release manager role but was not really suited for it:

   > If you wish to replace me with some one else, I will gracefully
   > pass on the role to who comes next.  I have one request, which
   > I hope is not unreasonable.  I would like to attempt one more
   >  release in an effort to prove myself.

   I totally understand the desire (been there myself!), but in
   this case, we shouldn't do the "one more try" thing.

   This isn't the first or second release, it's the sixth or
   seventh... And for all of those, I know you've been dissatisfied
   with the results too (because we've talked about it before).  So
   we've effectively already been down the one-more-try route.
   Eventually, one of the tries has to be the last one... I think
   [this past release] should be it.

In the worst case, the volunteer may disagree outright. Then you have to accept that things are going to be awkward and plow ahead anyway. Now is the time to say that you talked to other people about it (but still don't say who until you have their permission, since those conversations were confidential), and that you don't think it's good for the project to continue as things are. Be insistent, but never threatening. Keep in mind that with most roles, the transition really happens the moment someone new starts doing the job, not the moment the old person stops doing it. For example, if the contention is over the role of, say, issue manager, at any point you and other influential people in the project can solicit for a new issue manager. It's not actually necessary that the person who was previously doing it stop doing it, as long as he does not sabotage (deliberately or otherwise) the efforts of the new volunteer.

Which leads to a tempting thought: instead of asking the person to resign, why not just frame it as a matter of getting him some help? Why not just have two issue managers, or patch managers, or whatever the role is?

Although that may sound nice in theory, it is generally not a good idea. What makes the manager roles work—what makes them useful, in fact—is their centralization. Those things that can be done in a decentralized fashion are usually already being done that way. Having two people fill one managerial role introduces communications overhead between those two people, as well as the potential for slippery displacement of responsibility ("I thought you brought the first aid kit!" "Me? No, I thought you brought the first aid kit!"). Of course, there are exceptions. Sometimes two people work extremely well together, or the nature of the role is such that it can easily be spread across multiple people. But these are not likely to be of much use when you see someone flailing in a role he is not suited for. If he'd appreciated the problem in the first place, he would have sought such help before now. In any case, it would be disrespectful to let someone waste time continuing to do a job no one will pay attention to.

The most important factor in asking someone to step down is privacy: giving him the space to make a decision without feeling like others are watching and waiting. I once made the mistake—an obvious mistake, in retrospect—of mailing all three parties at once in order to ask Subversion's release manager to step aside in favor of two other volunteers. I'd already talked to the two new people privately, and knew that they were willing to take on the responsibility. So I thought, naïvely and somewhat insensitively, that I'd save some time and hassle by sending one mail to all of them to initiate the transition. I assumed that the current release manager was already fully aware of the problems and would see the reasonableness of my point immediately.

I was wrong. The current release manager was very offended, and rightly so. It's one thing to be asked to hand off the job; it's another thing to be asked that in front of the people you'll hand it off to. Once I got it through my head why he was offended, I apologized. He eventually did step aside gracefully, and continues to be involved with the project today. But his feelings were hurt, and needless to say, this was not the most auspicious of beginnings for the new volunteers either.

Transitions

De temps à autres, un volontaire occupant une place importante (par exemple responsable correctifs, responsable traductions, etc.) n'aura plus la possibilité de remplir ses fonctions. La raison peut être qu'il ne s'attendait pas à une telle charge de travail ou elle peut être due à des facteurs totalement extérieurs au projet : un mariage, un nouveau bébé, un nouvel employeur ou quoi que ce soit d'autre.

Quand un volontaire se retrouve submergé ainsi il ne le remarque pas forcément de suite. Ça se passe en douceur et il n'y a pas de moment précis où il réalise qu'il n'est plus capable d'assumer ses responsabilités. Le reste du projet n'a plus beaucoup de ses nouvelles pendant un certain temps, puis soudain vous verrez un accroissement d'activité quand il réalise qu'il a négligé le projet pendant trop longtemps et qu'il prend une nuit pour rattraper son retard. Puis vous n'entendrez plus parler de lui à nouveau pendant un certain temps et vous verrez peut-être à nouveau un regain d'activité. Les démissions ne seront que rarement spontanées. Le volontaire faisait le travail pendant son temps libre, sa démission signifierait qu'il reconnaît ouvertement que son temps libre a été définitivement réduit. Les gens ont souvent du mal à le reconnaître.

Par conséquent, c'est votre rôle, ou celui des autres membres du projet, de remarquer quand quelque chose se passe, ou plutôt ne se passe pas, et de demander au volontaire si tout va bien. La demande devrait être formulée amicalement et ne devrait pas être accusatrice. Vous cherchez une information, pas à rendre l'autre personne mal à l'aise. De manière générale, la demande devrait être faite ouvertement devant le reste du projet, mais si vous êtes au courant de circonstances particulières, le faire en privée est très bien aussi. La motivation principale d'une demande publique est que si le volontaire répond qu'il ne sera plus capable d'accomplir le travail un contexte sera déjà établi pour votre prochaine annonce publique : la recherche d'un nouveau volontaire pour prendre ce rôle.

Parfois, un volontaire n'est plus à même de faire le travail qui lui est attribué, mais il ne l'a pas forcément remarqué ou il peut refuser de l'admettre. Bien sûr, chacun peut connaître des difficultés au départ, surtout si la tâche est complexe. Cependant, si quelqu'un ne correspond pas au poste qui lui a été confié, même après que tous les autres lui aient donné toute l'aide ou toutes les suggestions qu'ils pouvaient, l'unique solution pour lui est de s'effacer et de donner sa chance à quelqu'un d'autre. Si cette personne ne s'en rend pas compte par elle-même, quelqu'un devra lui dire. Il n'y a en pratique qu'une manière de le faire, je pense, mais c'est un processus en plusieurs étapes et chacune est importante.

En premier, assurez vous que vous n'êtes pas fou. Sondez en privé l'avis des autres membres du projet pour savoir s'ils partagent le même sentiment que vous par rapport au problème. Même si vous êtes déjà sûr de vous, cela permettra de laisser savoir aux autres que vous envisagez de demander à cette personne d'abandonner son rôle. En général personne ne fera d'objection, ils seront soulagés que vous vous chargiez de cette tâche embarrassante et qu'ils n'aient pas à le faire.

Ensuite, contactez le volontaire en question, en privé, et informez le, gentiment mais de manière directe, du problème. Soyez précis et donnez autant d'exemples que possible. Assurez vous de bien mettre en avant l'aide proposée par les autres mais que les problèmes ont persisté sans amélioration. Préparez vous à ce que l'élaboration de ce courrier soit longue mais, pour ce genre de message, si vous n'étayez pas vos dires il vaut encore mieux ne rien faire. Annoncez lui que vous voudriez chercher un autre volontaire pour ce rôle, mais indiquez également qu'il existe bien d'autres manières d'apporter sa contribution au projet. Pour le moment ne dites pas encore que vous en avez parlé à d'autres, personne n'apprécie qu'on lui dise qu'on a conspiré dans son dos.

Les choses peuvent prendre différentes tournures ensuite. Le plus probable est que la personne sera d'accord avec vous, ou qu'au moins elle ne vous contredira pas, et laissera volontairement sa place. Dans ce cas, proposez lui de faire l'annonce lui même et de vous occuper du message de recherche d'un remplaçant.

Ou alors il peut être d'accord sur le fait qu'il y a eu des problèmes mais demandera un sursis (ou une nouvelle chance dans le cas d'une tâche ponctuelle comme responsable parutions). Vous devez suivre votre jugement, mais peu importe ce que vous faites, ne donnez pas votre accord simplement parce que vous pensez que la demande est raisonnable. Ça ne ferait que prolonger l'agonie, pas la réduire. Il y a souvent une très bonnes raisons de refuser d'accéder à une requête : la personne a déjà bénéficié de beaucoup d'opportunités et c'est ainsi que les choses en sont arrivées à ce point. Voilà comment je tourne les choses dans un mail à une personne qui avait le rôle de responsable parutions mais qui ne faisait pas vraiment à ce qu'on attendait de lui :

  > Si tu veux me faire remplacer par quelqu'un d'autre, je passerai
  > gracieusement le témoin. J'aurai juste une demande, qui je l'espère
  > n'est pas déraisonnable. J'aimerai qu'on m'accorde une sortie de plus
  > pour pouvoir prouver ma valeur.

  Je comprends totalement ton désir (je suis passé par là moi aussi !),
  mais dans le cas présent on ne devrait pas procéder ainsi.
  Ce n'est pas la première ou deuxième parution, c'est la six ou 
  septième... Et je sais que pour chacune tu n'as jamais été 
  complètement satisfait toi même par les résultats (parce qu'on en a
  déjà parlé avant). Tu as donc déjà eu ta seconde chance.
  Finalement, l'un des essais doit être le dernier... Je pense que
  [cette dernière parution] devrait l'être.

Dans le pire des cas le volontaire peut montrer ouvertement son désaccord. Vous devrez alors vous faire au fait que ça va être délicat et il faudra bien vous faire entendre coûte que coûte. Le moment sera venu de dire que vous en avez déjà parlé avec d'autres (mais ne dévoilez pas leur identité si vous n'avez pas leur permission puisque ces discussions sont sensées rester confidentielles) et que pour le bien du projet vous ne pensez pas qu'il faille continuer ainsi. Insistez mais ne devenez pas menaçant. Gardez en tête que pour la plupart des postes la transition devient effective au moment où une nouvelle personne commence le travail, pas au moment où son prédécesseur arrête de le faire. Par exemple, si la controverse touche le rôle de responsable difficultés par exemple, vous ou n'importe quelle autre personne influente dans le projet peut solliciter un nouveau responsable difficultés à n'importe quel moment. La personne qui le faisait avant n'a pas vraiment besoin d'arrêter de faire son travail, tant qu'elle ne sabote pas (délibérément ou de tout autre manière) les efforts du nouveau volontaire.

Ce qui mène à cette alternative tentante : plutôt que de demander à la personne de démissionner, pourquoi ne pas l'encadrer sous prétexte de lui apporter un peu d'aide ? Pourquoi ne pas utiliser deux responsables difficultés, correctifs ou autre ?

Bien qu'en théorie l'idée semble bonne, en général elle ne l'est pas. Ce qui fait que le rôle de manager fonctionne, ce qui le rend utile en fait, est la centralisation. Ce qui peut être accomplit de manière décentralisée est en général déjà fait de cette manière. Que deux personnes doivent remplir une tâche de managérat implique un délai supplémentaire dû à leur besoin de communication aussi bien que de potentiels glissements de responsabilité accidentels (« Je pensais que tu avais pris le kit de premiers soins ! » « Moi ? Non, je pensais que tu l'avais pris ! »). Bien sûr il y a des exceptions. Parfois deux personnes travaillent extrêmement bien ensemble ou alors la nature même du rôle peut faire qu'il peut être partagé facilement entre plusieurs personnes. Mais ça ne fera pas une grande différence pour une personne qui se démène dans un rôle pour lequel il n'est pas fait. Si dès le début il se sentait à l'aise avec ce problème il aurait demandé ce type d'aide bien avant. Dans tous les cas ça serait un manque de respect de laisser quelqu'un continuer un travail auquel personne ne prêtera attention.

La plus important lorsque vous demandez à quelqu'un de démissionner est d'observer la discrétion de rigueur : donnez lui la possibilité de prendre sa décision sans qu'il ressente que d'autres le surveillent et attendent sa réponse. J'ai fait cette erreur une fois, une erreur évidente quand j'y repense, d'envoyer un courrier aux trois parties pour demander au responsable parutions de Subversion de démissionner au profit de deux autres volontaires. J'en avais déjà parlé en privé avec les deux nouvelles personnes et je savais qu'ils étaient désireux de prendre cette responsabilité. Alors j'ai pensé, naïvement et avec peu de tact, que je gagnerai du temps et m'éviterai des tracas en leur envoyant à tous un courrier pour commencer la transition. Je supposais que le responsable parutions était déjà au courant des problèmes et comprendrait ma démarche sans problème.

J'ai eu tort. Le responsable parutions de l'époque s'est senti insulté, à raison. C'est une chose de se voir demander de passer la main, s'en est une autre quand c'est fait devant les personnes à qui la main passera. Dès que j'ai compris ce qui l'avait insulté je me suis excusé. Finalement il a démissionné et continue à être impliqué dans le projet aujourd'hui encore. Mais il a été blessé dans son amour propre, sans mentionner que ce n'était pas pour les nouveaux volontaires une situation idéale pour débuter dans leur nouveau rôle.

Committers

As the only formally distinct class of people found in all Open Source projects, committers deserve special attention here. Committers are an unavoidable concession to discrimination in a system which is otherwise as non-discriminatory as possible. But « discrimination » is not meant as a pejorative here. The function committers perform is utterly necessary, and I do not think a project could succeed without it. Quality control requires, well, control. There are always many people who feel competent to make changes to a program, and some smaller number who actually are. The project cannot rely on people's own judgement; it must impose standards and grant commit access only to those who meet them[22]. On the other hand, having people who can commit changes directly working side-by-side with people who cannot sets up an obvious power dynamic. That dynamic must be managed so that it does not harm the project.

In the section called “Who Votes?” in Chapter 4, Social and Political Infrastructure, we already discussed the mechanics of considering new committers. Here we will look at the standards by which potential new committers should be judged, and how this process should be presented to the larger community. Choosing Committers

In the Subversion project, we choose committers primarily on the Hippocratic Principle: first, do no harm. Our main criterion is not technical skill or even knowledge of the code, but merely that the committer show good judgement. Judgement can mean simply knowing what not to take on. A person might post only small patches, fixing fairly simple problems in the code; but if the patches apply cleanly, do not contain bugs, and are mostly in accord with the project's log message and coding conventions, and there are enough patches to show a clear pattern, then an existing committer will usually propose that person for commit access. If at least three people say yes, and no one objects, then the offer is made. True, we might have no evidence that the person is able to solve complex problems in all areas of the code base, but that does not matter: the person has made it clear that he is capable of at least judging his own abilities. Technical skills can be learned (and taught), but judgement, for the most part, cannot. Therefore, it is the one thing you want to make sure a person has before you give him commit access.

When a new committer proposal does provoke a discussion, it is usually not about technical ability, but rather about the person's behavior on the mailing lists or in IRC. Sometimes someone shows technical skill and an ability to work within the project's formal guidelines, yet is also consistently belligerent or uncooperative in public forums. That's a serious concern; if the person doesn't seem to shape up over time, even in response to hints, then we won't add him as a committer no matter how skilled he is. In a volunteer group, social skills, or the ability to « play well in the sandbox", are as important as raw technical ability. Because everything is under version control, the penalty for adding a committer you shouldn't have is not so much the problems it could cause in the code (review would spot those quickly anyway), but that it might eventually force the project to revoke the person's commit access—an action that is never pleasant and can sometimes be confrontational.

Many projects insist that the potential committer demonstrate a certain level of technical expertise and persistence, by submitting some number of nontrivial patches—that is, not only do these projects want to know that the person will do no harm, they want to know that she is likely to do good across the code base. This is fine, but be careful that it doesn't start to turn committership into a matter of membership in an exclusive club. The question to keep in everyone's mind should be « What will bring the best results for the code? » not « Will we devalue the social status associated with committership by admitting this person? » The point of commit access is not to reinforce people's self-worth, it's to allow good changes to enter the code with a minimum of fuss. If you have 100 committers, 10 of whom make large changes on a regular basis, and the other 90 of whom just fix typos and small bugs a few times a year, that's still better than having only the 10. Revoking Commit Access

The first thing to be said about revoking commit access is: try not to be in that situation in the first place. Depending on whose access is being revoked, and why, the discussions around such an action can be very divisive. Even when not divisive, they will be a time-consuming distraction from productive work.

However, if you must do it, the discussion should be had privately among the same people who would be in a position to vote for granting that person whatever flavor of commit access they currently have. The person herself should not be included. This contradicts the usual injunction against secrecy, but in this case it's necessary. First, no one would be able to speak freely otherwise. Second, if the motion fails, you don't necessarily want the person to know it was ever considered, because that could open up questions ("Who was on my side? Who was against me?") that lead to the worst sort of factionalism. In certain rare circumstances, the group may want someone to know that revocation of commit access is or was being considered, as a warning, but this openness should be a decision the group makes. No one should ever, on her own initiative, reveal information from a discussion and ballot that others assumed were secret.

Once someone's access is revoked, that fact is unavoidably public (see the section called “Avoid Mystery” later in this chapter), so try to be as tactful as you can in how it is presented to the outside world. Partial Commit Access

Some projects offer gradations of commit access. For example, there might be contributors whose commit access gives them free rein in the documentation, but who do not commit to the code itself. Common areas for partial commit access include documentation, translations, binding code to other programming languages, specification files for packaging (e.g., RedHat RPM spec files, etc.), and other places where a mistake will not result in a problem for the core project.

Since commit access is not only about committing, but about being part of an electorate (see the section called “Who Votes?” in Chapter 4, Social and Political Infrastructure), the question naturally arises: what can the partial committers vote on? There is no one right answer; it depends on what sorts of partial commit domains your project has. In Subversion we've kept things fairly simple: a partial committer can vote on matters confined exclusively to that committer's domain, and not on anything else. Importantly, we do have a mechanism for casting advisory votes (essentially, the committer writes « +0 » or « +1 (non-binding) » instead of just « +1 » on the ballot). There's no reason to silence people entirely just because their vote isn't formally binding.

Full committers can vote on anything, just as they can commit anywhere, and only full committers vote on adding new committers of any kind. In practice, though, the ability to add new partial committers is usually delegated: any full committer can « sponsor » a new partial committer, and partial committers in a domain can often essentially choose new committers for that same domain (this is especially helpful in making translation work run smoothly).

Your project may need a slightly different arrangement, depending on the nature of the work, but the same general principles apply to all projects. Each committer should be able to vote on matters that fall within the scope of her commit access, and not on matters outside that, and votes on procedural questions should default to the full committers, unless there's some reason (as decided by the full committers) to widen the electorate.

Regarding enforcement of partial commit access: it's often best not to have the version control system enforce partial commit domains, even if it can. See the section called “Authorization” in Chapter 3, Technical Infrastructure for the reasons why. Dormant Committers

Some projects automatically remove people's commit access if they go a certain amount of time (say, a year) without committing anything. I think this is usually unhelpful and even counterproductive, for two reasons.

First, it may tempt some people into committing acceptable but unnecessary changes, just to prevent their commit access from expiring. Second, it doesn't really serve any purpose. If the main criterion for granting commit access is good judgement, then why assume someone's judgement would deteriorate just because he's away from the project for a while? Even if he completely vanishes for years, not looking at the code or following development discussions, when he reappears he'll know how out of touch he is, and act accordingly. You trusted his judgement before, so why not trust it always? If high school diplomas do not expire, then commit access certainly shouldn't.

Sometimes a committer may ask to be removed, or to be explicitly marked as dormant in the list of committers (see the section called “Avoid Mystery” below for more about that list). In these cases, the project should accede to the person's wishes, of course. Avoid Mystery

Although the discussions around adding any particular new committer must be confidential, the rules and procedures themselves need not be secret. In fact, it's best to publish them, so people realize that the committers are not some mysterious Star Chamber, closed off to mere mortals, but that anyone can join simply by posting good patches and knowing how to handle herself in the community. In the Subversion project, we put this information right in the developer guidelines document, since the people most likely to be interested in how commit access is granted are those thinking of contributing code to the project.

In addition to publishing the procedures, publish the actual list of committers. The traditional place for this is a file called MAINTAINERS or COMMITTERS in the top level of the project's source code tree. It should list all the full committers first, followed by the various partial commit domains and the members of each domain. Each person should be listed by name and e-mail address, though the address can be encoded to prevent spam (see the section called “Address hiding in archives” in Chapter 3, Technical Infrastructure) if the person prefers that.

Since the distinction between full commit and partial commit access is obvious and well defined, it is proper for the list to make that distinction too. Beyond that, the list should not try to indicate the informal distinctions that inevitably arise in a project, such as who is particularly influential and how. It is a public record, not an acknowledgments file. List committers either in alphabetical order, or in the order in which they arrived.

[22] Note that the commit access means something a bit different in decentralized version control systems, where anyone can set up a repository that is linked into the project, and give themselves commit access to that repository. Nevertheless, the concept of commit access still applies: « commit access » is shorthand for « the right to make changes to the code that will ship in the group's next release of the software. » In centralized version control systems, this means having direct commit access; in decentralized ones, it means having one's changes pulled into the main distribution by default. It is the same idea either way; the mechanics by which it is realized are not terribly important.

Committers

En tant que seul groupe distinct dans tous les projets Open Source, les committers méritent une attention particulière. Les committers sont la seule exception dans un système qui autrement est aussi peu discriminatoire que possible. Mais « discrimination » n'est pas pris dans un sens péjoratif ici. Le rôle des committers est absolument essentiel, je ne pense pas qu'un projet puisse réussir sans eux. Le contrôle qualité demande un ... contrôle. Il y a toujours des gens qui se sentent capables d'apporter des modifications au programme, mais peu le sont vraiment. Le projet ne peut pas se reposer sur le jugement des gens, il doit imposer des normes et accorder un accès de commit à ceux qui les respectent [22]. D'un autre côté, faire directement cohabiter des gens qui ont un accès de commit avec d'autres qui ne l'ont pas induit un rapport de force. Ce rapport de force doit être encadré afin de ne pas nuire au projet.

Dans la section « Qui vote ? » dans le Chapitre 4, Infrastructure sociale et politique , nous avons déjà parlé des rouages derrière le recrutement de nouveaux committers. Ici nous nous intéresserons aux critères d'évaluation des nouveaux committers potentiels et à la présentation de ce processus à la communauté entière.

Choisir les committers

Dans le projet Subversion notre premier critère de sélection est le Serment d'Hyppocrate : premier commandement : ne cause pas de mal. Notre critère principal n'est pas l'aptitude technique ou même la connaissance du code, mais simplement le bon jugement dont fait preuve le committer. Faire preuve de jugement peut simplement signifier savoir quoi ne pas incorporer. Une personne peut envoyer de petits correctifs, réparant des problèmes basiques du code ; mais si les correctifs s'appliquent proprement, qu'ils ne contiennent pas de bogues et sont en accord avec le journal de messages du projet et les conventions d'écriture du code et qu'ils sont assez nombreux pour attester d'une certaine constance, alors un committer déjà en place pourra suggérer de donner à cette personne un accès de commit. Si au moins trois personnes disent oui et que personne ne s'y oppose la proposition est faite. Nous ne savons pas si la personne est capable de résoudre des problèmes complexes dans tous les domaines du code, mais ce n'est pas important : la personne a montré qu'elle est au moins capable de juger de ses propres compétences. Les aptitudes techniques peuvent s'apprendre (et être enseignées), mais le jugement est en grande partie inné. C'est donc cette qualité que vous cherchez chez une personne à qui vous voulez donner l'accès de commit.

Quand quelqu'un propose de donner l'accès de commit à quelqu'un et que cette suggestion est controversée ce ne sont en général pas les aptitudes techniques de cette personne qui sont mises en cause, mais plutôt sont comportement sur les listes de diffusion et sur IRC. Parfois une personne montre des aptitudes techniques et une bonne capacité à travailler selon les règles du projet, mais en même temps il se montre systématiquement hargneux ou peu coopératif sur les forums publics. C'est un problème sérieux, si cette personne ne semble pas s'améliorer avec le temps, malgré des allusions de notre part, alors nous ne l'ajouterons pas à la liste des committers, même s'il est très doué. Dans un groupe de volontaires, les aptitudes sociales et la capacité à « bien jouer dans le bac à sable » sont aussi importantes que les aptitudes techniques brutes. Puisque tout est subordonné à la gestion de version, les dommages causés par le choix d'un mauvais committer ne résident pas tant dans les problèmes auxquels le code se retrouve exposé (l'inspection les détecteraient rapidement de toute façon) que dans le fait qu'au bout du compte le projet pourrait être forcé d'annuler l'accès de commit de cette personne, une chose qui n'est jamais plaisante et qui peut parfois être conflictuelle.

Beaucoup de projets insistent sur le fait que le committer potentiel fasse preuve d'un certain niveau d'expertise technique et d'implication en proposant un nombre non négligeable de correctifs non triviaux, ce qui veut dire que ces projets ne veulent pas seulement s'assurer que cette personne ne causera pas de dégâts, ils veulent savoir si elle est susceptible d'apporter des améliorations au code. C'est compréhensible, mais prenez garde de ne pas transformer l'accès de commit en une carte d'accès à un groupe fermé. La question que tout le monde devrait garder en tête est : « Qu'est ce qui sera le plus bénéfique pour le code ? » et non « Allons nous abaisser le statut social associé au rôle de commit en acceptant cette personne ? ». Le but d'un accès de commit n'est pas de renforcer la valeur intrinsèque d'une personne mais de permettre d'apporter de bons changements au code sans trop le perturber. Si sur 100 committers vous en avez 10 qui font de grands changements régulièrement et les 90 autres qui se contentent de corriger des erreurs de frappes et des bogues minimes quelques fois dans l'année, c'est toujours mieux que si n'aviez que 10 committers.

Révoquer un accès de commit

Le meilleur conseil concernant la révocation de l'accès de commit est : évitez de vous retrouver dans cette situation. Selon la personne concernée et le pourquoi, les discussions autour de cette décision peuvent être à l'origine de tensions. Même quand ce n'est pas le cas elles vous prendront du temps sur le travail plus important.

Cependant, si vous devez vous y résoudre, cette discussion doit être tenue en privé entre les participants qui peuvent décider par vote d'informer le principal intéressé de la situation. La personne elle-même ne devrait pas être engagée dans la discussion. Ceci va à l'encontre du principe selon lequel rien ne devrait être tenu secret, mais dans ce cas c'est nécessaire. D'abord, personne ne pourrait donner librement son avis autrement. Ensuite, si le vote échoue, vous ne voulez pas forcément que la personne sache que son éviction a été considérée car alors cela ouvrirait la voie aux questions (« Qui était de mon côté ? » ; « Qui était contre moi ? ») qui mènent aux pires clivages. Dans certains cas particuliers le groupe pourrait vouloir que la personne sache que la révocation de son accès de commit est ou a été considérée, en guise d'avertissement, mais ceci devrait rester une décision faite par le groupe. Personne ne devrait de sa propre initiative révéler l'existence d'une discussion et d'un scrutin que les autres pensaient être secret.

Une fois que l'accès de quelqu'un est révoqué, l'information deviendra forcément publique (voir la section appelée « Éviter le mystère » plus loin dans ce chapitre), essayer donc de faire preuve d'autant de tact que possible dans la manière dont vous le présentez au monde extérieur.

Accès de commit partiel

Certains projets ont différents niveaux d'accès de commit. Par exemple, certains participants peuvent jouir d'un accès de commit leur laissant toute liberté quant à la documentation, mais qui n'ont pas le même accès au code en lui même. On retrouve en général ces accès limités dans les domaines de la documentation, de la traduction, des liens entre le code et d'autres langages de programmation, des instructions détaillées la création de paquets (par exemple : les Redhat RPM spec files, etc.) et les autres domaines pour lesquels une erreur n'aura pas d'incidence sur le code.

Puisqu'avoir l'accès de commit n'est pas uniquement une question d'apport de modifications mais aussi une question d'appartenance à un électorat (voir la section appelée « Qui vote ? » dans le Chapitre 4, Infrastructure sociale et politique) la question suivante se pose naturellement : à quels votes peuvent prendre part les committers partiels ? Il n'y a pas de réponse toute faite, cela dépend des différents types de domaines de committer partiel que votre projet possède. Dans Subversion nous avons fait les choses simplement : un committer partiel peut voter pour les questions qui touchent exclusivement à son domaine et pour rien d'autre. Ce qui est important est que nous avons mis en place un système de « vote conseil » (en gros, le committer écrit « +0 » ou « +1 (ne compte pas) » plutôt que simplement « +1 » sur son bulletin). Il n'y a pas de raison de bâillonner entièrement les gens juste parce que leur vote ne compte pas formellement.

Les committers de plein droit peuvent voter pour tout, tout comme ils peuvent apporter des modifications partout et seulement cette catégorie de committers peut voter pour l'admission de nouveaux committers (quelle que soit l'étendue de leur futur accès). En pratique pourtant, la responsabilité d'ajouter de nouveaux committers partiels est souvent déléguée : n'importe quel committer de plein droit peut « parrainer » un nouveau committer partiel et les committers partiels dans un domaine peuvent souvent choisir les nouveaux committers de ce même domaine (c'est particulièrement pratique pour permettre un travail de traduction sans accrocs).

Votre projet pourrait avoir besoin d'une organisation légèrement différente selon la nature du travail, mais les mêmes principes généraux s'appliquent à tous les projets. Chaque committer devrait avoir la possibilité de voter pour les questions qui sont de son ressort et pas sur les questions qui sont au delà de son champ d'accès et les votes qui portent sur les questions procédurières devraient par défaut incomber aux committers ayant tous les droits, à moins qu'il y ait des raisons (décidées par les committers de plein droit) pour élargir la base des électeurs.

En ce qui concerne l'application de l'accès de commit partiel : il vaut souvent mieux que ce ne soit pas le logiciel de gestion de version qui fasse respecter les domaines d'accès de commit partiel. Voir la section appelée « Autorisation » dans le Chapitre 3, Infrastructure technique pour en connaître les raisons.

Les committers en hibernation

Certains projets retirent automatiquement leur accès de commit aux gens qui ne valident plus de modifications pendant un certain temps (un an par exemple). Je pense que ça n'aide en général en rien et même que c'est contre-productif, pour deux raisons.

En premier lieu, les gens pourraient se sentir obligés de valider des modifications acceptables mais inutiles simplement pour éviter que leur accès de commit n'expire. En deuxième lieu ça ne sert pas vraiment à quelque chose. Le principal critère pour accorder l'accès de commit est le jugement, ce n'est pas parce qu'une personne s'écarte du projet pendant un temps que son jugement en deviendra moins bon. Même s'il ne donne pas signe de vie pendant des années, qu'il ne regarde pas le code et qu'il ne suit pas les discussions autour du développement, quand il fait sa réapparition il saura à quel point il a pris du retard et agira en fonction. Vous aviez confiance en son jugement précédemment, alors pourquoi changer ? Si les diplômes obtenus au lycée n'ont pas de date limite de validité alors les accès de commit ne devraient pas non plus.

Parfois un committer peut demander à être remplacé ou à être clairement marqué comme étant inactif sur la liste des committers (voir la section appelée « Éviter le mystère » ci-dessous pour plus de détails à propos de cette liste). Dans ce cas, le projet devrait évidemment satisfaire le vœux de cette personne.

Éviter le mystère

Même si les discussions en rapport avec l'ajout d'un nouveau committer doivent être confidentielles, les règles et procédures en elles-mêmes n'ont pas besoin d'être secrètes. En fait il vaut mieux les publier, ainsi les gens se rendent compte que les committers ne font pas parti d'une sorte de « carré VIP » mystérieux, dont l'accès est interdit aux simples mortels, mais que chacun peut y accéder en proposant de bons correctifs et en sachant se comporter en communauté. Dans le projet Subversion nous affichons ces informations directement dans les directives développeurs puisque les personnes susceptibles d'être intéressées par les démarches menant à l'octroi d'un accès de commit sont celles qui envisagent de contribuer au projet.

En plus de publier les procédures, publiez aussi la liste des committers. Sa place habituelle est dans une fichier appelé « MAINTAINERS » ou « COMMITTERS » dans le premier niveau de l'arborescence du code source du projet. Elle devrait lister tous les committers de plein droit en premier, suivis par les différents domaines de commit partiels avec leurs membres respectifs. Les noms et adresses e-mail de chacun devraient apparaître, les adresses pouvant être encodées pour éviter le spam (voir la section nommée « Masquer les adresses dans les archives » dans le Chapitre 3, Infrastructure Technique) si la personne le désir.

Puisque la distinction entre les committers de plein droit et ceux qui ont seulement un accès partiel est bien marquée et définie il est normal que la liste fasse cette distinction aussi. Mais les distinctions faites par la liste ne devraient pas aller au delà. Elle ne doit pas faire mention des distinctions informelles qui apparaîtront inévitablement dans le projet, comme par exemple qui a une influence particulière et de quelle manière. C'est une liste publique, pas un fichier de remerciements. Listez les committers soit par ordre alphabétique soit par ordre d'arrivée.

[22] Remarquez que l'accès de commit signifie quelque chose de légèrement différent pour un logiciel de gestion de version décentralisé où chacun peut mettre en place un dépôt qui est relié au projet et se donner à lui-même l'accès de commit pour ce dépôt. Néanmoins, le concept d'accès de commit s'applique toujours : « accès de commit » est une façon de dire « l'autorisation de faire des changements au code qui seront inclus dans la prochaine version du logiciel ». Dans les logiciels de gestion de version centralisés c'est synonyme d'accès de commit direct, pour les systèmes décentralisés cela signifie voir ses modifications intégrées à la distribution principale par défaut. Dans les deux cas l'idée de base est la même, les moyens importent peu.

Credit

Credit is the primary currency of the free software world. Whatever people may say about their motivations for participating in a project, I don't know any developers who would be happy doing all their work anonymously, or under someone else's name. There are tangible reasons for this: one's reputation in a project roughly governs how much influence one has, and participation in an Open Source project can also indirectly have monetary value, because some employers now look for it on resumés. There are also intangible reasons, perhaps even more powerful: people simply want to be appreciated, and instinctively look for signs that their work was recognized by others. The promise of credit is therefore one of best motivators the project has. When small contributions are acknowledged, people come back to do more.

One of the most important features of collaborative development software (see Chapter 3, Technical Infrastructure) is that it keeps accurate records of who did what, when. Wherever possible, use these existing mechanisms to make sure that credit is distributed accurately, and be specific about the nature of the contribution. Don't just write « Thanks to J. Random <jrandom@example.com> » if instead you can write « Thanks to J. Random <jrandom@example.com> for the bug report and reproduction recipe » in a log message.

In Subversion, we have an informal but consistent policy of crediting the reporter of a bug in either the issue filed, if there is one, or the log message of the commit that fixes the bug, if not. A quick survey of Subversion commit logs up to commit number 14525 shows that about 10% of commits give credit to someone by name and e-mail address, usually the person who reported or analyzed the bug fixed by that commit. Note that this person is different from the developer who actually made the commit, whose name is already recorded automatically by the version control system. Of the 80-odd full and partial committers Subversion has today, 55 were credited in the commit logs (usually multiple times) before they became committers themselves. This does not, of course, prove that being credited was a factor in their continued involvement, but it at least sets up an atmosphere in which people know they can count on their contributions being acknowledged.

It is important to distinguish between routine acknowledgment and special thanks. When discussing a particular piece of code, or some other contribution someone made, it is fine to acknowledge their work. For example, saying « Daniel's recent changes to the delta code mean we can now implement feature X » simultaneously helps people identify which changes you're talking about and acknowledges Daniel's work. On the other hand, posting solely to thank Daniel for the delta code changes serves no immediate practical purpose. It doesn't add any information, since the version control system and other mechanisms have already recorded the fact that he made the changes. Thanking everyone for everything would be distracting and ultimately information-free, since thanks are effective largely by how much they stand out from the default, background level of favorable comment going on all the time. This does not mean, of course, that you should never thank people. Just make sure to do it in ways that tend not to lead to credit inflation. Following these guidelines will help:

     The more ephemeral the forum, the more free you should feel to express thanks there. For example, thanking someone for their bugfix in passing during an IRC conversation is fine, as is an aside in an e-mail devoted mainly to other topics. But don't post an e-mail solely to thank someone, unless it's for a truly unusual feat. Likewise, don't clutter the project's Web pages with expressions of gratitude. Once you start that, it'll never be clear when or where to stop. And never put thanks into comments in the code; that would only be a distraction from the primary purpose of comments, which is to help the reader understand the code.
   *

     The less involved someone is in the project, the more appropriate it is to thank her for something she did. This may sound counterintuitive, but it fits with the attitude that expressing thanks is something you do when someone contributes even more than you thought she would. Thus, to constantly thank regular contributors for doing what they normally do would be to express a lower expectation of them than they have of themselves. If anything, you want to aim for the opposite effect!

     There are occasional exceptions to this rule. It's acceptable to thank someone for fulfilling his expected role when that role involves temporary, intense efforts from time to time. The canonical example is the release manager, who goes into high gear around the time of each release, but otherwise lies dormant (dormant as a release manager, in any case—he may also be an active developer, but that's a different matter).
   *

     As with criticism and crediting, gratitude should be specific. Don't thank people just for being great, even if they are. Thank them for something they did that was out of the ordinary, and for bonus points, say exactly why what they did was so great.

In general, there is always a tension between making sure that people's individual contributions are recognized, and making sure the project is a group effort rather than a collection of individual glories. Just remain aware of this tension and try to err on the side of group, and things won't get out of hand.

Remerciements

Les remerciements sont la monnaie du monde du logiciel libre. Peu importe quelles motivations avancent les gens pour expliquer leur participation à un projet, je ne connais aucun développeur qui serait heureux de faire tout ce travail anonymement ou sous une autre identité. Les raisons sont tout à fait compréhensibles : c'est la réputation de quelqu'un dans un projet qui détermine plus ou moins son influence et la participation dans un projet Open Source peut aussi avoir indirectement une valeur monétaire parce que certains employeurs recherchent cette référence sur un CV désormais. Il y a aussi d'autres raisons moins évidentes, mais peut-être plus puissantes également : les gens veulent simplement qu'on les apprécie et recherchent instinctivement des signes qui montrent que leur travail a été reconnu par d'autres. L'une des meilleures motivations qu'un projet peut offrir est donc la promesse de remerciements. Lorsque des contributions minimes sont reconnues cela incite les gens a en faire plus.

L'un des aspects les plus importants du développement collaboratif accompli sur un logiciel (voir Chapitre 3, Infrastructure Technique) est qu'il conserve une trace de qui a fait quoi et quand. Chaque fois que cela est possible, utilisez les moyens existants pour exprimer votre gratitude de manière précise et soyez explicite quant à la nature de la contribution. N'écrivez pas simplement « Merci à A. Nonyme <anonyme@exemple.com> » si vous pouvez écrire à la place « Merci à A. Nonyme <anonyme@exemple.com> pour le rapport de bogue et les pistes de résolution » dans un message de journal.

A Subversion, nous avons une règle informelle mais cohérente pour remercier les personnes qui rapportent un bogue, soit dans le formulaire du problème, s'il y en a un, ou dans le message de journal du commit qui règle le bogue. Un rapide tour d'horizon des journaux des commits de Subversion jusqu'au commit 14525 montre que 10% des commits font des remerciements nominativement et font figurer l'adresse e-mail, des remerciements sont en général destinés aux personnes qui ont rapporté ou analysé les bogues que ce commit a corrigés. Remarquez que cette personne n'est pas le développeur qui a vraiment fait la validation, dont le nom est déjà automatiquement enregistré par le logiciel de gestion de version. Parmi les 80 et quelques committers (partiels et de plein droit) que compte actuellement Subversion, 55 d'entre eux avaient déjà été remercié (en général plus d'une fois) dans le journal de validation avant de devenir committers eux-mêmes. Cela ne prouve évidemment pas qu'être remercié est un facteur de leur implication continue mais au moins cela établit une atmosphère dans laquelle les gens savent que leur contribution sera remarquée.

Il est important de distinguer les remerciements de routine et les remerciements particuliers. Quand vous débattez d'un morceau de code particulier, ou d'une autre contribution que quelqu'un a apportée, ça n'est pas une mauvaise chose de reconnaître leur travail. Par exemple, dire « Les dernières modifications de Daniel au code delta nous permettent maintenant d'ajouter la fonctionnalité X » aide les gens à savoir de quels changements vous parlez et en même temps montre votre appréciation pour le travail de Daniel. D'un autre côté, simplement dire « Merci à Daniel pour ses modifications au code delta » n'apporte rien. Aucune information nouvelle n'est transmise puisque le logiciel de gestion de version et d'autres mécanismes ont déjà enregistrés le fait qu'il a apporté des modifications. Remercier tout le monde pour tout et n'importe quoi vous ferez perdre votre temps et n'apporterez pas d'information puisque la portée de remerciements dépend beaucoup de comment ils se démarquent des commentaires positifs habituels qui affluent en permanence. Cela ne veut évidemment pas dire que vous ne devriez pas remercier les gens. Assurez vous simplement de le faire tout en ne donnant pas dans la surenchère de remerciements. Ces quelques conseils devraient vous aider :

Vous êtes libre d'exprimer toute votre gratitude dans une discussion éphémère. Par exemple, remercier en passant, durant une conversation IRC, quelqu'un pour avoir corrigé un bogue est bien, idem pour une remarque dans un e-mail dédié principalement à d'autres sujets. Mais n'envoyez pas un e-mail juste pour remercier quelqu'un, à moins qu'il ait accompli un fait vraiment exceptionnel. De la même manière, ne surchargez pas les pages Web du projet avec des remerciements. Une fois que vous mettez le doigt dans l'engrenage vous ne saurez jamais où et comment vous en sortir. Et ne mettez pas de remerciements dans les commentaires du code, il ne faut pas s'éloigner du but premier des commentaires qui est d'aider le lecteur à comprendre le code.

Il est important de remercier les personnes les moins impliquées pour ce qu'elles ont fait. Même si cela peut sembler illogique ça cadre avec l'idée que vous devez exprimer votre gratitude aux personnes qui dépassent vos attentes. Un corollaire de ceci est que trop remercier les personnes qui contribuent régulièrement pour avoir fait ce qu'elles font normalement signifiera que vous attendez moins de leur implication qu'elles ne pensaient. C'est plutôt l'effet contraire que vous recherchez !

Il y a certaines exceptions à cette règle. Il est normal que vous remerciez quelqu'un pour avoir fait ce qui est attendu de sa part si cela signifie qu'il a dû consentir des efforts intenses de temps en temps sur des périodes données. L'exemple typique est le responsable sorties qui s'arme lourdement quand la sortie approche mais qui le reste du temps se met en hibernation (en hibernation en tant que responsable sorties, il peut très bien être actif en tant que développeur, mais c'est un autre chose encore).

Comme pour les critiques et les remerciements, la gratitude devrait être précise. Ne remerciez pas les gens simplement parce qu'ils sont supers, même s'ils le sont. Remerciez les pour quelque chose qu'ils ont fait qui sort de l'ordinaire et pour les bons points précisez en quoi ce qu'ils ont fait était super.

En général il y a toujours des tiraillements entre la nécessité de s'assurer que les contributions de chacun sont reconnues et le besoin de s'assurer que le projet est un effort de groupe et pas un ensemble de faits individuels mis bouts à bouts. Gardez ceci à l'esprit et essayez de faire penchez la balance en faveur du groupe, ainsi vous pourrez garder le contrôle.

Forks

Forks / Les fourches

In the section called “Forkability” in Chapter 4, Social and Political Infrastructure, we saw how the potential to fork has important effects on how projects are governed. But what happens when a fork actually occurs? How should you handle it, and what effects can you expect it to have? Conversely, when should you initiate a fork?

Dans la section « Fourchabilité » dans le Chapitre 4, Infrastructure sociale et politique, nous avons vu l'influence qu'à la possibilité de fourcher sur la gestion du projet. Mais que se passe-t-il quand une fourche se concrétise réellement ? Comment devriez vous gérer la situation et à quelles conséquences devriez vous vous attendre ? Et inversement, quand devriez vous concrétiser une fourche ?

The answers depend on what kind of fork it is. Some forks are due to amicable but irreconcilable disagreements about the direction of the project; perhaps more are due to both technical disagreements and interpersonal conflicts. Of course, it's not always possible to tell the difference between the two, as technical arguments may involve personal elements as well. What all forks have in common is that one group of developers (or sometimes even just one developer) has decided that the costs of working with some or all of the others now outweigh the benefits.

Les réponses dépendent du type de fourche à laquelle vous avez affaire. Certaines fourches sont dues à des différences de point de vue amicales mais irréconciliables sur la manière de mener le projet mais peut-être que plus nombreuses sont celles dues à la fois à des désaccords techniques et des conflits de relation. Bien sûr, il n'est pas toujours possible de discerner l'un de l'autre puisque les débats techniques peuvent contenir des sentiments personnels également. Ce que toutes les fourches ont en commun est qu'un groupe de développeurs (parfois même juste un seul développeur) a décidé que le travail avec certains ou avec tous les autres développeurs lui coûte plus qu'il n'en tire de bénéfices.

Once a project forks, there is no definitive answer to the question of which fork is the « true » or « original » project. People will colloquially talk of fork F coming out of project P, as though P is continuing unchanged down some natural path while F diverges into new territory, but this is, in effect, a declaration of how that particular observer feels about it. It is fundamentally a matter of perception: when a large enough percentage of observers agree, the assertion starts to become true. It is not the case that there is an objective truth from the outset, one that we are only imperfectly able to perceive at first. Rather, the perceptions are the objective truth, since ultimately a project—or a fork—is an entity that exists only in people's minds anyway.

Dès qu'un projet fourche il est difficile de dire quelle est la « vraie » fourche ou quel est le projet « original ». Les gens parleront de la fourche F issue du projet P, avec P poursuivant à l'identique le long d'un chemin naturel alors que F s'aventure sur un nouveau territoire, mais ceci, déjà, est teinté de subjectivité. C'est principalement un problème de perception : quand un nombre suffisamment important d'observateurs sont d'accord l'assertion devient vraie. Ici il n'y a pas de vérité objective dès le début, pas de vérité qui saute aux yeux. Ce sont plutôt les perceptions qui forment cette vérité objective puisque, au final, le projet ou la fourche est une entité qui n'existe que dans l'esprit des gens de toute façon.

If those initiating the fork feel that they are sprouting a new branch off the main project, the perception question is resolved immediately and easily. Everyone, both developers and users, will treat the fork as a new project, with a new name (perhaps based on the old name, but easily distinguishable from it), a separate Web site, and a separate philosophy or goal. Things get messier, however, when both sides feel they are the legitimate guardians of the original project and therefore have the right to continue using the original name. If there is some organization with trademark rights to the name, or legal control over the domain or Web pages, that usually resolves the issue by fiat: that organization will decide who is the project and who is the fork, because it holds all the cards in a public relations war. Naturally, things rarely get that far: since everyone already knows what the power dynamics are, they will avoid fighting a battle whose outcome is known in advance, and just jump straight to the end.

Si ceux à l'origine de la fourche pensent qu'ils font germer une nouvelle branche sur le projet principal, la question de la perception est résolue immédiatement et facilement. Tout le monde, à la fois les développeurs et les utilisateurs, verra la fourche comme un nouveau projet, avec un nouveau nom (peut-être basé sur l'ancien nom, mais facilement reconnaissable), un site Web distinct et une philosophie ou un but distinct. Cependant, les choses se compliquent quand les deux camps considèrent qu'ils sont les légataires de l'esprit original du projet et qu'ils ont donc le droit de le poursuivre sous son nom d'origine. Si un organisme possède les droits sur le nom ou le contrôle légal du domaine ou des pages Web la question est en général résolue légalement : cet organisme décidera de qui est le projet et qui est la fourche puisqu'il a toutes les cartes en main dans la guerre des relations publiques. Évidemment, les choses vont rarement aussi loin : puisque tout le monde est au fait de qui tient les rennes, ils éviteront de commencer une bataille dont l'issue est connue d'avance et iront droit au résultat.

Fortunately, in most cases there is little doubt as to which is the project and which is the fork, because a fork is, in essence, a vote of confidence. If more than half of the developers are in favor of whatever course the fork proposes to take, usually there is no need to fork—the project can simply go that way itself, unless it is run as a dictatorship with a particularly stubborn dictator. On the other hand, if fewer than half of the developers are in favor, the fork is a clearly minority rebellion, and both courtesy and common sense indicate that it should think of itself as the divergent branch rather than the main line.

Heureusement, dans la plupart des cas il y a peu de doute quant à qui est le projet et qui est la fourche puisque, par nature, une fourche est un vote de confiance. Si plus de la moitié des développeurs sont pour le chemin tracé par la fourche, en général, il n'y a pas besoin de fourche, le projet peut simplement emprunter ce chemin à moins qu'il ne soit dirigé comme une dictature dont le chef serait particulièrement borné. A l'opposé, si moins de la moitié des développeurs sont pour, la fourche est clairement la rébellion d'une minorité et la courtoisie et le bon sens veulent qu'ils se considèrent alors comme la branche divergente plutôt que la ligne principale.

Handling a Fork / Gérer une fourche

If someone threatens a fork in your project, keep calm and remember your long-term goals. The mere existence of a fork isn't what hurts a project; rather, it's the loss of developers and users. Your real aim, therefore, is not to squelch the fork, but to minimize these harmful effects. You may be mad, you may feel that the fork was unjust and uncalled for, but expressing that publicly can only alienate undecided developers. Instead, don't force people to make exclusive choices, and be as cooperative as is practicable with the fork. To start with, don't remove someone's commit access in your project just because he decided to work on the fork. Work on the fork doesn't mean that person has suddenly lost his competence to work on the original project; committers before should remain committers afterward. Beyond that, you should express your desire to remain as compatible as possible with the fork, and say that you hope developers will port changes between the two whenever appropriate. If you have administrative access to the project's servers, publicly offer the forkers infrastructure help at startup time. For example, offer them a complete, deep-history copy of the version control repository, if there's no other way for them to get it, so that they don't have to start off without historical data (this may not be necessary depending on the version control system). Ask them if there's anything else they need, and provide it if you can. Bend over backward to show that you are not standing in the way, and that you want the fork to succeed or fail on its own merits and nothing else.

Si quelqu'un menace de lancer une fourche de votre projet, gardez votre calme et souvenez vous de vos buts à long terme. Le simple fait qu'une fourche existe n'est pas ce qui menace votre projet, la perte de développeurs et d'utilisateurs voilà le vrai risque. Votre réel objectif alors n'est pas de bâillonner la fourche mais d'en minimiser les effets néfastes. Vous pourrez être énervé, vous pourrez penser que la fourche n'est pas justifiée et n'a pas de légitimité, mais exprimer cela en public ne peut que vous aliéner les développeurs indécis. A la place vous ne devriez pas forcer les développeurs à faire un choix entre les deux projets et vous devez être aussi coopératifs que possible avec la fourche. En premier lieu, ne retirez pas à quelqu'un son accès de commit dans votre projet simplement parce qu'il a décidé de travailler sur la fourche. Le fait de travailler sur la fourche ne veut pas dire qu'il a soudainement perdu ses capacités à travailler sur le projet original, ceux qui étaient committers devraient le rester. Au delà de ça vous devriez exprimer votre envie de maintenir la compatibilité avec la fourche et dire que vous espérez que les développeurs feront des portages entre les deux chaque fois que ça sera approprié. Si vous avez un accès direct au serveur hébergeant le projet, offrez publiquement à la fourche une aide matérielle pour ses débuts. Par exemple, proposez leur un historique complet et détaillé du dépôt de gestion de version, s'ils n'ont pas d'autre moyen de l'obtenir, afin qu'ils n'aient pas à débuter sans historique (cela n'est pas forcément nécessaire, ça dépend du logiciel de gestion de version). Demandez leur s'il y a autre chose dont ils ont besoin et fournissez leur si vous le pouvez. Inclinez vous, avec réserve, pour montrer que vous ne serez pas un obstacle et que vous voulez voir la fourche réussir ou échouer grâce ou à cause de ses qualités intrinsèques et pas pour d'autres raisons.

The reason to do all this—and do it publicly—is not to actually help the fork, but to persuade developers that your side is a safe bet, by appearing as non-vindictive as possible. In war it sometimes makes sense (strategic sense, if not human sense) to force people to choose sides, but in free software it almost never does. In fact, after a fork some developers often openly work on both projects, and do their best to keep the two compatible. These developers help keep the lines of communication open after the fork. They allow your project to benefit from interesting new features in the fork (yes, the fork may have things you want), and also increase the chances of a merger down the road.

Si vous devez faire tout cela, et le faire publiquement, ce n'est pas pour aider la fourche en fait, mais pour montrer aux développeurs que rester de votre côté est le pari le plus sûr en vous montrant aussi peu vindicatif que possible. En temps de guerre il est parfois logique (stratégiquement parlant si ce n'est pas humainement) de forcer les gens à choisir leur camp, mais pour les logiciels libres ce n'est presque jamais le cas. En fait, quand une fourche apparaît, certains développeurs ne cachent pas le fait qu'ils travaillent sur les deux projets et font de leur mieux pour maintenir leur compatibilité. Ces développeurs aident à conserver les lignes de communications ouvertes après la séparation. Ils permettent à votre projet de bénéficier des nouvelles fonctionnalités intéressantes de la fourche (oui, la fourche peut proposer des choses que vous désirez) et augmentent aussi la probabilité d'une fusion ultérieure.

Sometimes a fork becomes so successful that, even though it was regarded even by its own instigators as a fork at the outset, it becomes the version everybody prefers, and eventually supplants the original by popular demand. A famous instance of this was the GCC/EGCS fork. The GNU Compiler Collection (GCC, formerly the GNU C Compiler) is the most popular Open Source native-code compiler, and also one of the most portable compilers in the world. Due to disagreements between the GCC's official maintainers and Cygnus Software,[23] one of GCC's most active developer groups, Cygnus created a fork of GCC called EGCS. The fork was deliberately non-adversarial: the EGCS developers did not, at any point, try to portray their version of GCC as a new official version. Instead, they concentrated on making EGCS as good as possible, incorporating patches at a faster rate than the official GCC maintainers. EGCS gained in popularity, and eventually some major operating system distributors decided to package EGCS as their default compiler instead of GCC. At this point, it became clear to the GCC maintainers that holding on to the « GCC » name while everyone switched to the EGCS fork would burden everyone with a needless name change, yet do nothing to prevent the switchover. So GCC adopted the EGCS codebase, and there is once again a single GCC, but greatly improved because of the fork.

Parfois une fourche gagne un tel succès que même si elle était considérée comme une fourche par ses instigateurs au départ, elle devient la version que tout le monde préfère et finalement supplante la version original à la demande des utilisateurs. Un exemple connu de ceci était la fourche GCC/EGCS. Le GNU Compiler Collection (GCC, anciennement GNU C Compiler) est le compilateur de code exécutable Open Source le plus populaire et aussi l'un des compilateurs les plus portables du monde. En raison de désaccords entre les développeurs officiel de GCC et Cygnus Software, [23] l'un des groupes de développement de GCC le plus actif, Cygnus créa une fourche de GCC appelée EGCS. Ils avaient décidé de ne pas entrer en compétition : les développeurs d'EGCS n'ont jamais, à aucun moment, essayé de présenter leur version de GCC comme étant la nouvelle version officielle. Ils se sont plutôt concentrés sur l'amélioration de EGCS en ajoutant des correctifs plus rapidement que ne le faisaient les développeurs officiels de GCC. EGCS a gagné en popularité et finalement certains parmi les principaux distributeurs de systèmes d'exploitation ont décidé d'adopter EGCS comme compilateur par défaut à la place de GCC. Il était alors devenu clair pour les développeurs de GCC que s'accrocher au nom « GCC », alors que tout le monde adoptait la fourche EGCS, ne serait qu'un désagrément pour tout le monde avec un changement de nom inutile mais qui au final n'empêcherait pas la migration. Alors GCC a adopté le code de base de EGCS et il y avait alors à nouveau plus qu'un seul GCC, mais grandement amélioré grâce à la fourche.

This example shows why you cannot always regard a fork as an unadulteratedly bad thing. A fork may be painful and unwelcome at the time, but you cannot necessarily know whether it will succeed. Therefore, you and the rest of the project should keep an eye on it, and be prepared not only to absorb features and code where possible, but in the most extreme case to even join the fork if it gains the bulk of the project's mindshare. Of course, you will often be able to predict a fork's likelihood of success by seeing who joins it. If the fork is started by the project's biggest complainer and joined by a handful of disgruntled developers who weren't behaving constructively anyway, they've essentially solved a problem for you by forking, and you probably don't need to worry about the fork taking momentum away from the original project. But if you see influential and respected developers supporting the fork, you should ask yourself why. Perhaps the project was being overly restrictive, and the best solution is to adopt into the mainline project some or all of the actions contemplated by the fork—in essence, to avoid the fork by becoming it.

Cet exemple montre que vous ne pouvez pas toujours voir une fourche comme une sorte d'adultère. Même si une fourche peut être douloureuse et indésirable, vous ne pouvez pas forcément prédire si elle réussira ou pas. Vous, et le reste du projet, devriez donc la surveillez et vous préparez, non seulement à en absorber des fonctionnalités et du code quand c'est possible, mais dans les cas les plus extrêmes à rejoindre la fourche si elle gagne le cœur du gros du projet. Bien sûr, vous pourrez souvent prédire les chances de succès d'une fourche d'après personnes qui s'y joignent. Si la fourche est initiée par les pires empoisonneurs et ralliée par un groupe de développeurs mécontents qui n'apportait rien de constructif de toute façon ils vous font en fait une faveur en choisissant un autre chemin et vous n'avez pas à vous soucier de l'importance que prendra la fourche par rapport au projet originel. Mais si vous voyez des développeurs influents et respectés soutenir la fourche vous devriez vous demander pourquoi. Peut-être que le projet devenait trop restrictif et la meilleure solution est alors que le projet principal fasse siennes toutes ou une partie des actions envisagées par la fourche, c'est-à-dire, éviter que la fourche se concrétise.

Initiating a Fork / Amorcer une fourche

All the advice here assumes that you are forking as a last resort. Exhaust all other possibilities before starting a fork. Forking almost always means losing developers, with only an uncertain promise of gaining new ones later. It also means starting out with competition for users' attention: everyone who's about to download the software has to ask themselves: « Hmm, do I want that one or the other one? » Whichever one you are, the situation is messy, because a question has been introduced that wasn't there before. Some people maintain that forks are healthy for the software ecosystem as a whole, by a standard natural selection argument: the fittest will survive, which means that, in the end, everyone gets better software. This may be true from the ecosystem's point of view, but it's not true from the point of view of any individual project. Most forks do not succeed, and most projects are not happy to be forked.

Tous les conseils donnés ici supposent que la fourche intervient en dernier recours. Épuisez toutes les autres solutions avant de commencer une fourche. Le fait d'amorcer une fourche est presque toujours synonyme de perte de développeurs, avec seulement la promesse vague d'en gagner de nouveaux plus tard. Cela implique également que vous allez entrer en compétition pour gagner l'attention des utilisateurs : tous ceux qui s'apprêtent à télécharger le logiciel vont se demander : « Hum, est-ce que je veux celui-là ou cet autre là ? » Que vous soyez le premier ou le deuxième, la situation est épineuse car une nouvelle question a été ajoutée. D'après certaines personnes les fourches sont bonnes pour l'écosystème du logiciel entier si l'on se base sur les arguments de la sélection naturelle : le plus adapté survivra, ce qui signifie que, au final, tout le monde profite d'un meilleur logiciel. Cela peut être vrai du point de vue de l'écosystème, mais ce n'est pas vrai du point de vue du projet prit individuellement. La plupart des fourches ne réussissent pas et la plupart des projets ne sont pas enchantés d'être divisés.

A corollary is that you should not use the threat of a fork as an extremist debating technique—"Do things my way or I'll fork the project!"—because everyone is aware that a fork that fails to attract developers away from the original project is unlikely to survive long. All observers—not just developers, but users and operating system packagers too—will make their own judgement about which side to choose. You should therefore appear extremely reluctant to fork, so that if you finally do it, you can credibly claim it was the only route left.

Un corollaire à cela est que vous ne devriez pas utiliser l'argument de la fourche comme un argument extrémiste. : « Faites ce que je veux ou je commencerai une fourche ! », parce que tout le monde sait que les fourches qui n'arrivent pas à capter des développeurs du projet originel n'ont qu'une faible chance de survie. Tous les observateurs, pas seulement les développeurs, mais aussi les utilisateurs et ceux qui font les dépôts pour les systèmes d'exploitation, choisiront leur camp selon leurs propres critères. Vous devriez donc vous montrer réticent à l'idée de commencer une fourche, ainsi si vous devez finalement vous y résoudre, vous pourrez affirmer avec crédibilité que c'était votre dernière alternative.

Do not neglect to take all factors into account in evaluating the potential success of your fork. For example, if many of the developers on a project have the same employer, then even if they are disgruntled and privately in favor of a fork, they are unlikely to say so out loud if they know that their employer is against it. Many free software programmers like to think that having a free license on the code means no one company can dominate development. It is true that the license is, in an ultimate sense, a guarantor of freedom—if others want badly enough to fork the project, and have the resources to do so, they can. But in practice, some projects' development teams are mostly funded by one entity, and there is no point pretending that that entity's support doesn't matter. If it is opposed to the fork, its developers are unlikely to take part, even if they secretly want to.

Ne négligez aucun facteur lorsque vous évaluez les chances de succès de votre fourche. Par exemple, si beaucoup de développeurs sur un projet ont le même employeur, alors même s'ils sont mécontents et secrètement en faveur d'une fourche il y a peu de chance qu'ils l'annoncent ouvertement si leur employeur est contre. De nombreux programmeurs de logiciels libres aiment à penser que le fait d'appliquer une licence libre au code signifie qu'aucune entreprise ne peut en dominer le développement. C'est vrai que la licence est au final une garantie de liberté, si certains veulent vraiment initier une branche et ont les moyens de le faire ils le peuvent. Mais en pratique les équipes de développement de certains projets sont principalement financées par une entité et vous ne pouvez pas faire comme si ce soutien ne comptait pas. Si cette entité est opposée à la fourche il y a peu de chance que ses développeurs y prennent partie, même s'ils le désirent secrètement.

If you still conclude that you must fork, line up support privately first, then announce the fork in a non-hostile tone. Even if you are angry at, or disappointed with, the current maintainers, don't say that in the message. Just dispassionately state what led you to the decision to fork, and that you mean no ill will toward the project from which you're forking. Assuming that you do consider it a fork (as opposed to an emergency preservation of the original project), emphasize that you're forking the code and not the name, and choose a name that does not conflict with the project's name. You can use a name that contains or refers to the original name, as long as it does not open the door to identity confusion. Of course it's fine to explain prominently on the fork's home page that it descends from the original program, and even that it hopes to supplant it. Just don't make users' lives harder by forcing them to untangle an identity dispute.

Si pour autant vous pensez toujours qu'une fourche est nécessaire assurez vous de vos soutiens en privé en premier, annoncez ensuite la naissance de la fourche de manière amicale. Même si vous êtes en colère ou déçu par les responsables actuels ne le dites pas dans le message. Exposez sans emportement les raisons qui vous ont poussé à prendre cette décision et annoncez que vous ne souhaitez pas nuire au projet en faisant cela. En supposant que vous la considérez bien comme une fourche (en opposition avec une manœuvre d'urgence de préservation du projet originel), soulignez bien que vous utiliserez le code, mais pas le nom du projet et que vous choisissez un nom qui ne prêtera pas à confusion. Vous pouvez utiliser un nom qui contient ou fait référence au nom original tant qu'il évite toute confusion d'identité. Évidemment vous pouvez mettre en avant sur le page Web de la fourche le lien de parenté avec le programme originel et même que vous espérez le supplanter. Essayez simplement de ne pas compliquer la vie des utilisateurs en les mêlant à une bataille identitaire.

Finally, you can get things started on the right foot by automatically granting all committers of the original project commit access to the fork, including even those who openly disagreed with the need for a fork. Even if they never use the access, your message is clear: there are disagreements here, but no enemies, and you welcome code contributions from any competent source.

[23] Now part of RedHat (http://www.redhat.com/).

Pour finir, vous pouvez commencer du bon pied en octroyant automatiquement l'accès de commit pour la fourche à tous ceux qui l'avaient déjà pour le projet originel, même à ceux qui montraient ouvertement leur désaccord sur la nécessité d'une fourche. Même s'ils n'utilisent jamais leur accès, votre message est clair : il y a des désaccords, mais pas d'ennemis et toutes les contributions de tous ceux qui en ont les compétences sont les bienvenues.

[23] Maintenant partie intégrante de RedHat (http://www.redhat.com).

POSS Chap 8

De Framalang Wiki.

Sommaire

Chapter 8. Managing Volunteers

Getting the Most Out of Volunteers

Tirer le meilleur des volontaires

Delegation

Déléguer

Distinguish clearly between inquiry and assignment

Distinguer clairement requête et assignation

Follow up after you delegate

Le suivi après la délégation

Notice what people are interested in

Remarquer les centres d'intérêts des gens

Praise and Criticism

Félicitations et critiques

Prevent Territoriality

Éviter le marquage de territoire

The Automation Ratio

La bonne dose d'automatisation

Automated testing

Les tests automatisés

Treat Every User as a Potential Volunteer

Considérez tous les utilisateurs comme des volontaires potentiels

Share Management Tasks as Well as Technical Tasks

Partager les tâches de gestion aussi bien que les tâches techniques

Patch Manager

Responsable correctifs

Translation Manager

Responsable traduction

Documentation Manager

Responsable documentation

Issue Manager

Responsable difficultés

FAQ Manager

Responsable FAQ

Transitions

Transitions

Transitions

Committers

Committers

Committers

Credit

Credit

Remerciements

Forks

Forks / Les fourches

Handling a Fork / Gérer une fourche

Initiating a Fork / Amorcer une fourche

Affichages

Outils personnels

Navigation

Chercher

Boîte à outils