POSS Chap 8 Intro
Un article de Framalang Wiki.
Getting people to agree on what a project needs, and to work together to achieve it, requires more than just a genial atmosphere and a lack of obvious dysfunction. It requires someone, or several someones, consciously managing all the people involved. Managing volunteers may not be a technical craft in the same sense as computer programming, but it is a craft in the sense that it can be improved through study and practice.
This chapter is a grab-bag of specific techniques for managing volunteers. It draws, perhaps more heavily than previous chapters, on the Subversion project as a case study, partly because I was working on that project as I wrote this and had all the primary sources close at hand, and partly because it's more acceptable to cast critical stones into one's own glass house than into others'. But I have also seen in various other projects the benefits of applying—and the consequences of not applying—the recommendations that follow; when it is politically feasible to give examples from some of those other projects, I will do so.
Speaking of politics, this is as good a time as any to drag that much-maligned word out for a closer look. Many engineers like to think of politics as something other people engage in. « I'm just advocating the best course for the project, but she's raising objections for political reasons. » I believe this distaste for politics (or for what is imagined to be politics) is especially strong in engineers because engineers are bought into the idea that some solutions are objectively superior to others. Thus, when someone acts in a way that seems motivated by outside considerations—say, the maintenance of his own position of influence, the lessening of someone else's influence, outright horse-trading, or avoiding hurting someone's feelings—other participants in the project may get annoyed. Of course, this rarely prevents them from behaving in the same way when their own vital interests are at stake.
If you consider « politics » a dirty word, and hope to keep your project free of it, give up right now. Politics are inevitable whenever people have to cooperatively manage a shared resource. It is absolutely rational that one of the considerations going into each person's decision-making process is the question of how a given action might affect his own future influence in the project. After all, if you trust your own judgement and skills, as most programmers do, then the potential loss of future influence has to be considered a technical result, in a sense. Similar reasoning applies to other behaviors that might seem, on their face, like « pure » politics. In fact, there is no such thing as pure politics: it is precisely because actions have multiple real-world consequences that people become politically conscious in the first place. Politics is, in the end, simply an acknowledgment that all consequences of decisions must be taken into account. If a particular decision leads to a result that most participants find technically satisfying, but involves a change in power relationships that leaves key people feeling isolated, the latter is just as important a result as the former. To ignore it would not be high-minded, but shortsighted.
So as you read the advice that follows, and as you work with your own project, remember that there is no one who is above politics. Appearing to be above politics is merely one particular political strategy, and sometimes a very useful one, but it is never the reality. Politics is simply what happens when people disagree, and successful projects are those that evolve political mechanisms for managing disagreement constructively.
Parvenir à mettre les gens d'accord sur les besoins du projet et parvenir à les faire travailler ensemble pour atteindre ce but demande plus qu'une atmosphère sympathique et une absence de dysfonctionnements évidents. Il faut qu'une personne, ou plusieurs personnes, prenne(nt) en charge la gestion des volontaires. Gérer les volontaires n'est peut être pas un art technique au même titre que la programmation mais c'est un art dans le sens où cette discipline peut-être améliorée par l'étude et la mise en pratique.
Ce chapitre n'est pas un ensemble de techniques précises prêtes à l'emploi pour diriger les volontaires. Il s'appuie, peut-être plus encore que les autres chapitres, sur le projet Subversion comme cas d'étude. Ceci est dû en partie au fait que je travaillais sur ce projet au moment de l'écriture, j'avais donc un accès direct à la matière première et en partie aussi parce qu'il est plus acceptable de commencer par une auto-critique. Mais j'ai également pu voir dans d'autres projets les conséquences de la mise en application, ou les conséquences de la non mise en application, des recommandations qui suivent. Lorsqu'il est politiquement correct que je cite des exemples parmi d'autres projets je le ferai.
En parlant de politique, quitte à en discuter, autant le faire maintenant et regarder de plus près ce domaine tant décrié. De nombreux ingénieurs pensent que la politique est une chose à laquelle s'adonnent uniquement les autres. « Je ne fais que défendre la meilleure marche à suivre pour le projet, mais elle soulève des objections pour des raisons politiques. » Je pense que ce dégoût de la politique (ou de ce qui est perçu comme tel) est particulièrement fort chez les ingénieurs car ils adhèrent à l'idée que certaines solutions sont objectivement meilleures que d'autres. Ainsi, quand quelqu'un agit d'une manière qui semble motivée par des considérations externes, par exemple la défense de sa propre position d'influence, l'abaissement de l'influence de quelqu'un d'autre, un retournement de veste manifeste ou encore pour éviter de blesser quelqu'un, d'autres personnes dans le projet pourraient en être gênées. Ce qui ne les empêchera évidemment pas de se comporter de la même manière quand leurs propres intérêts vitaux sont en jeu.
Si pour vous « politique » est un mot sale et que vous espérez qu'il ne vienne pas ternir votre projet vous pouvez abandonner dès maintenant. La politique est inévitable quand des gens doivent gérer une ressource partagée coopérativement. Lors d'une prise de décision il est tout à fait normal de prendre en considération les conséquences que cette décision auront sur notre influence future dans le projet. Après tout, si vous avez confiance en votre propre jugement et vos propres compétences, comme la plupart des programmeurs, le risque de perdre de l'influence doit être considéré comme une donnée technique dans un sens. Un raisonnement similaire s'applique à d'autres comportements qui peuvent, de prime abord, sembler purement politiques. En fait le « purement politique » n'existe pas, c'est bien parce que les actions ont des répercussions dans le monde réel que les gens deviennent « politiquement conscients ». La politique n'est rien d'autre finalement que le fait de reconnaître que toutes les conséquences d'une décision doivent être prises en compte. Si une décision en particulier mène à un résultat que les participants trouvent techniquement satisfaisant mais qui modifie les relations au pouvoir et qui donne un sentiment de mise à l'écart à certains personnages clés, alors ce dernier résultat est au moins aussi important que le résultat technique. L'ignorer n'est pas un signe de noblesse d'esprit mais plutôt de manque de clairvoyance.
Alors en lisant les conseils qui suivent, quand vous travaillez sur votre propre projet, souvenez vous que personne n'est au dessus de la politique. Se donner l'air d'être au dessus de la politique n'est qu'une simple stratégie politique, qui peut parfois être très utile, mais dans tous les cas ce n'est jamais une réalité. La politique est simplement le fruit du désaccord entre certaines personnes et les projets qui réussissent sont ceux qui développent des mécanismes politiques pour gérer les désaccords de manière constructive.
