POSS Chap 2 Part 3
Un article de Framalang Wiki.
[modifier] Setting the Tone
So far we've covered one-time tasks you do during project setup: picking a license, arranging the initial Web site, etc. But the most important aspects of starting a new project are dynamic. Choosing a mailing list address is easy; ensuring that the list's conversations remain on-topic and productive is another matter entirely. If the project is being opened up after years of closed, in-house development, its development processes will change, and you will have to prepare the existing developers for that change.
The first steps are the hardest, because precedents and expectations for future conduct have not yet been set. Stability in a project does not come from formal policies, but from a shared, hard-to-pin-down collective wisdom that develops over time. There are often written rules as well, but they tend to be essentially a distillation of the intangible, ever-evolving agreements that really guide the project. The written policies do not define the project's culture so much as describe it, and even then only approximately.
There are a few reasons why things work out this way. Growth and high turnover are not as damaging to the accumulation of social norms as one might think. As long as change does not happen too quickly, there is time for new arrivals to learn how things are done, and after they learn, they will help reinforce those ways themselves. Consider how children's songs survive the centuries. There are children today singing roughly the same rhymes as children did hundreds of years ago, even though there are no children alive now who were alive then. Younger children hear the songs sung by older ones, and when they are older, they in turn will sing them in front of other younger ones. The children are not engaging in a conscious program of transmission, of course, but the reason the songs survive is nonetheless that they are transmitted regularly and repeatedly. The time scale of free software projects may not be measured in centuries (we don't know yet), but the dynamics of transmission are much the same. The turnover rate is faster, however, and must be compensated for by a more active and deliberate transmission effort.
This effort is aided by the fact that people generally show up expecting and looking for social norms. That's just how humans are built. In any group unified by a common endeavor, people who join instinctively search for behaviors that will mark them as part of the group. The goal of setting precedents early is to make those " in-group " behaviors be ones that are useful to the project; for once established, they will be largely self-perpetuating.
Following are some examples of specific things you can do to set good precedents. They're not meant as an exhaustive list, just as illustrations of the idea that setting a collaborative mood early helps a project tremendously. Physically, every developer may be working alone in a room by themselves, but you can do a lot to make them feel like they're all working together in the same room. The more they feel this way, the more time they'll want to spend on the project. I chose these particular examples because they came up in the Subversion project (http://subversion.tigris.org/), which I participated in and observed from its very beginning. But they're not unique to Subversion; situations like these will come up in most Open Source projects, and should be seen as opportunities to start things off on the right foot.
[modifier] Donner le ton
Jusque-là nous avons vu les tâches que vous faites une fois pour toutes, choisir une licence, créer le site Web, etc. Mais les aspects les plus importants de la création d'un projet changent sans cesse. Le choix d'une adresse pour la liste de diffusion est simple, s'assurez que les discussions sur cette liste ne dévient pas est complètement différent. Si le projet s'ouvre après des années de développement interne, son processus de développement s'en retrouvera modifié et vous devrez préparer les développeurs déjà présent à ce changement.
Les premiers pas sont les plus durs car les modèles et les attentes pour le futur n'ont pas encore été définis. La stabilité d'un projet n'est pas due à des règles formelles mais à une sagesse collective, difficile à définir, qui se développe avec le temps. On retrouve souvent des règles écrites également, mais elles représentent plus une version purifiée des accords intangibles et sans cesse changeants qui dirigent vraiment le projet. Les règles écrites sont plus descriptives de la culture du projet que caractérisantes, et encore, seulement approximativement.
Il y a plusieurs raisons à ce mode de fonctionnement. La croissance et un fort taux de renouvellement ne sont pas aussi nuisibles à l'accumulation de normes sociales qu'on pourrait le penser. Tant que les changements ne se produisent pas trop vite, les nouveaux arrivant ont le temps d'apprendre comment les choses fonctionnent, et après avoir appris, ils apporteront leur propre contribution. Voyez comme les chansons enfantines survivent à travers les siècles. Les enfants d'aujourd'hui chantent plus ou moins les mêmes rimes que celles chantées par d'autres enfants il y a des centaines d'années de cela, bien qu'aucun enfant de l'époque ne soit encore vivant. Les jeunes enfants entendent des chansons chantées par d'autres plus âgés, ensuite quand ils sont plus vieux ils les chantent à leur tour devant d'autres plus jeunes qu'eux. Les enfants n'entrent pas consciemment dans ce programme de transmission évidemment, mais la raison qui fait que ces chansons survivent est qu'elles sont malgré tout transmises régulièrement et de manière répétée. L'échelle de temps des logiciels libres ne se mesure peut-être pas en siècles (on ne sait pas pour l'instant), mais les moyens de transmission sont très proches. Le taux de renouvellement est plus rapide cependant et doit être compensé par un effort de transmission plus actif et volontaire.
Cet effort est aidé par le fait que les gens arrivent en cherchant et en espérant trouver des normes sociales. L'Homme est ainsi fait. Dans un groupe unifié par un but commun les recrues cherchent instinctivement les attitudes qui montreront qu'ils font partie du groupe. Le but est d'établir rapidement des modèles et de rendre ces comportements « de groupe » utiles au projet, car une fois en place ils se perpétueront principalement par eux mêmes.
Vous trouverez ci-dessous quelques pistes qui vous aideront à indiquer la bonne marche à suivre. Cette liste n'est pas exhaustive, ce sont simplement des illustrations de l'idée que créer tôt une bonne collaboration aide énormément le projet. Physiquement, les développeurs travailleront peut-être seuls, mais vous pouvez faire en sorte qu'ils se sentent plus proche, comme s'ils travaillaient tous dans la même pièce. Si vous réussissez, ils auront plus envie de passer de temps sur le projet. Je choisis ces exemples en particulier car le projet Subversion y a été confronté (http://subversion.tigris.org/). J'y ai participé, j'ai pu observer depuis le tout début ces problèmes. Mais ils ne sont pas spécifiques à Subversion, la plus part des projets Open Source les rencontreront et ces exemples doivent être pris comme une opportunité de commencer du bon pied.
[modifier] Avoid Private Discussions
Even after you've taken the project public, you and the other founders will often find yourselves wanting to settle difficult questions by private communications among an inner circle. This is especially true in the early days of the project, when there are so many important decisions to make, and, usually, few volunteers qualified to make them. All the obvious disadvantages of public list discussions will loom palpably in front of you: the delay inherent in e-mail conversations, the need to leave sufficient time for consensus to form, the hassle of dealing with naive volunteers who think they understand all the issues but actually don't (every project has these; sometimes they're next year's star contributors, sometimes they stay naive forever), the person who can't understand why you only want to solve problem X when it's obviously a subset of larger problem Y, and so on. The temptation to make decisions behind closed doors and present them as faits accomplis, or at least as the firm recommendations of a united and influential voting block, will be great indeed.
Don't do it.
As slow and cumbersome as public discussions can be, they're almost always preferable in the long run. Making important decisions in private is like spraying contributor repellant on your project. No serious volunteer would stick around for long in an environment where a secret council makes all the big decisions. Furthermore, public discussion has beneficial side effects that will last beyond whatever ephemeral technical question was at issue:
- The discussion will help train and educate new developers. You never know how many eyes are watching the conversation; even if most people don't participate, many may be tracking silently, gleaning information about the software.
- The discussion will train you in the art of explaining technical issues to people who are not as familiar with the software as you are. This is a skill that requires practice, and you can't get that practice by talking to people who already know what you know.
- The discussion and its conclusions will be available in public archives forever after, enabling future discussions to avoid retracing the same steps. See the section called "Conspicuous Use of Archives" in Chapter 6, Communications.
Finally, there is the possibility that someone on the list may make a real contribution to the conversation, by coming up with an idea you never anticipated. It's hard to say how likely this is; it just depends on the complexity of the code and degree of specialization required. But if anecdotal evidence may be permitted, I would hazard that this is more likely than one would intuitively expect. In the Subversion project, we (the founders) believed we faced a deep and complex set of problems, which we had been thinking about hard for several months, and we frankly doubted that anyone on the newly created mailing list was likely to make a real contribution to the discussion. So we took the lazy route and started batting some technical ideas back and forth in private e-mails, until an observer of the project[10] caught wind of what was happening and asked for the discussion to be moved to the public list. Rolling our eyes a bit, we did-and were stunned by the number of insightful comments and suggestions that quickly resulted. In many cases people offered ideas that had never even occurred to us. It turned out there were some very smart people on that list; they'd just been waiting for the right bait. It's true that the ensuing discussions took longer than they would have if we had kept the conversation private, but they were so much more productive that it was well worth the extra time.
Without descending into hand-waving generalizations like " the group is always smarter than the individual " (we've all met enough groups to know better), it must be acknowledged that there are certain activities at which groups excel. Massive peer review is one of them; generating large numbers of ideas quickly is another. The quality of the ideas depends on the quality of the thinking that went into them, of course, but you won't know what kinds of thinkers are out there until you stimulate them with a challenging problem.
Naturally, there are some discussions that must be had privately; throughout this book we'll see examples of those. But the guiding principle should always be: If there's no reason for it to be private, it should be public.
Making this happen requires action. It's not enough merely to ensure that all your own posts go to the public list. You also have to nudge other people's unnecessarily private conversations to the list too. If someone tries to start a private discussion, and there's no reason for it to be private, then it is incumbent on you to open the appropriate meta-discussion immediately. Don't even comment on the original topic until you've either successfully steered the conversation to a public place, or ascertained that privacy really was needed. If you do this consistently, people will catch on pretty quickly and start to use the public forums by default.
[modifier] Evitez les discussions privées
Même une fois le projet ouvert au public, vous et les autres fondateurs serez tentés de régler les problèmes délicats par des discussions privées au sein d'un cercle fermé. C'est particulièrement vrai dans les premiers jours, quand il y a tant de décisions importantes à prendre et, généralement, peu de volontaires qualifiés pour le faire. Tous les inconvénients des discussions publiques vous apparaîtront de manière palpable : le délai inhérent aux discussions par e-mail, le besoin de laisser suffisamment de temps à un consensus de se former, le tracas d'avoir affaire aux volontaires naïfs qui pensent saisir les tenants et les aboutissants alors que ce n'est pas le cas (tout projet a cette catégorie de volontaires, ils pourront très bien devenir les membres les plus actifs l'année suivante, tout comme ils peuvent aussi rester naïfs pour toujours), l'ennui d'avoir affaire à la personne qui ne comprend pas pourquoi vous voulez résoudre juste le problème X alors qu'il fait partie de manière évidente d'un plus grand problème Y et ainsi de suite. La tentation de prendre les décisions en petit comité et de les présenter comme des faits accomplis, ou au moins comme les recommandations d'une grande partie soudée et influente des votants, sera grande effectivement.
Ne le faites pas.
Aussi encombrantes et lentes qu'elles puissent être, les discussions publiques seront presque toujours préférables sur le long terme. Prendre les décisions importantes en privé reviendrait à pulvériser du repousse bénévoles sur le projet. Aucun volontaire sérieux ne resterait longtemps dans un environnement où toutes les grandes décisions sont prises par un conseil privé. De plus, les discussions publiques ont des effets secondaires positifs qui perdureront bien après l'éphémère question technique débattue :
- La discussion aidera à entraîner et éduquer les nouveaux développeurs. Vous ne savez jamais combien de paires d'yeux suivent une conversation, même si la plupart ne participent pas, ils peuvent être nombreux à la suivre en silence, glanant des informations sur le logiciel.
- La discussion vous entraînera dans l'art d'expliquer les problèmes techniques aux gens qui ne sont pas aussi familiers que vous avec le logiciel. C'est une compétence qui demande de la pratique, pratique que vous ne pouvez pas acquérir en parlant avec des gens qui savent déjà ce que vous savez.
- La discussion et ses conclusions seront accessibles dans des archives publiques en permanence ensuite, permettant aux discussions futures d'éviter de tourner en rond. Voir la section « Utilisation efficace des archives » dans le Chapitre 6, Communication.
Finalement, il se peut que quelqu'un dans la liste apporte une vraie contribution à la discussion, en proposant une idée à laquelle vous n'auriez pas pensé. La probabilité que ça arrive est difficile à déterminer, ça dépend simplement de la complexité du code et du degré de spécialisation requis. Mais s'il m'est accordé de fournir une preuve anecdotique, je me risquerais à dire que c'est plus probable que ce que vous pourriez penser. Dans le projet Subversion, nous (les fondateurs) pensions que nous faisions face à un ensemble de problèmes graves et complexes auxquels nous réfléchissions beaucoup depuis quelques mois. Nous doutions franchement qu'un membre de la nouvelle liste de diffusion puisse apporter une vraie contribution à la discussion. Alors nous avons employé la manière simple et nous avons commencer à débattre d'idées techniques par e-mails privés, jusqu'à ce que quelqu'un qui observait le projet[10] ait eu vent de ce qui se passait et ait demandé à ce que la discussion soit partagée dans la liste publique. Nous l'avons fait, un peu mécontents, et nous avons été surpris par le nombre de commentaires inspirés et de suggestions qui en ont rapidement résultés. Dans beaucoup de cas les gens proposaient des idées qui ne nous étaient encore jamais venues à l'esprit. En fin de compte il y avait des gens très malins sur cette liste, ils attendaient simplement qu'on leur tende la main. J'avoue que les discussions qui ont suivi ont pris plus de temps qu'elles ne l'auraient fait si nous avions gardé cette conversation privée, mais elles étaient tellement plus productives que ça n'était pas du temps perdu, loin s'en faut.
Sans tomber dans les généralisations faciles comme « le groupe est toujours plus fort que l'individu » (nous avons tous connus suffisamment de groupes pour savoir que ça n'est pas forcément vrai), il faut reconnaître qu'ils y a certains domaines dans lesquels le groupe excelle. Une inspection à grande échelle par nos confrères en fait partie, générer un grand nombre d'idées rapidement également. La qualité des idées dépend de la qualité de la réflexion qu'ils ont menée, bien sûr, mais vous ne pourrez jamais jauger le niveau de vos collaborateurs si vous ne leur soumettez pas un problème difficile.
Évidemment, certaines discussions doivent être privées, nous en verrons des exemples tout au long du livre. Mais le principe directeur devrait toujours être : s'il n'y a pas de raison qu'elle soit privée alors elle devrait être publique.
Rendre cela possible demandera des efforts. Ce n'est pas suffisant de simplement s'assurer que tous vos billets passent par la liste publique. Vous devez aussi faire en sorte que les discussions d'autres personnes qui n'ont pas de raison d'être privées figurent également sur la liste publique. Si quelqu'un tente de commencer une conversation privée, sans raison de confidentialité particulière, il vous incombe alors de rendre public l'embryon de discussion au plus tôt. Ne faites pas de commentaires sur le sujet d'origine avant d'avoir réussi à le diriger vers un endroit public ou de vous être assuré que la confidentialité était requise. Si vous insistez, les gens comprendront rapidement et commenceront à utiliser les forums publics naturellement.
[modifier] Nip Rudeness in the Bud
From the very start of your project's public existence, you should maintain a zero-tolerance policy toward rude or insulting behavior in its forums. Zero-tolerance does not mean technical enforcement per se. You don't have to remove people from the mailing list when they flame another subscriber, or take away their commit access because they made derogatory comments. (In theory, you might eventually have to resort to such actions, but only after all other avenues have failed-which, by definition, isn't the case at the start of the project.) Zero-tolerance simply means never letting bad behavior slide by unnoticed. For example, when someone posts a technical comment mixed together with an ad hominem attack on some other developer in the project, it is imperative that your response address the ad hominem attack first, as a separate issue unto itself, and only afterward move on to the technical content.
It is unfortunately very easy, and all too typical, for constructive discussions to lapse into destructive flame wars. People will say things in e-mail that they would never say face-to-face. The topics of discussion only amplify this effect: in technical issues, people often feel there is a single right answer to most questions, and that disagreement with that answer can only be explained by ignorance or stupidity. It's a short distance from calling someone's technical proposal stupid to calling the person themselves stupid. In fact, it's often hard to tell where technical debate leaves off and character attack begins, which is one reason why drastic responses or punishments are not a good idea. Instead, when you think you see it happening, make a post that stresses the importance of keeping the discussion friendly, without accusing anyone of being deliberately poisonous. Such " Nice Police " posts do have an unfortunate tendency to sound like a kindergarten teacher lecturing a class on good behavior:
First, let's please cut down on the (potentially) ad hominem comments; for example, calling J's design for the security layer " naive and ignorant of the basic principles of computer security. " That may be true or it may not, but in either case it's no way to have the discussion. J made his proposal in good faith. If it has deficiencies, point them out, and we'll fix them or get a new design. I'm sure M meant no personal insult to J, but the phrasing was unfortunate, and we try to keep things constructive around here.
Now, on to the proposal. I think M was right in saying that...
As stilted as such responses sound, they have a noticeable effect. If you consistently call out bad behavior, but don't demand an apology or acknowledgment from the offending party, then you leave people free to cool down and show their better side by behaving more decorously next time-and they will. One of the secrets of doing this successfully is to never make the meta-discussion the main topic. It should always be an aside, a brief preface to the main portion of your response. Point out in passing that " we don't do things that way around here, " but then move on to the real content, so that you're giving people something on-topic to respond to. If someone protests that they didn't deserve your rebuke, simply refuse to be drawn into an argument about it. Either don't respond (if you think they're just letting off steam and don't require a response), or say you're sorry if you overreacted and that it's hard to detect nuance in e-mail, then get back to the main topic. Never, ever insist on an acknowledgment, whether public or private, from someone that they behaved inappropriately. If they choose of their own volition to post an apology, that's great, but demanding that they do so will only cause resentment.
The overall goal is to make good etiquette be seen as one of the " in-group " behaviors. This helps the project, because developers can be driven away (even from projects they like and want to support) by flame wars. You may not even know that they were driven away; someone might lurk on the mailing list, see that it takes a thick skin to participate in the project, and decide against getting involved at all. Keeping forums friendly is a long-term survival strategy, and it's easier to do when the project is still small. Once it's part of the culture, you won't have to be the only person promoting it. It will be maintained by everyone.[modifier] Tuez la vulgarité dans l'oeuf
Dès le début de votre projet vous devriez maintenir une politique de tolérance zéro contre les comportements grossiers et insultants au sein des forums. La tolérance zéro ne signifie pas l'emploi des grands moyens. Vous n'êtes pas censé bannir des personnes des listes de diffusion parce qu'elles s'en sont prises à un autre membre, ni leur retirer leur accès de commit parce qu'ils ont fait des commentaires désobligeants (En théorie vous serez peut-être amené à vous y résoudre, mais seulement après avoir épuisé toutes les autres solutions, ce qui par nature n'est pas le cas au début du projet). Montrer une tolérance nulle signifie simplement ne jamais fermer les yeux sur un mauvais comportement. Par exemple, quand quelqu'un publie un commentaire technique mêlé à une attaque ad hominem contre un autre développeur travaillant sur le projet, vous devez en premier lieu répondre à l'attaque ad hominem comme à un problème différent et seulement ensuite revenir au contenu technique du message.
Il est malheureusement très facile, et bien trop courant, que des discussions constructives sombrent en batailles rangées. Les gens peuvent dire par e-mail des choses qu'ils n'oseraient jamais dire en face. Le sujet de discussion amplifie ce fait : pour les problèmes techniques, les gens pensent souvent qu'il n'y a qu'une seule bonne solution à la plupart des questions et qu'un avis divergent ne peut être expliqué que par l'ignorance ou la stupidité. Il n'y a qu'un pas entre dire que la proposition d'une personne est stupide et traiter la personne elle même d'idiot. En fait la frontière entre débat technique et attaque personnelle est souvent difficile à discerner. C'est l'une des raisons pour lesquelles les mesures drastiques ou les punitions ne sont pas une bonne idée. Quand vous pensez être témoin de ceci, faites plutôt une réponse qui souligne l'importance de conserver un ton amical dans les discussions, sans accuser personne d'avoir été délibérément un fauteur de troubles. Ces réponses très « policier sympa » ont une malheureuse tendance à ressembler à un cours sur les bonnes manières donné par un maître de maternelle :
En premier, occupons nous ,si vous le voulez bien, des commentaires potentiellement ad hominem ; par exemple, dire que le modèle de J pour la couche de sécurité est « naïf et ignorant des principes de base de la sécurité informatique » n'est en aucun cas une manière d'en débattre, que cela soit vrai ou pas. J a fait sa proposition en toute bonne foi. Si elle a présente des inconvénients, indiquez les et on les corrigera ou on décidera de pencher pour une autre solution. Je suis sûr que ce n'était pas l'intention de M d'insulter personnellement J, mais les mots étaient mal choisis et on essaie de garder les discussions constructives ici.
En ce qui concerne la proposition. Je pense que M a raison lorsqu'il dit que...
Bien que ce genre de réponses semblent artificiellement formelles, elles ont un effet visible. Si vous montrez du doigt les mauvais comportements sans cesse, sans demander d'excuses ou la reconnaissance de sa faute par la personne ayant été offensante vous laissez les gens se calmer doucement et montrer un meilleur visage la prochaine fois en se comportant de manière plus courtoise et ils le feront. Un des secrets pour que cette technique soit payante est de ne jamais laisser le hors sujet devenir la discussion principale. Ça doit rester une parenthèse, comme une courte préface au corps de votre réponse. Indiquez en passant que les choses ne se déroulent pas ainsi par ici mais ensuite passez au vrai sujet, afin de donner aux autres matière à répondre et de recentrer le débat. Si quelqu'un pense ne pas avoir mérité votre reproche et conteste, refusez simplement d'être attiré dans une dispute à ce propos. Vous pouvez ne pas répondre (si vous estimez qu'il se défoule simplement et que ça n'appelle pas une réponse) ou dire que vous êtes désolé si vous avez réagi excessivement et qu'il est difficile de détecter les nuances par e-mail, ensuite revenez en au sujet principal. N'insistez surtout jamais pour qu'une personne qui s'est mal conduite reconnaisse ses torts, que ce soit publiquement ou en privé. S'ils décident de leur propre chef de faire un message d'excuse c'est très bien, mais leur demander de le faire apportera uniquement de la rancœur.
Le but final est que les gens voient l'usage des bonnes manières comme un comportement du « groupe ». C'est important pour le projet puisque les développeurs peuvent être découragés (même dans un projet qu'ils aiment et veulent soutenir) par des guerres d'insultes. Ça pourrait même arriver sans que vous ne vous en rendiez compte, quelqu'un pourrait jeter un œil aux discussions, voir qu'il faut la peau dure pour participer à ce projet et décide finalement de ne pas s'impliquer. Maintenir les forums accueillants est une stratégie de survie à long terme et c'est plus simple à réaliser quand le projet est encore petit. Une fois que ça sera entré dans les mœurs vous ne serez plus le seul à insister sur la politesse, tout le monde le fera.[modifier] Practice Conspicuous Code Review
One of the best ways to foster a productive development community is to get people looking at each others' code. Some technical infrastructure is required to do this effectively-in particular, commit e-mails must be turned on; see the section called "Commit e-mails" for more details. The effect of commit e-mails is that every time someone commits a change to the source code, an e-mail goes out showing the log message and diffs for the change (see diff, in the section called "Version Control Vocabulary"). Code review is the practice of reviewing commit e-mails as they come in, looking for bugs and possible improvements.[11]
Code review serves several purposes simultaneously. It's the most obvious example of peer review in the Open Source world, and directly helps to maintain software quality. Every bug that ships in a piece of software got there by being committed and not detected; therefore, the more eyes watch commits, the fewer bugs will ship. But code review also serves an indirect purpose: it confirms to people that what they do matters, because one obviously wouldn't take time to review a commit unless one cared about its effect. People do their best work when they know that others will take the time to evaluate it.
Reviews should be public. Even on occasions when I have been sitting in the same physical room with developers, and one of us has made a commit, we take care not to do the review verbally in the room, but to send it to the development mailing list instead. Everyone benefits from seeing the review happen. People follow the commentary and sometimes find flaws in it, and even when they don't, it still reminds them that review is an expected, regular activity, like washing the dishes or mowing the lawn.
In the Subversion project, we did not at first make a regular practice of code review. There was no guarantee that every commit would be reviewed, though one might sometimes look over a change if one was particularly interested in that area of the code. Bugs slipped in that really could and should have been caught. A developer named Greg Stein, who knew the value of code review from past work, decided that he was going to set an example by reviewing every line of every single commit that went into the code repository. Each commit anyone made was soon followed by an e-mail to the developer's list from Greg, dissecting the commit, analyzing possible problems, and occasionally praising a clever bit of code. Right away, he was catching bugs and non-optimal coding practices that would otherwise have slipped by without ever being noticed. Pointedly, he never complained about being the only person reviewing every commit, even though it took a fair amount of his time, but he did sing the praises of code review whenever he had the chance. Pretty soon, other people, myself included, started reviewing commits regularly too. What was our motivation? It wasn't that Greg had consciously shamed us into it. But he had proven that reviewing code was a valuable way to spend time, and that one could contribute as much to the project by reviewing others' changes as by writing new code. Once he demonstrated that, it became expected behavior, to the point where any commit that didn't get some reaction would cause the committer to worry, and even ask on the list whether anyone had had a chance to review it yet. Later, Greg got a job that didn't leave him as much time for Subversion, and had to stop doing regular reviews. But by then, the habit was so ingrained for the rest of us as to seem that it had been going on since time immemorial.
Start doing reviews from very first commit. The sorts of problems that are easiest to catch by reviewing diffs are security vulnerabilities, memory leaks, insufficient comments or API documentation, off-by-one errors, caller/callee discipline mismatches, and other problems that require a minimum of surrounding context to spot. However, even larger-scale issues such as failure to abstract repeated patterns to a single location become spottable after one has been doing reviews regularly, because the memory of past diffs informs the review of present diffs.
Don't worry that you might not find anything to comment on, or that you don't know enough about every area of the code. There will usually be something to say about almost every commit; even where you don't find anything to question, you may find something to praise. The important thing is to make it clear to every committer that what they do is seen and understood. Of course, code review does not absolve programmers of the responsibility to review and test their changes before committing; no one should depend on code review to catch things he ought to have caught on his own.[modifier] Effectuez une inspection visible du code
L'un des meilleurs moyens de motiver une communauté de développement productive est d'amener les gens à regarder le code des autres. Une certaine infrastructure technique est requise pour le faire efficacement, en particulier les e-mails de commit doivent être activés, voir la section « E-mails de commit » pour plus de détails. Chaque fois que quelqu'un modifie le code source, l'effet de l'e-mail de commit est qu'un e-mail est envoyé montrant le journal et les diffs concernant les changements (voir diff dans la section nommée « Vocabulaire de la gestion de configuration logicielle »). L'inspection du code consiste à étudier les e-mails de commit à mesure qu'ils arrivent, à chercher des bogues et les améliorations possibles. [11]
L'inspection du code a plusieurs utilités. C'est l'exemple le plus probant de critique par les pairs dans le monde de l'Open Source et aide directement à maintenir la qualité du logiciel. Tout bogue qui se retrouve dans une partie du logiciel a été créé mais pas détecté, donc plus il y a d'yeux qui surveillent les commits moins il y a de bogues qui passe au travers des mailles du filet. Mais l'inspection du code est utile indirectement également : ça confirme aux gens que ce qu'ils font compte, en effet personne ne prendrait le temps d'inspecter un commit à moins qu'il n'accorde de l'importance à ces effets. Les gens donnent leur meilleur quand il savent que d'autres personnes prendront le temps d'évaluer leur travail.
Les inspections devraient être publiques. Même lorsque j'ai pu être dans la même salle que le développeurs et que l'un de nous avait apporté une contribution nous n'en avons pas fait la critique verbalement dans la salle mais l'avons envoyée à la liste de diffusion des développeurs à la place. C'est dans l'intérêt de chacun de voir que la critique a été faite. Les gens s'intéressent aux commentaires et parfois y trouvent des défauts et même s'ils ne le font pas ça leur rappelle que la critique est attendue, une activité régulière comme faire la vaisselle ou tondre le gazon.
Dans le projet Subversion, nous n'avons pas fait au départ l'exercice d'inspection régulière du code. Nous n'avions aucune garantie que tous les commits seraient revus, bien que quelqu'un puisse de temps en temps regarder un changement s'il est particulièrement intéressé par cette partie du code. Des bogues nous ont échappés qui auraient vraiment pu et auraient dû être vus. Un développeur, du nom de Greg Stein, qui connaissait l'importance de l'inspection du code par ses expériences passées, a décidé de montrer l'exemple en inspectant chaque ligne de chaque commit destiné au dépôt. Tout commit que quelqu'un faisait était rapidement suivi par un e-mail envoyé à la liste des développeurs par Greg, disséquant le commit, analysant les problèmes possibles et parfois faisant l'éloge d'un morceau de code bien écrit. Il détectait tout de suite les bogues et les habitudes non optimales d'écriture de code qui nous auraient autrement échappés. Évidemment il ne s'est jamais plaint d'être le seul à inspecter absolument tous les commits, même si ça lui prenait une grande partie de son temps, mais il faisait l'éloge de l'inspection de code à chaque fois qu'il en avait l'occasion. Rapidement, d'autres personnes, y compris moi-même, ont commencé à inspecter les commits de façon régulière aussi. Quelle était notre motivation ? Ce n'est pas Greg qui nous a fait nous sentir honteux de ne pas le faire. Mais il avait prouvé que passer du temps à inspecter le code est payant et que quelqu'un peut apporter autant au projet en examinant les modifications des autres qu'en écrivant de nouvelles lignes de code. Une fois qu'il avait démontré ce fait c'est devenu la norme, à tel point que lorsqu'un commit ne recevait pas de commentaires la personne à son origine s'inquiétait et demandait même sur la liste si quelqu'un avait eu l'occasion de le contrôler. Plus tard Greg a trouvé un emploi qui ne lui laissait plus autant de temps pour Subversion et a dû arrêter de faire des inspections régulières. Mais à ce moment là, l'habitude était tellement ancrée qu'on aurait dit qu'on le faisait depuis toujours.
Commencez les examens dès le tout premier commit. Le type de problèmes qui sont plus simples à détecter en fouillant les diffs sont les vulnérabilités de sécurité, les fuites de mémoire, les commentaires ou la documentation API insuffisants, les erreurs de logique, les incohérences de discipline appelant/appelé et d'autres problèmes qui nécessitent peu de contexte pour être détectés. Néanmoins, même des problèmes à plus grande échelle, comme l'incapacité à réduire des schémas répétés à une seule position deviennent détectables une fois que la personne fait des inspections régulièrement, parce que se souvenir des diffs antérieurs aide à l'inspection des diffs plus récents.
Ne vous inquiétez pas si vous ne trouvez rien à commenter ou si vous n'êtes pas assez renseigné sur toutes les parties du code. Il y aura presque toujours quelque chose à dire à propos de chaque commit, même si vous ne trouvez rien à redire vous aurez peut-être un commentaire élogieux à faire. Le plus important est de montrer à ceux qui envoient les commits que ce qu'ils font est vus et compris. Évidemment, l'inspection du code ne dispense pas les programmeurs de la responsabilité de contrôler et tester leurs changements avant de les exposer, personne ne devrait se reposer sur l'inspection du code pour trouver les erreurs qu'il aurait dû voir lui même.[modifier] When Opening a Formerly Closed Project, be Sensitive to the Magnitude of the Change
If you're opening up an existing project, one that already has active developers accustomed to working in a closed-source environment, make sure everyone understands that a big change is coming-and make sure that you understand how it's going to feel from their point of view.
Try to imagine how the situation looks to them: formerly, all code and design decisions were made with a group of other programmers who knew the software more or less equally well, who all received the same pressures from the same management, and who all know each others' strengths and weaknesses. Now you're asking them to expose their code to the scrutiny of random strangers, who will form judgements based only on the code, with no awareness of what business pressures may have forced certain decisions. These strangers will ask lots of questions, questions that jolt the existing developers into realizing that the documentation they slaved so hard over is still inadequate (this is inevitable). To top it all off, the newcomers are unknown, faceless entities. If one of your developers already feels insecure about his skills, imagine how that will be exacerbated when newcomers point out flaws in code he wrote, and worse, do so in front of his colleagues. Unless you have a team of perfect coders, this is unavoidable-in fact, it will probably happen to all of them at first. This is not because they're bad programmers; it's just that any program above a certain size has bugs, and peer review will spot some of those bugs (see the section called "Practice Conspicuous Code Review" earlier in this chapter). At the same time, the newcomers themselves won't be subject to much peer review at first, since they can't contribute code until they're more familiar with the project. To your developers, it may feel like all the criticism is incoming, never outgoing. Thus, there is the danger of a siege mentality taking hold among the old hands.
The best way to prevent this is to warn everyone about what's coming, explain it, tell them that the initial discomfort is perfectly normal, and reassure them that it's going to get better. Some of these warnings should take place privately, before the project is opened. But you may also find it helpful to remind people on the public lists that this is a new way of development for the project, and that it will take some time to adjust. The very best thing you can do is lead by example. If you don't see your developers answering enough newbie questions, then just telling them to answer more isn't going to help. They may not have a good sense of what warrants a response and what doesn't yet, or it could be that they don't have a feel for how to prioritize coding work against the new burden of external communications. The way to get them to participate is to participate yourself. Be on the public mailing lists, and make sure to answer some questions there. When you don't have the expertise to field a question, then visibly hand it off to a developer who does-and watch to make sure he follows up with an answer, or at least a response. It will naturally be tempting for the longtime developers to lapse into private discussions, since that's what they're used to. Make sure you're subscribed to the internal mailing lists on which this might happen, so you can ask that such discussions be moved to the public lists right away.
There are other, longer-term concerns with opening up formerly closed projects. Chapter 4, Social and Political Infrastructure explores techniques for mixing paid and unpaid developers successfully, and Chapter 9, Licenses, Copyrights, and Patents discusses the necessity of legal diligence when opening up a private code base that may contain software written or " owned " by other parties.[modifier] Soyez attentifs à l'amplitude des changements lorsque vous libérez un projet fermé
Si vous libérez un projet déjà existant, sur lequel les développeurs sont habitués à travailler dans un environnement fermé, assurez vous que tout le monde comprenne qu'un grand changement se profile, essayez de vous mettre à leur place pour comprendre leurs sentiments.
Essayez d'imaginer la situation de leur point de vue : avant, toutes les décisions concernant le code et l'architecture étaient prises au sein d'un groupe où tous les programmeurs connaissaient à peu près aussi bien le logiciel, programmeurs qui étaient sous la même pression du même encadrement et qui connaissaient les forces et les faiblesses de chacun. Maintenant vous leur demandez d'exposer le code au regard d'étrangers qui se feront un jugement uniquement d'après ce qu'ils voient, sans connaître les pressions commerciales derrière telle ou telle décision. Ces étrangers poseront beaucoup de questions, des questions qui seront comme un choc pour les développeurs déjà présents qui réaliseront que la documentation sur laquelle ils se sont échinés est encore inadaptée (c'est inévitable). Plus important encore, les nouveaux venus sont des inconnus, des entités sans visage. Si l'un de vos développeurs a déjà des doutes quant à ses compétences, imaginez comment se sentiment sera exacerbé quand des nouveaux venus montreront du doigt des défauts du code qu'il a écrit, et pire encore, devant tous ses collègues. A moins que votre équipe soit composée de codeurs parfaits c'est inévitable, en fait, ça leur arrivera à tous au début. Ce n'est pas parce qu'ils sont de mauvais programmeurs, c'est juste que n'importe quel programme ayant atteint une certaine taille contient des bogues et la critique par des pairs mettra en avant certains de ces bogues (voir la section appelée « Effectuez une inspection visible du code », précédemment dans ce chapitre). A ce moment, les nouveaux venus ne seront pas exposés à la critique des pairs eux, comme ils ne peuvent pas participer à la programmation tant qu'ils ne sont pas familiers avec le projet. Vos développeurs auront l'impression que la critique ne va que dans un sens. Il y a donc un risque qu'une mentalité d'assiégé se développe au sein des « anciens ».
Le meilleur moyen d'éviter ceci est de prévenir tout le monde de ce qui les attend, expliquez, dites leur que l'inconfort du début est parfaitement normal et assurez les que les choses iront en s'améliorant. Certains de ces avertissements devraient être faits en privé, avant que le projet ne soit ouvert. Mais vous pourrez aussi trouver utile de rappeler aux gens sur les listes publiques que c'est une nouvelle phase du développement du projet et qu'il y aura un certain temps d'adaptation. La meilleure chose que vous puissiez faire est de donner l'exemple. Demandez aux développeurs de répondre plus, si vous vous rendez compte qu'ils ne le font pas suffisamment, aux questions de débutants n'améliorera pas les choses. Ils n'ont pas forcément déjà une idée claire des questions qui requièrent une réponse ou pas ou il se peut qu'ils ne sachent pas comment répartir leur temps entre le travail de programmation et leur nouvelle charge de communication externe. Afin de les faire participer il faut que vous participiez vous même. Soyez présent sur les listes de diffusion publiques et répondez à quelques questions posées par ce biais. Si vous n'avez pas la connaissance requise pour répondre à une question alors transmettez là à un développeur qui saura y répondre et ce de manière visible à tous. Assurez vous qu'il fournisse une solution, ou qu'au moins il réponde. Il sera tentant pour les développeurs qui ont participé de longue date de retomber dans des discussions privées, c'est naturel comme c'est ce à quoi ils sont habitués. Assurez vous de faire partie de la liste de diffusion interne sur laquelle cela peut se passer, ainsi vous pouvez demander à ce que ce genre de discussion soit déplacé sur les listes publiques immédiatement.
Il y a d'autre préoccupations sur le long terme lorsque vous rendez public un projet précédemment fermé. Le Chapitre 4, Infrastructure sociale et politique explore des techniques pour faire cohabiter avec succès des développeurs salariés et bénévoles et le Chapitre 9, Licences, droits d'auteur et brevets traite de l'attention légale que vous devez porter lorsque vous rendez libre un code propriétaire qui pourrait contenir des logiciels écrits ou « détenu » par d'autres parties
