POSS Chap 6 Intro
Un article de Framalang Wiki.
The ability to write clearly is perhaps the most important skill one can have in an Open Source environment. In the long run it matters more than programming talent. A great programmer with lousy communications skills can get only one thing done at a time, and even then may have trouble convincing others to pay attention. But a lousy programmer with good communications skills can coordinate and persuade many people to do many different things, and thereby have a significant effect on a project's direction and momentum.
There does not seem to be much correlation, in either direction, between the ability to write good code and the ability to communicate with one's fellow human beings. There is some correlation between programming well and describing technical issues well, but describing technical issues is only a tiny part of the communications in a project. Much more important is the ability to empathize with one's audience, to see one's own posts and comments as others see them, and to cause others to see their own posts with similar objectivity. Equally important is noticing when a given medium or communications method is no longer working well, perhaps because it doesn't scale as the number of users increases, and taking the time to do something about it.
All of which is obvious in theory—what makes it hard in practice is that free software development environments are bewilderingly diverse both in audiences and in communications mechanisms. Should a given thought be expressed in a post to the mailing list, as an annotation in the bug tracker, or as a comment in the code? When answering a question in a public forum, how much knowledge can you assume on the part of the reader, given that "the reader" is not only the one who asked the question in the first place, but all those who might see your response? How can the developers stay in constructive contact with the users, without getting swamped by feature requests, spurious bug reports, and general chatter? How do you tell when a medium has reached the limits of its capacity, and what do you do about it?
Solutions to these problems are usually partial, because any particular solution is eventually made obsolete by project growth or changes in project structure. They are also often ad hoc, because they're improvised responses to dynamic situations. All participants need to be aware of when and how communications can become bogged down, and be involved in solutions. Helping people do this is a big part of managing an Open Source project. The sections that follow discuss both how to conduct your own communications, and how to make maintenance of communications mechanisms a priority for everyone in the project.[18]
La capacité d'écrire avec clarté est peut-être la qualité la plus importante que l'on peut avoir dans un environnement Open Source. Sur le long terme, elle compte plus que le talent pour programmer. Un programmeur génial ayant de piètres capacités en terme de communication ne peut s'occuper que d'une chose à la fois et même ainsi il aura peut-être du mal à obtenir l'attention désirée. Mais un piètre programmeur avec des talents en matière de communication peut coordonner et convaincre plusieurs personnes de faire plusieurs choses différentes, tout en ayant un impact significatif sur la direction et l'intensité du projet.
Il ne semble pas y avoir de grande corrélation, dans un sens ou dans l'autre, entre la capacité à écrire du bon code et la capacité à communiquer avec ses confrères. Il y a une corrélation entre bien programmer et bien décrire les questions techniques, mais décrire les questions techniques ne représente qu'une infime partie dans la communication que requiert le projet. Bien plus importante est la capacité à s'identifier à son auditoire, de voir ses propres messages et commentaires comme les autres les voient et d'amener les autres à percevoir leurs propres messages avec la même objectivité. Se rendre compte qu'un support ou qu'un processus de communication ne fonctionne plus correctement parce qu'il ne s'adapte pas au nombre grandissant d'utilisateurs par exemple et prendre le temps d'y remédier est tout aussi important.
Tout ceci est évident d'un point de vue théorique, ce qui complique les choses en pratique c'est que les environnements de développement de logiciel libre offrent une variété déconcertante de publics et de mécanismes de communication. Faut-il exprimer telle remarque par un message dans la liste de discussion, sous la forme d'une note dans le traqueur de bogues ou d'un commentaire dans le code ? Pour répondre à une question dans un forum public, quel degré de connaissance supposer de la part du lecteur étant donné que «le lecteur » n'est pas seulement celui qui a posé la question au départ mais tous ceux qui pourront lire la réponse ? Comment les développeurs peuvent-ils rester en contact de manière constructive avec les utilisateurs sans être submergés de demandes sur les fonctionnalités, de rapports de bogue infondés et de discussions généralistes ? Comment déterminer le moment où un support a atteint la limite de ses capacités et que faire pour y remédier ?
Les solutions à ces problèmes sont souvent ponctuelles, car toute solution particulière est à l'occasion rendue obsolète quand le projet grandit ou que sa structure change. Elles sont souvent ad hoc, car ce sont des réponses improvisées à des situations dynamiques. Tous les participants doivent être attentifs à quand et comment les communications s'enlisent et être impliqués dans les solutions. Aider les gens dans ce sens est une partie importante dans la gestion d'un projet Open Source. Les parties suivantes abordent la question de la gestion de votre propre communication et comment faire du maintien des mécanismes de communication une priorité pour chacun des membres du projet [18].
