POSS Chap 8 Part 5
Un article de Framalang Wiki.
[modifier] 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.
[modifier] 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.
