POSS Chap 4 Part 2
Un article de Framalang Wiki.
Sommaire |
[modifier] Consensus-based Democracy
As projects get older, they tend to move away from the benevolent dictatorship model and toward more openly democratic systems. This is not necessarily out of dissatisfaction with a particular BD. It's simply that group-based governance is more "evolutionarily stable", to borrow a biological metaphor. Whenever a benevolent dictator steps down, or attempts to spread decision-making responsibility more evenly, it is an opportunity for the group to settle on a new, non-dictatorial system—establish a constitution, as it were. The group may not take this opportunity the first time, or the second, but eventually they will; once they do, the decision is unlikely ever to be reversed. Common sense explains why: if a group of N people were to vest one person with special power, it would mean that N - 1 people were each agreeing to decrease their individual influence. People usually don't want to do that. Even if they did, the resulting dictatorship would still be conditional: the group anointed the BD, clearly the group could depose the BD. Therefore, once a project has moved from leadership by a charismatic individual to a more formal, group-based system, it rarely moves back.
The details of how these systems work vary widely, but there are two common elements: one, the group works by consensus most of the time; two, there is a formal voting mechanism to fall back on when consensus cannot be reached.
Consensus merely means an agreement that everyone is willing to live with. It is not an ambiguous state: a group has reached consensus on a given question when someone proposes that consensus has been reached, and no one contradicts the assertion. The person proposing consensus should, of course, state specifically what the consensus is, and what actions would be taken in consequence of it, if they're not obvious.
Most conversation in a project is on technical topics, such as the right way to fix a certain bug, whether or not to add a feature, how strictly to document interfaces, etc. Consensus-based governance works well because it blends seamlessly with the technical discussion itself. By the end of a discussion, there is often general agreement on what course to take. Someone will usually make a concluding post, which is simultaneously a summary of what has been decided and an implicit proposal of consensus. This provides a last chance for someone else to say "Wait, I didn't agree to that. We need to hash this out some more."
For small, uncontroversial decisions, the proposal of consensus is implicit. For example, when a developer spontaneously commits a bugfix, the commit itself is a proposal of consensus: "I assume we all agree that this bug needs to be fixed, and that this is the way to fix it." Of course, the developer does not actually say that; she just commits the fix, and the others in the project do not bother to state their agreement, because silence is consent. If someone commits a change that turns out not to have consensus, the result is simply for the project to discuss the change as though it had not already been committed. The reason this works is the topic of the next section.____
Démocratie basée sur le consensus
En vieillissant, les projets ont tendance à s'éloigner du modèle du dictateur bienveillant au profit de systèmes plus ouvertement démocratiques. Ce n'est pas forcément par mécontentement à l'égard d'un DB en particulier. C'est simplement parce que la gouvernance basée sur le groupe est plus "évolutionnairement stable" pour emprunter une métaphore à la biologie. Chaque fois que le dictateur bienveillant abdique ou essaie de répartir la responsabilité de la prise de décision de manière plus équilibrée c'est une occasion pour le groupe d'établir un nouveau système non-dictatorial, de fonder une constitution en quelque sorte. Il se peut que le groupe ne saisisse pas cette opportunité la première fois, ni la deuxième, mais il finira par le faire et une fois que ce sera fait il est peu vraisemblable que l'on puisse revenir en arrière. La raison tient du bon sens : si un groupe de N personnes devait investir l'une d'entre elles d'un pouvoir spécial, ceci voudrait dire que N-1 personnes ont accepté de diminuer leur influence personnelle. Or ce n'est généralement pas ce que les gens veulent. S'ils le font, la dictature qui en résulte n'est que conditionnelle : celui que le groupe a sacré DB peut aussi bien être détrôné par ce même groupe. C'est pourquoi une fois que le projet a évolué du leadership d'un individu charismatique vers un système plus formel basé sur le groupe il revient rarement en arrière.
Les détails du fonctionnement de ces systèmes varient considérablement, mais il existe 2 éléments communs : 1) le groupe travaille par consensus la plupart du temps ; 2) il y a un mécanisme formel de vote sur lequel se reposer quand le consensus n'est pas atteint.
"Consensus" veut simplement dire un accord que chacun est prêt à respecter. Il ne s'agit pas d'un état ambigu : le consensus est atteint sur une question donnée lorsque quelqu'un déclare que le consensus est atteint et que personne ne contredit cette affirmation. La personne qui propose le consensus devrait, bien sûr, spécifier en quoi il consiste et quelles actions en découlent, si cela ne va pas de soit.
La plupart des conversations dans un projet portent sur des questions techniques, telles que la meilleure façon de corriger un bogue, l'ajout ou non d'une fonctionnalité, le degré de précision dans la documentation des interfaces, etc. La gouvernance basée sur le consensus fonctionne bien car elle se marie parfaitement à la discussion technique elle-même. A la fin de la discussion, tout le monde s'accorde souvent sur la voie à prendre. Quelqu'un postera généralement une conclusion, qui est en même temps un résumé de ce qui a été décidé et une proposition implicite de consensus. Ce qui offre une dernière chance à chacun de dire : "Attendez, je n'ai pas donné mon accord là-dessus. Il faut encore décortiquer la question."
Pour les décisions mineures n'impliquant pas de controverse, la proposition de consensus est implicite. Par exemple, quand un développeur valide spontanément une correction de bogue, la validation elle-même ("commit") contient une proposition de consensus : "Je suppose que tout le monde est d'accord que ce bogue doit être corrigé et que c'est la bonne façon de le faire." Bien sûr, le développeur ne dit pas réellement ceci, il ne fait que valider la correction et les autres membres du projet ne se donnent pas la peine de manifester leur accord, car qui ne dit mot consent. Si quelqu'un valide une modification qui finalement n'est pas approuvée par tous, le projet engage alors simplement une discussion à propos de cette modification, comme si elle n'avait pas encore été validée. La raison pour laquelle cela fonctionne est l'objet de la prochaine partie.
[modifier] Version Control Means You Can Relax
The fact that the project's source code is kept under version control means that most decisions can be easily unmade. The most common way this happens is that someone commits a change mistakenly thinking everyone would be happy with it, only to be met with objections after the fact. It is typical for such objections to start out with an obligatory apology for having missed out on prior discussion, though this may be omitted if the objector finds no record of such a discussion in the mailing list archives. Either way, there is no reason for the tone of the discussion to be different after the change has been committed than before. Any change can be reverted, at least until dependent changes are introduced (i.e., new code that would break if the original change were suddenly removed). The version control system gives the project a way to undo the effects of bad or hasty judgement. This, in turn, frees people to trust their instincts about how much feedback is necessary before doing something.
This also means that the process of establishing consensus need not be very formal. Most projects handle it by feel. Minor changes can go in with no discussion, or with minimal discussion followed by a few nods of agreement. For more significant changes, especially ones with the potential to destabilize a lot of code, people should wait a day or two before assuming there is consensus, the rationale being that no one should be marginalized in an important conversation simply because he didn't check e-mail frequently enough.
Thus, when someone is confident he knows what needs to be done, he should just go ahead and do it. This applies not only to software fixes, but to Web site updates, documentation changes, and anything else unlikely to be controversial. Usually there will be only a few instances where an action needs to be undone, and these can be handled on a case-by-case basis. Of course, one shouldn't encourage people to be headstrong. There is still a psychological difference between a decision under discussion and one that has already taken effect, even if it is technically reversible. People always feel that momentum is allied to action, and will be slightly more reluctant to revert a change than to prevent it in the first place. If a developer abuses this fact by committing potentially controversial changes too quickly, however, people can and should complain, and hold that developer to a stricter standard until things improve.____
La gestion de version, gage de sérénité
Le fait que le code source du projet est sous gestion de version implique que l'on peut revenir sur la plupart des décisions. Le cas le plus courant est celui où quelqu'un valide malencontreusement un changement en pensant que tout le monde l'appréciera et que son acte ne rencontre que des objections. Il est d'usage après de telles objections de commencer obligatoirement par présenter ses excuses pour avoir manqué les discussions antérieures, bien que cette étape puisse être omise si l'objecteur ne trouve pas trace d'une telle discussion dans les archives de la liste de discussion. Autrement, il n'y a pas de raison pour que le ton de la discussion soit différent après la validation du changement qu'avant. Tout changement est réversible, du moins jusqu'à ce que des changements afférents soient introduits (c'est-à-dire, du code nouveau qui serait cassé si le changement initial était supprimé). Ce logiciel de gestion de version offre au projet le moyen de défaire les effets de mauvais jugements ou de jugements hâtifs. En conséquence, les gens peuvent suivre leur instinct et évaluer le bon moment pour ajouter une modification selon les commentaires reçus.
Ceci veut dire également que le processus pour établir le consensus n'a pas besoin d'être très formel. La plupart des projets le font au feeling. Les changements mineurs passent sans discussion ou avec un minimum de discussions ponctuées de quelques signes d'approbation. Pour les changements plus importants, notamment ceux qui peuvent déstabiliser beaucoup de code, il faudrait attendre un jour ou deux avant d'estimer qu'il y a consensus, le principe étant que personne ne doit être tenu à l'écart d'une conversation importante uniquement parce qu'il n'a pas vérifié son courrier assez fréquemment.
Ainsi, quand quelqu'un est certain qu'il sait ce qu'il faut faire, il devrait simplement se lancer et le faire. Ceci s'applique non seulement aux corrections logicielles, mais également aux mises à jour du site Web, aux changements de la documentation et à tout ce qui a peu de chances de prêter à controverse. Généralement, il y aura peu de circonstances où il faudra défaire une action et elles pourront être traitées au cas par cas. Bien sûr, il ne faut pas encourager les gens à être têtus. Il subsiste toujours une différence psychologique entre une décision à débattre et une décision qui a déjà pris effet, même si elle est techniquement réversible. Les gens associent toujours l'élan à l'action et ils seront plus réticents à défaire un changement qu'à empêcher qu'il ait lieu. Cependant, si un développeur abuse de ce fait en validant des changements potentiellement controversés trop rapidement, les gens sont en droit et en devoir de se plaindre et de lui imposer des règles plus strictes jusqu'à ce que les choses aillent mieux.[modifier] When Consensus Cannot Be Reached, Vote
Inevitably, some debates just won't consense. When all other means of breaking a deadlock fail, the solution is to vote. But before a vote can be taken, there must be a clear set of choices on the ballot. Here, again, the normal process of technical discussion blends serendipitously with the project's decision-making procedures. The kinds of questions that come to a vote often involve complex, multifaceted issues. In any such complex discussion, there are usually one or two people playing the role of honest broker: posting periodic summaries of the various arguments and keeping track of where the core points of disagreement (and agreement) lie. These summaries help everyone measure how much progress has been made, and remind everyone of what issues remain to be addressed. Those same summaries can serve as prototypes for a ballot sheet, should a vote become necessary. If the honest brokers have been doing their job well, they will be able to credibly call for a vote when the time comes, and the group will be willing to use a ballot sheet based on their summary of the issues. The brokers themselves may be participants in the debate; it is not necessary for them to remain above the fray, as long as they can understand and fairly represent others' views, and not let their partisan sentiments prevent them from summarizing the state of the debate in a neutral fashion.
The actual content of the ballot is usually not controversial. By the time matters reach a vote, the disagreement has usually boiled down to a few key issues, with recognizable labels and brief descriptions. Occasionally a developer will object to the form of the ballot itself. Sometimes his concern is legitimate, for example, that an important choice was left off or not described accurately. But other times a developer may be merely trying to stave off the inevitable, perhaps knowing that the vote probably won't go his way. See the section called “Difficult People” in Chapter 6, Communications for how to deal with this sort of obstructionism.
Remember to specify the voting system, as there are many different kinds, and people might make wrong assumptions about which procedure is being used. A good choice in most cases is approval voting, whereby each voter can vote for as many of the choices on the ballot as he likes. Approval voting is simple to explain and to count, and unlike some other methods, it only involves one round of voting. See http://en.wikipedia.org/wiki/Voting_system#List_of_systems for more details about approval voting and other voting systems, but try to avoid getting into a long debate about which voting system to use (because, of course, you will then find yourself in a debate about which voting system to use to decide the voting system!). One reason approval voting is a good choice is that it's very hard for anyone to object to—it's about as fair as a voting system can be.
Finally, conduct votes in public. There is no need for secrecy or anonymity in a vote on matters that have been debated publicly anyway. Have each participant post her votes to the project mailing list, so that any observer can tally and check the results for herself, and so that everything is recorded in the archives.___
Quand le consensus n'est pas possible, votez
Inévitablement, certains débats ne trouveront pas de consensus. Quand tous les autres moyens pour sortir d'une impasse échouent la solution est le vote. Mais avant de procéder au vote, il doit y avoir un ensemble clair de choix en jeu. Ici, de nouveau, le processus normal de la discussion technique se marie étonnamment avec les procédures de prise de décision du projet. Le genre de questions soumises à référendum impliquent souvent des thématiques complexes, aux facettes multiples. Dans ce genre de discussions complexes il y a généralement une ou deux personnes qui remplissent le rôle de médiateurs : ils postent des comptes-rendus réguliers des différents arguments et gardent trace des principaux points d'achoppement (et de ceux où il y a accord). Ces compte-rendus aident tout le monde à mesurer les progrès qui ont été faits et rappellent les questions qui restent à régler. Ces mêmes compte-rendus peuvent servir de prototype au bulletin de vote, au cas où le vote deviendrait nécessaire. Si les médiateurs ont bien fait leur travail, ils seront en mesure d'appeler à voter le moment venu et le groupe sera disposé favorablement à l'utilisation de la feuille de scrutin basée sur leur compte-rendu. Les médiateurs eux-mêmes peuvent participer au débat ; ils ne sont pas obligés de rester au-dessus de la mêlée du moment qu'ils arrivent à comprendre et à représenter avec justesse les points de vue des autres et du moment que leurs sentiments partisans ne les empêchent pas de rendre compte de manière neutre de l'état de la discussion.
Le contenu du bulletin généralement n'est pas controversé. Quand l'affaire en vient au vote, le désaccord s'est déjà réduit à quelques questions clés portant des étiquettes reconnaissables et des descriptions succinctes. Occasionnellement, un développeur fera une objection sur le vote lui-même. Parfois son inquiétude est justifiée, par exemple si une option importante a été omise ou insuffisamment renseignée. Mais d'autres fois un développeur essaiera tout simplement d'éviter l'inévitable, en sachant peut-être que l'issue du vote n'ira pas dans son sens. Voyez la section "Les personnes difficiles" dans le Chapitre 6, Communication pour savoir comment gérer ce genre d'obstructionnisme.
Pensez à préciser le système de vote, étant donné qu'il y en a plusieurs et que les gens pourraient se méprendre sur la procédure qui est en cours. Un bon choix dans la plupart des cas est le vote d'approbation où chaque participant peut voter pour autant de choix sur le bulletin qu'il veut. Le vote d'approbation est simple à expliquer et à compter et, à la différence d'autres méthodes, il compte un seul tour. Voir http://fr.wikipedia.org/wiki/Système_de_vote pour plus de détails sur le vote d'approbation et les autres systèmes de vote, mais évitez de rentrer dans un long débat sur quel système adopter (car, évidemment, vous vous trouverez lancé dans un débat sur le choix du système de vote pour décider du système de vote lui-même !) Une des raisons pour lesquelles le vote d'approbation est un bon choix est qu'il est très difficile d'y opposer des objections, il est aussi juste qu'un système de vote peut l'être.
Enfin, procédez au vote publiquement. Ni le secret, ni l'anonymat se sont requis pour un vote portant sur des questions qui, de toute façon, ont été débattues publiquement. Faites en sorte que chaque participant poste son vote sur la liste de discussion du projet afin que n'importe quel observateur puisse compter et vérifier les résultats par lui-même et que tout soit consigné dans les archives.[modifier] When To Vote
The hardest thing about voting is determining when to do it. In general, taking a vote should be very rare—a last resort for when all other options have failed. Don't think of voting as a great way to resolve debates. It isn't. It ends discussion, and thereby ends creative thinking about the problem. As long as discussion continues, there is the possibility that someone will come up with a new solution everyone likes. This happens surprisingly often: a lively debate can produce a new way of thinking about the problem, and lead to a proposal that eventually satisfies everyone. Even when no new proposal arises, it's still usually better to broker a compromise than to hold a vote. After a compromise, everyone is a little bit unhappy, whereas after a vote, some people are unhappy while others are happy. From a political standpoint, the former sitation is preferable: at least each person can feel he extracted a price for his unhappiness. He may be dissatisfied, but so is everyone else.
Voting's main advantage is that it finally settles a question so everyone can move on. But it settles it by a head count, instead of by rational dialogue leading everyone to the same conclusion. The more experienced people are with Open Source projects, the less eager I find them to be to settle questions by vote. Instead they will try to explore previously unconsidered solutions, or compromise more severely than they'd originally planned. Various techniques are available to prevent a premature vote. The most obvious is simply to say "I don't think we're ready for a vote yet," and explain why not. Another is to ask for an informal (non-binding) show of hands. If the response clearly tends toward one side or another, this will make some people suddenly more willing to compromise, obviating the need for a formal vote. But the most effective way is simply to offer a new solution, or a new viewpoint on an old suggestion, so that people re-engage with the issues instead of merely repeating the same arguments.
In certain rare cases, everyone may agree that all the compromise solutions are worse than any of the non-compromise ones. When that happens, voting is less objectionable, both because it is more likely to lead to a superior solution and because people will not be overly unhappy no matter how it turns out. Even then, the vote should not be rushed. The discussion leading up to a vote is what educates the electorate, so stopping that discussion early can lower the quality of the result.
(Note that this advice to be reluctant to call votes does not apply to the change-inclusion voting described in the section called “Stabilizing a Release” in Chapter 7, Packaging, Releasing, and Daily Development. There, voting is more of a communications mechanism, a means of registering one's involvement in the change review process so that everyone can tell how much review a given change has received.)Le plus difficile en ce qui concerne le vote est de déterminer quand il doit avoir lieu. En règle générale le recours au vote devrait être exceptionnel, en dernier recours quand toutes les autres options ont échoué. Ne voyez pas le vote comme LE moyen génial de clore les débats. Il ne l'est pas. Il met fin à la discussion et par là met fin à la pensée créative sur le problème en question. Tant que la discussion continue la possibilité que quelqu'un présente une nouvelle solution qui plaise à tout le monde subsiste. Etonnamment ceci arrive assez souvent, d'un débat animé peut naître une nouvelle façon d'aborder le problème qui débouche sur une proposition qui finalement satisfait tout le monde. Même quand aucune proposition nouvelle ne surgit, il reste encore préférable de négocier un compromis que de voter. Après un compromis, tout le monde est un peu malheureux, tandis qu'après un vote, certains sont malheureux et d'autres sont heureux. D'un point de vue politique, la première situation est préférable : au moins chacun peut avoir le sentiment d'avoir tiré un prix de son malheur. Ils sont peut-être malheureux, mais les autres le sont aussi.
L'avantage principal du vote est qu'il permet de régler définitivement une question pour que tout le monde puisse aller de l'avant. Mais il règle la question au nombre des voix et non par le dialogue rationnel qui amène tout le monde à la même conclusion. Je trouve que les gens ayant de l'expérience dans les projets Open Source sont moins enclins à régler les questions par le vote. Ils essaieront plutôt d'explorer des solutions qui n'ont pas été examinées précédemment ou feront des compromis plus durs que ce qu'ils avaient initialement prévu.
Il existe plusieurs techniques pour éviter un vote prématuré. La plus évidente consiste simplement à dire : "Je pense que nous ne sommes pas encore prêts pour un vote", en en exposant les raisons. Une autre consiste à demander un vote informel (non contraignant) à main levée. Si l'issue penche nettement en faveur d'une des deux parties, certains seront alors plus enclins à négocier, évitant le recours à un vote formel. Mais la solution la plus efficace consiste à offrir une nouvelle solution ou un nouveau point de vue sur une proposition ancienne pour que les gens se repositionnent sur ces questions au lieu de simplement ressasser leurs arguments.
Dans certains cas exceptionnels tout le monde peut être d'accord sur le fait que toutes les solutions impliquant un compromis sont pires que celles sans compromis. Dans ce cas, le vote devient plus acceptable pour deux raisons : parce que c'est le moyen le plus plausible de parvenir à une meilleure solution et parce que les gens ne seront pas foncièrement malheureux, quelle qu'en soit l'issue. Même alors, le vote ne doit pas être précipité. La discussion qui mène au vote éduque l'électorat ; interrompre cette discussion trop tôt nuirait donc à la qualité du résultat.
(Notez que ce conseil de ne recourir au vote qu'avec réticence ne s'applique pas au vote pour l'inclusion des modifications décrit dans la section "Stabiliser une version" du Chapitre 7, Création de paquets, sorties et développement quotidien. Là, le vote est bien plus un mécanisme de communication, un moyen d'enregistrer l'implication de chacun dans le processus de révision des modifications, pour que chacun puisse évaluer l'attention dont a fait l'objet une modification.)[modifier] Who Votes?
Having a voting system raises the question of electorate: who gets to vote? This has the potential to be a sensitive issue, because it forces the project to officially recognize some people as being more involved, or as having better judgement, than others.
The best solution is to simply take an existing distinction, commit access, and attach voting privileges to it. In projects that offer both full and partial commit access, the question of whether partial committers can vote largely depends on the process by which partial commit access is granted. If the project hands it out liberally, for example as a way of maintaining many third-party contributed tools in the repository, then it should be made clear that partial commit access is really just about committing, not voting. The reverse implication naturally holds as well: since full committers will have voting privileges, they must be chosen not only as programmers, but as members of the electorate. If someone shows disruptive or obstructionist tendencies on the mailing list, the group should be very cautious about making him a committer, even if the person is technically skilled.Qui vote ?
Avoir un système de vote appelle la question de l'électorat : qui a le droit de vote ? C'est là une question potentiellement sensible car elle oblige le projet à reconnaître certaines personnes comme étant plus impliquées ou ayant un meilleur jugement que d'autres.
La meilleur solution consiste à utiliser une distinction existante, comme l'accès à la validation ("accès de commit") et à y attacher les privilèges du vote. Dans les projets qui proposent à la fois des accès de validation partielle et totale la question de savoir si les committers partiels ont accès au vote dépend largement du processus par lequel l'accès à la validation partielle est garanti. Si le projet les délivre généreusement, par exemple comme un moyen de mettre à jour de nombreux outils versés au dépôt par des tierces parties, alors il faudrait préciser que l'accès à la validation partielle est juste un droit de validation, pas un droit de vote. Et inversement : puisque ceux qui ont un accès à la validation totale auront les privilèges du vote, il faut les choisir non seulement en tant que programmeurs, mais aussi en tant que membres de l'électorat. Si quelqu'un affiche sur les listes des diffusion des tendances turbulentes ou obstructionnistes, le groupe devrait peut-être réfléchir à deux fois avant de lui donner les droits de committer, même s'il s'agit de quelqu'un de techniquement performant.The voting system itself should be used to choose new committers, both full and partial. But here is one of the rare instances where secrecy is appropriate. You can't have votes about potential committers posted to a public mailing list, because the candidate's feelings (and reputation) could be hurt. Instead, the usual way is that an existing committer posts to a private mailing list consisting only of the other committers, proposing that someone be granted commit access. The other committers speak their minds freely, knowing the discussion is private. Often there will be no disagreement, and therefore no vote necessary. After waiting a few days to make sure every committer has had a chance to respond, the proposer mails the candidate and offers him commit access. If there is disagreement, discussion ensues as for any other question, possibly resulting in a vote. For this process to be open and frank, the mere fact that the discussion is taking place at all should be secret. If the person under consideration knew it was going on, and then were never offered commit access, he could conclude that he had lost the vote, and would likely feel hurt. Of course, if someone explicitly asks for commit access, then there is no choice but to consider the proposal and explicitly accept or reject him. If the latter, then it should be done as politely as possible, with a clear explanation: "We liked your patches, but haven't seen enough of them yet," or "We appreciate all your patches, but they required considerable adjustments before they could be applied, so we don't feel comfortable giving you commit access yet. We hope that this will change over time, though." Remember, what you're saying could come as a blow, depending on the person's level of confidence. Try to see it from their point of view as you write the mail.
Because adding a new committer is more consequential than most other one-time decisions, some projects have special requirements for the vote. For example, they may require that the proposal receive at least n positive votes and no negative votes, or that a supermajority vote in favor. The exact parameters are not important; the main idea is to get the group to be careful about adding new committers. Similar, or even stricter, special requirements can apply to votes to remove a committer, though hopefully that will never be necessary. See the section called “Committers” in Chapter 8, Managing Volunteers for more on the non-voting aspects of adding and removing committers.Le système de vote lui-même devrait être utilisé pour choisir les nouveaux 'committers', qu'ils aient un accès de commit total ou partiel. Mais il s'agit ici d'une des circonstances où le vote secret est approprié. On ne peut poster des votes sur un committer potentiel sur la liste de discussion publique au risque de heurter les sentiments du candidat (et d'écorner sa réputation). En revanche, l'usage veut qu'un committer existant poste sur une liste privée composée uniquement des autres 'committers' la proposition d'accorder à quelqu'un l'accès à la validation. Les autres 'committers' donnent ouvertement leur avis, sachant que la discussion est privée. Généralement il n'y a aura pas de désaccord, donc pas besoin de vote. Après avoir attendu quelques jours pour être sûr que chacun a eu l'occasion de réagir, celui dont émanait la proposition écrit au candidat pour lui offrir l'accès à la validation. Si désaccord il y a, une discussion s'ensuit comme pour toutes les autres désaccords, débouchant le cas échéant sur un vote. Pour que ce processus soit franc et ouvert le simple fait que la discussion ait lieu devrait rester secret. Si la personne en question savait ce qui est en cours et ne se voyait pas offrir l'accès au commit elle en conclurait qu'elle n'a pas remporté le vote et en serait vraisemblablement blessée. Bien sûr, si quelqu'un demande explicitement l'accès à la validation, il ne reste plus alors qu'à considérer la proposition et à l'accepter ou la rejeter explicitement. Dans ce dernier cas, il faudrait procéder aussi poliment que possible, avec une explication claire : "Nous avons apprécié tes correctifs, mais nous avons besoin d'en voir plus encore" ou "Nous avons apprécié tous tes correctifs, mais ils avaient besoin de beaucoup de réglages avant de pouvoir être appliqués, donc nous ne sommes pas prêt à te donner un accès à la validation pour le moment. Nous espérons que ça va changer avec le temps." Souvenez-vous que ce que vous êtes en train de dire peut être reçu comme un coup, suivant le degré de confiance en soi de la personne. Essayez de voir les choses de son point de vue lorsque vous rédigez le courriel.
Le fait d'ajouter un nouveau committer ayant plus de conséquences que la plupart des autres décisions qui se prennent rapidement, certains projets posent des exigences particulières concernant le vote. Par exemple, ils peuvent exiger que la proposition reçoive au moins une voix pour et aucune voix contre, ou bien qu'une supramajorité vote pour. Les paramètres exacts importent peu ; l'idée principale est que le groupe doit être prudent au moment d'ajouter des nouveau committers. Des exigences particulières similaires ou même plus strictes peuvent être appliquées au vote qui consiste à retirer l'accès à un committer, bien que, avec un peu de chance, ceci ne sera jamais nécessaire. Voyez la section intitulée "Committers", dans le Chapitre 8, Gérer les volontaires pour plus d'informations sur les aspects autres que le vote pour l'attribution ou le retrait des droits de commit.[modifier] Polls Versus Votes
Vote ou sondage ?
Pour certains types de votes il peut être utile d'étendre l'électorat. Par exemple si les développeurs n'arrivent pas à se rendre compte si le choix d'une interface donnée correspond à l'usage que les gens font vraiment du logiciel. Une des solutions consiste à demander à tous les abonnés de la liste de discussion du projet de voter. Il s'agit plus d'un sondage que d'un vote en réalité et les développeurs peuvent choisir de se soumettre au résultat ou non. Comme dans tout sondage, faites en sorte qu'il soit clair pour les participants qu'il s'agit de questions ouvertes : si quelqu'un pense à une meilleure option que celles proposées dans le sondage, sa réponse peut être le résultat le plus important du sondage.[modifier] Vetoes
Some projects allow a special kind of vote known as a veto. A veto is a way for a developer to put a halt to a hasty or ill-considered change, at least long enough for everyone to discuss it more. Think of a veto as somewhere between a very strong objection and a filibuster. Its exact meaning varies from one project to another. Some projects make it very difficult to override a veto; others allow them to be overridden by regular majority vote, perhaps after an enforced delay for more discussion. Any veto should be accompanied by a thorough explanation; a veto without such an explanation should be considered invalid on arrival.
With vetoes comes the problem of veto abuse. Sometimes developers are too eager to raise the stakes by casting a veto, when really all that was called for was more discussion. You can prevent veto abuse by being very reluctant to use vetoes yourself, and by gently calling it out when someone else uses her veto too often. If necessary, you can also remind the group that vetoes are binding for only as long as the group agrees they are—after all, if a clear majority of developers wants X, then X is going to happen one way or another. Either the vetoing developer will back down, or the group will decide to weaken the meaning of a veto.
You may see people write "-1" to express a veto. This usage comes from the Apache Software Foundation, which has a highly structured voting and veto process, described at http://www.apache.org/foundation/voting.html. The Apache standards have spread to other projects, and you will see their conventions used to varying degrees in a lot of places in the Open Source world. Technically, "-1" does not always indicate a formal veto even according to the Apache standards, but informally it is usually taken to mean a veto, or at least a very strong objection.
Like votes, vetoes can apply retroactively. It's not okay to object to a veto on the grounds that the change in question has already been committed, or the action taken (unless it's something irrevocable, like putting out a press release). On the other hand, a veto that arrives weeks or months late isn't likely to be taken very seriously, nor should it be.
Veto
Quelques projets autorisent un type particulier de vote connu sous le nom de veto. Le veto permet au développeur de mettre fin à un changement hâtif ou inconsidéré, au moins suffisamment longtemps pour que l'on puisse encore en discuter. Le veto est quelque chose entre une très forte objection et une forme d'obstruction. Son sens exact varie d'un projet à l'autre. Certains projets rendent très difficile de passer outre un veto ; d'autres permettent de passer outre au moyen d'un vote majoritaire, peut-être après un délai obligatoire destiné à prolonger la discussion. Tout veto devrait être accompagné d'une explication approfondie ; sans cela, il devrait être considéré comme nul et non avenu.
Avec le veto vient le problème de l'abus du veto. Parfois les développeurs sont trop pressés de faire monter les enchères en lançant un veto quand le temps est encore aux discussions. Vous pouvez éviter l'abus du veto en étant vous-même très réticent à y recourir et en signalant gentiment quand quelqu'un d'autre utilise son droit de veto trop souvent. Si nécessaire, vous pouvez également rappeler au groupe que les vetos ne sont contraignants que dans la mesure où le groupe accepte qu'ils le soient. Après tout, si une nette majorité de développeurs veulent X, c'est X qui aura lieu d'une façon ou d'une autre. Dans ce cas, ou bien le développeur qui oppose son veto cède, ou bien le groupe décide d'affaiblir la portée du veto.
Pour exprimer leur veto, certains écrivent "-1". Cet usage vient de l'Apache Software Foundation, qui a un processus de vote et de veto hautement structuré, décrit ici : http://www.apache.org/foundation/voting.html. Les critères d'Apache se sont étendus à d'autres projets et vous les verrez à l'œuvre à divers degrés à de nombreuses reprises dans le monde Open Source. Techniquement, "-1" n'indique pas toujours un veto formel même d'après les critères d'Apache, mais de manière informelle c'est généralement pris dans le sens de veto ou d'une très forte objection.
Comme le vote, le veto peut être rétroactif. On ne peut faire objection au veto en prétextant que le changement en question a déjà été validé par "commit" ou que l'action a déjà été lancée (à moins qu'il ne s'agisse d'un fait irréversible, comme la publication d'un communiqué de presse). D'un autre côté, un veto qui arrive des semaines ou des mois après a peu de chances d'être pris très au sérieux et à juste titre.
