POSS Chap 4 Part 1

Un article de Framalang Wiki.

Jump to: navigation, search

[modifier] Benevolent Dictators

The benevolent dictator model is exactly what it sounds like: final decision-making authority rests with one person, who, by virtue of personality and experience, is expected to use it wisely.

Although "benevolent dictator" (or BD) is the standard term for this role, it would be better to think of it as "community-approved arbitrator" or "judge". Generally, benevolent dictators do not actually make all the decisions, or even most of the decisions. It's unlikely that one person could have enough expertise to make consistently good decisions across all areas of the project, and anyway, quality developers won't stay around unless they have some influence on the project's direction. Therefore, benevolent dictators commonly do not dictate much. Instead, they let things work themselves out through discussion and experimentation whenever possible. They participate in those discussions themselves, but as regular developers, often deferring to an area maintainer who has more expertise. Only when it is clear that no consensus can be reached, and that most of the group wants someone to guide the decision so that development can move on, do they put their foot down and say "This is the way it's going to be." Reluctance to make decisions by fiat is a trait shared by virtually all successful benevolent dictators; it is one of the reasons they manage to keep the role.

____

Le dictateur bienveillant

Le dictateur bienveillant est exactement ce que laisse entendre son nom : l'instance de prise de décision ultime réside en une personne dont on attend, en vertu de sa personnalité et de son expérience, qu'elle en use sagement.

Bien que "dictateur bienveillant" (DB) soit le terme courant pour ce rôle, ce serait mieux de l'imaginer comme un "arbitre approuvé par la communauté" ou un "juge". Généralement, les dictateurs bienveillants ne prennent pas réellement toutes les décisions, ni même la majorité des décisions. Il est peu probable qu'une seule personne puisse avoir suffisamment de compétences pour prendre des décisions justes dans tous les domaines d'un projet et, de toute façon, les bons développeurs ne resteront pas dans les parages s'ils n'ont pas quelque influence sur la direction du projet. C'est pourquoi les dictateurs bienveillants ne dictent généralement pas grand chose. En revanche, ils laissent les choses s'éclaircir d'elles-mêmes au travers de la discussion et de l'expérimentation quand c'est possible. Ils participent à ces discussions eux-mêmes, mais en tant que simples développeurs, s'en remettant souvent à un responsable du domaine qui a plus de savoir-faire. C'est seulement quand il est clair qu'on n'atteindra pas de consensus, et que la majorité du groupe veut que quelqu'un oriente la décision pour que le développement puisse continuer, qu'ils tapent du poing sur la table en disant : "Voilà ce qu'il faut faire." Le fait de répugner à la prise de décisions par dictat est un trait commun à presque tous les bons dictateurs bienveillants ; c'est une des raisons pour lesquelles ils parviennent à garder leur rôle.


[modifier] Who Can Be a Good Benevolent Dictator?

Being a BD requires a combination of traits. It needs, first of all, a well-honed sensitivity to one's own influence in the project, which in turn brings self-restraint. In the early stages of a discussion, one should not express opinions and conclusions with so much certainty that others feel like it's pointless to dissent. People must be free to air ideas, even stupid ideas. It is inevitable that the BD will post a stupid idea from time to time too, of course, and therefore the role also requires an ability to recognize and acknowledge when one has made a bad decision—though this is simply a trait that any good developer should have, especially if she stays with the project a long time. But the difference is that the BD can afford to slip from time to time without worrying about long-term damage to her credibility. Developers with less seniority may not feel so secure, so the BD should phrase critiques or contrary decisions with some sensitivity for how much weight her words carry, both technically and psychologically.

____

Qui peut être un bon dictateur bienveillant ?
Être un DB requiert une combinaison de traits de caractère. Il faut, tout d'abord, une perception bien affûtée de sa propre influence sur le projet, ce qui implique en retour de la modération. Dans les premières phases de discussion, on ne devrait pas asséner ses opinions et ses conclusions de telle sorte que les autres puissent trouver inutile de penser différemment. Les gens doivent se sentir à l'aise pour exposer leurs idées, même leur idées stupides. Inévitablement, le DB aussi postera à l'occasion une idée stupide bien sûr, c'est pourquoi le rôle requiert aussi la capacité de comprendre et de reconnaître quand on a pris une mauvaise décision, même s'il ne s'agit là que d'un trait que tout bon développeur devrait avoir, notamment s'il reste longtemps dans le projet. La différence est que le DB peut se permettre d'échapper au projet de temps en temps sans craindre des dommages à long-terme sur sa crédibilité. Les développeurs moins anciens ne se sentiront pas aussi en sécurité et le DB devra formuler ses critiques et ses décisions contraires en pesant avec tact ses mots et leur portée sur le plan aussi bien technique que psychologique.


The BD does not need to have the sharpest technical skills of anyone in the project. She must be skilled enough to work on the code herself, and to understand and comment on any change under consideration, but that's all. The BD position is neither acquired nor held by virtue of intimidating coding skills. What is important is experience and overall design sense—not necessarily the ability to produce good design on demand, but the ability to recognize good design, whatever its source. It is common for the benevolent dictator to be a founder of the project, but this is more a correlation than a cause. The sorts of qualities that make one able to successfully start a project—technical competence, ability to persuade other people to join, etc.—are exactly the qualities any BD would need. And of course, founders start out with a sort of automatic seniority, which can often be enough to make benevolent dictatorship appear the path of least resistance for all concerned.


Le DB n'a pas besoin de posséder de meilleures compétences techniques que quiconque dans le projet. Il doit avoir suffisamment de compétences pour travailler sur le code, pour comprendre et discuter tout changement et c'est tout. La position de DB n'est ni obtenue ni détenue en vertu d'un talent à coder hors du commun. Ce qui compte est l'expérience et la vision globale, pas forcément la capacité à concevoir de bonnes choses à la demande, mais à reconnaître une bonne conception, quelle qu'en soit la source.

Le dictateur bienveillant est généralement un des fondateurs du projet, mais il s'agit plus d'une corrélation que d'une cause. Le genre de qualités qui rendent quelqu'un susceptible de démarrer un projet avec succès, compétences techniques, capacité à persuader d'autres gens de s'y associer, etc., sont exactement les mêmes que celles dont a besoin le DB. Et évidemment, les fondateurs démarrent avec une sorte d'ancienneté automatique qui peut souvent suffire à faire du dictateur bienveillant la voie de moindre résistance qui s'offre à tous.

Remember that the potential to fork goes both ways. A BD can fork a project just as easily as anyone else, and some have occasionally done so, when they felt that the direction they wanted to take the project was different from where the majority of other developers wanted to go. Because of forkability, it does not matter whether the benevolent dictator has root (system administrator privileges) on the project's main servers or not. People sometimes talk of server control as though it were the ultimate source of power in a project, but in fact it is irrelevant. The ability to add or remove people's commit passwords on one particular server affects only the copy of the project that resides on that server. Prolonged abuse of that power, whether by the BD or someone else, would simply lead to development moving to a different server.

Whether your project should have a benevolent dictator, or would run better with some less centralized system, largely depends on who is available to fill the role. As a general rule, if it's simply obvious to everyone who should be the BD, then that's the way to go. But if no candidate for BD is immediately obvious, then the project should probably use a decentralized decision-making process, as described in the next section.


Souvenez-vous que le potentiel de fourche est à double tranchant. Un DB peut scinder un projet aussi facilement que n'importe qui et certains l'ont fait à l'occasion quand ils ont senti que la direction qu'ils voulaient que prenne le projet était différente de celle souhaitée par la plupart des développeurs. A cause de la possibilité de fork, peu importe si le dictateur bienveillant a les privilèges d'administrateur sur le serveur principal du projet ou pas. Les gens parlent parfois du contrôle du serveur comme de la source ultime du pouvoir dans un projet, mais en fait c'est sans importance. La capacité d'ajouter ou d'enlever les mots de passe de validation (commit) des uns et des autres sur un serveur particulier n'affecte que la copie du projet qui réside sur ce serveur. Un abus prolongé de ce pouvoir, que ce soit de la part du DB ou de quelqu'un d'autre, aurait tout simplement pour conséquence de déplacer le développement vers un autre serveur.

Quant à savoir si votre projet devrait avoir un dictateur bienveillant ou se porterait mieux avec un système moins centralisé, cela dépend en grande partie de la personne disponible pour endosser ce rôle. En règle générale, si tout le monde trouve évident qu'untel devrait être le DB, le problème est résolu. Mais si aucun candidat ne se démarque nettement, le projet devrait plutôt recourir à un mode de prise de décision décentralisé.
  1. A partir du 3e paragraphe, l'auteur parle du benevolent dictator au FEMININ, sans transition. J'ai laissé tout au masculin en français, en attendant d'en comprendre la raison.
  2. "has root" : "a le mot de passe root" ou "est root" ?

81.57.208.69 15 mars 2007 à 23:25 (CET)

--Olivier 30 septembre 2007 à 12:19 (CEST):

Il emploie effectivement souvent le féminin tout au long du livre quand il parle de personne en particulier. Je pense qu'il vaut mieux garder le masculin comme c'est ce qui est "normal".

Pour root j'ai simplement gardé ta parenthèse (droits d'administration)
Repassée par hasard, j'ai fait une relecture orthographique : ça n'a pas été inutile !. --
Récupérée de « http://www.framalang.org/wiki/POSS_Chap_4_Part_1 »