POSS Chap 5 Part 2
Un article de Framalang Wiki.
[modifier] Hire for the Long Term / Engagez pour le long terme
If you're managing programmers on an Open Source project, keep them there long enough that they acquire both technical and political expertise—a couple of years, at a minimum. Of course, no project, whether open or closed-source, benefits from swapping programmers in and out too often. The need for a newcomer to learn the ropes each time would be a deterrent in any environment. But the penalty is even stronger in Open Source projects, because outgoing developers take with them not only their knowledge of the code, but also their status in the community and the human relationships they have made there.
Si vous dirigez des programmeurs dans un projet Open Source, gardez les suffisamment longtemps afin qu'ils puissent acquérir à la fois l'expertise technique et politique nécessaires, deux ans au minimum. Évidemment, aucun projet, que ce soit en open ou en closed-source, ne bénéficie d'une rotation rapide des programmeurs. Le besoin pour un nouvel arrivant d'apprendre les ficelles à chaque fois serait une barrière trop importante dans n'importe quel environnement. Mais le handicape est encore plus fort pour les projets Open Source puisque les développeurs sortants emmènent avec eux non seulement leur connaissance du code, mais aussi leur statut dans la communauté et les relations humaines qu'ils avaient tissées.
The credibility a developer has accumulated cannot be transferred. To pick the most obvious example, an incoming developer can't inherit commit access from an outgoing one (see the section called “Money Can't Buy You Love” later in this chapter), so if the new developer doesn't already have commit access, he will have to submit patches until he does. But commit access is only the most measurable manifestation of lost influence. A long-time developer also knows all the old arguments that have been hashed and rehashed on the discussion lists. A new developer, having no memory of those conversations, may try to raise the topics again, leading to a loss of credibility for your organization; the others might wonder "Can't they remember anything?" A new developer will also have no political feel for the project's personalities, and will not be able to influence development directions as quickly or as smoothly as one who's been around a long time.
La crédibilité qu'un développeur a acquise ne peut être transférée. Pour prendre l'exemple le plus évident, un nouveau développeur ne peut pas hériter de l'accès de commit du développeur sortant (voir la section « L'argent ne fait pas tout » plus loin dans ce chapitre), donc si le nouveau développeur n'a pas déjà l'accès de commit il devra proposer des correctifs jusqu'à ce qu'il l'obtienne. Mais l'accès de commit n'est que la manifestation la plus visible de la perte d'influence. Un développeur de longue date connaît toutes les discussions qui ont été battues et re-battues sur les listes de discussion. Un nouveau développeur, ne connaissant pas toutes ces conversations, pourrait tenter de soulever le problème encore une fois, ce qui mènera à une perte de crédibilité pour votre organisation, les autres pourront se demander « Ils ne peuvent donc pas se souvenir ? » Un nouveau développeur ne connaîtra pas la hiérarchie interne du projet et ne sera pas capable d'influencer l'orientation du projet aussi rapidement et souplement que quelqu'un présent depuis longtemps.
Train newcomers through a program of supervised engagement. The new developer should be in direct contact with the public development community from the very first day, starting off with bug fixes and cleanup tasks, so he can learn the code base and acquire a reputation in the community, yet not spark any long and involved design discussions. All the while, one or more experienced developers should be available for questioning, and should be reading every post the newcomer makes to the development lists, even if they're in threads that the experienced developers normally wouldn't pay attention to. This will help the group spot potential rocks before the newcomer runs aground. Private, behind-the-scenes encouragement and pointers can also help a lot, especially if the newcomer is not accustomed to massively parallel peer review of his code.
Entraînez les nouveaux venus au travers d'un programme de formation supervisé. Le nouveau développeur devrait être en contact direct avec la communauté de développement public dès le départ, en commençant avec des corrections de bogues et des tâches de nettoyage afin qu'il puisse apprendre les bases du code et se faire une réputation dans la communauté, mais ne commencez pas encore de longues discussions engagées sur la conception. Tout au long du processus un développeur expérimenté, ou plusieurs, devrait être disponible pour répondre aux questions et devrait lire toutes les contributions que le nouveau venu fait à la liste de développement, même si elles sont dans des discussions que le développeur expérimenté ne suit pas en général. Cela aidera le groupe à repérer les récifs potentiels avant que le nouveau venu ne s'échoue. Des encouragements et des indications privés peuvent aussi être d'une grande aide, particulièrement si le nouveau venu n'est pas habitué à une inspection importante de son code par ses pairs.
When CollabNet hires a new developer to work on Subversion, we sit down together and pick some open bugs for the new person to cut his teeth on. We'll discuss the technical outlines of the solutions, and then assign at least one experienced developer to (publicly) review the patch that the new developer will (also publicly) post. We typically don't even look at the patch before the main development list sees it, although we could if there were some reason to. The important thing is that the new developer go through the process of public review, learning the code base while simultaneously becoming accustomed to receiving critiques from complete strangers. But we try to coordinate the timing so that our own review comes immediately after the posting of the patch. That way the first review the list sees is ours, which can help set the tone for the others' reviews. It also contributes to the idea that this new person is to be taken seriously: if others see that we're putting in the time to give detailed reviews, with thorough explanations and references into the archives where appropriate, they'll appreciate that a form of training is going on, and that it probably signifies a long-term investment. This can make them more positively disposed toward that developer, at least to the degree of spending a little extra time answering questions and reviewing patches.
Quand CollabNet engage un nouveau développeur pour travailler dans Subversion, nous choisissons quelques bogues pour que le nouveau venu puisse s'y faire les dents. Nous discutons du contour technique des solutions et ensuite nous assignons au moins un développeur expérimenté à la vérification (publique) du correctif que le nouveau développeur publiera (publiquement). En règle générale on ne regarde même pas le correctif avant que la principale liste de développeurs le voit, bien que nous pourrions si nous avions des raisons de le faire. Ce qui est important est que le développeur passe par le processus de révision public, il apprend la base du code en même temps qu'il s'habitue à recevoir des critiques de personnes complètement inconnues. Mais nous essayons de coordonner notre timing afin que nos impressions soient visibles dès la publication du correctif. Ainsi, l'inspection en tête de liste est la notre, ce qui peut aider à donner le ton pour les inspections suivantes. Cela apporte aussi l'idée que cette nouvelle personne doit être prise au sérieux : si les gens voient que nous prenons le temps de faire des commentaires détaillés, avec des explications exhaustives et des références aux archives quand elles sont nécessaires, ils comprendront que la personne est dans une phase de formation qui sera certainement synonyme d'investissement sur le long terme. Cela peut mieux les disposer envers un développeur, au moins en ce qui concerne le temps supplémentaire qu'ils prendront pour répondre aux questions et inspecter les correctifs.
