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