POSS Chap 3 Intro
Un article de Framalang Wiki.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| GaeliX | GLX | Traduction | Terminé |
| Olivier | OLV | Relecture | Terminé |
| ??? | Validation |
Sommaire |
[modifier] §1
Free software projects rely on technologies that support the selective capture and integration of information. The more skilled you are at using these technologies, and at persuading others to use them, the more successful your project will be. This only becomes more true as the project grows. Good information management is what prevents Open Source projects from collapsing under the weight of Brooks' Law,[12] which states that adding manpower to a late software project makes it later. Fred Brooks observed that the complexity of a project increases as the square of the number of participants. When only a few people are involved, everyone can easily talk to everyone else, but when hundreds of people are involved, it is no longer possible for each person to remain constantly aware of what everyone else is doing. If good free software project management is about making everyone feel like they're all working together in the same room, the obvious question is: what happens when everyone in a crowded room tries to talk at once?
Les projets de logiciels libres se fondent sur des technologies basées sur la capture et l'intégration sélectives des informations. Plus vous êtes habile à employer ces technologies, et à persuader les autres de les employer, plus votre projet aura de succès. Et cela devient d'autant plus vrai que votre projet croit. La bonne gestion de l'information est ce qui empêche des projets Open Source de s'effondrer sous l'effet de la loi de Brook, [12] qui stipule qu'ajouter de la main d'œuvre à un projet informatique en retard ne fait que le retarder plus encore. Fred Brook a observé que la complexité d'un projet informatique augmente proportionnellement au carré du nombre de participants. Quand seulement quelques personnes sont impliquées la communication est aisée, mais quand des centaines de personnes sont impliquées il n'est plus possible que chaque personne reste constamment au courant de ce que chacun fait. Si la bonne gestion d'un projet de logiciel libre est de faire en sorte que chacun des participants ait l'impression de travailler avec tous les autres dans la même pièce, une question s'impose : que se passe-t-il dans une pièce surpeuplée quand tout le monde veut parler en même temps ?
[modifier] §2
This problem is not new. In non-metaphorical crowded rooms, the solution is parliamentary procedure: formal guidelines for how to have real-time discussions in large groups, how to make sure important dissents are not lost in floods of "me-too" comments, how to form subcommittees, how to recognize when decisions are made, etc. An important part of parliamentary procedure is specifying how the group interacts with its information management system. Some remarks are made "for the record", others are not. The record itself is subject to direct manipulation, and is understood to be not a literal transcript of what occurred, but a representation of what the group is willing to agree occurred. The record is not monolithic, but takes different forms for different purposes. It comprises the minutes of individual meetings, the complete collection of all minutes of all meetings, summaries, agendas and their annotations, committee reports, reports from correspondents not present, lists of action items, etc.
Ce problème n'est pas nouveau. Dans les salles surpeuplées non-métaphoriques la solution est le procédé parlementaire : ce sont des directives formelles sur les moyens d'avoir des discussions en temps réel dans de larges assemblées, sur le moyen de s'assurer que d'importantes divergences d'opinion ne vont pas se retrouvées noyées sous des flots de « moi-je », sur la manière de former des sous-comités, d'identifier quand des décisions sont prises, etc. Une part importante de ce procédé parlementaire est de spécifier comment le groupe interagit avec son système d'information. Certaines remarques ont vocation à être « enregistrées », d'autres non. Cet « enregistrement » lui-même est sujet à manipulations et n'est pas une transcription littérale de ce qui vient de se produire mais une représentation de ce que le groupe a convenu de considérer comme résultat. Cet « enregistrement » n'est pas monolithique, mais revêt différentes formes selon la finalité recherchée. Il comprend les comptes-rendus des différentes réunions, la totalité des comptes-rendus de toutes les réunions, les résumés, les ordres du jour et leurs annotations, les rapports de comité, les rapports des correspondants non présents, les listes d'actions à entreprendre, etc.
[modifier] §3
Because the Internet is not really a room, we don't have to worry about replicating those parts of parliamentary procedure that keep some people quiet while others are speaking. But when it comes to information management techniques, well-run Open Source projects are parliamentary procedure on steroids. Since almost all communication in Open Source projects happens in writing, elaborate systems have evolved for routing and labeling data appropriately; for minimizing repetitions so as to avoid spurious divergences; for storing and retrieving data; for correcting bad or obsolete information; and for associating disparate bits of information with each other as new connections are observed. Active participants in Open Source projects internalize many of these techniques, and will often perform complex manual tasks to ensure that information is routed correctly. But the whole endeavor ultimately depends on sophisticated software support. As much as possible, the communications media themselves should do the routing, labeling, and recording, and should make the information available to humans in the most convenient way possible. In practice, of course, humans will still need to intervene at many points in the process, and it's important that the software make such interventions convenient too. But in general, if the humans take care to label and route information accurately on its first entry into the system, then the software should be configured to make as much use of that metadata as possible.
Puisque Internet n'est pas vraiment une salle, nous ne devons pas nous soucier de reproduire cette partie du procédé parlementaire qui fait taire les uns pendant que les autres parlent. Mais quand on en vient aux techniques de gestion de l'information on voit que les projets Open Source bien dirigés utilisent ce procédé parlementaire boosté aux stéroïdes. Puisque presque toute la communication dans des projets Open Source se fait par écrit, des systèmes élaborés ont évolué pour permettre le cheminement et l'étiquetage des données de façon appropriée, pour minimiser les répétitions afin d'éviter des divergences inutiles, pour stocker et rechercher les données, pour corriger les informations fausses ou désuètes et pour connecter ensemble des bribes d'information disparates au fur et à mesure que de nouveaux raccordements sont observés. Les participants actifs dans les projets Open Source ont fait leurs plusieurs de ces techniques et réalisent souvent de complexes opérations manuelles afin de s'assurer que l'information est correctement transmise. Mais le plus gros de l'effort repose finalement sur la sophistication du logiciel sous-jacent. Autant que possible, les média de communications eux-mêmes devraient assurer l'acheminement, l'étiquetage et l'enregistrement et devraient mettre l'information à disposition de l'humain de la façon la plus commode possible. Dans la pratique, évidement, l'humain a toujours besoin d'intervenir sur de nombreux points dans le processus et il est important que le logiciel rende de telles interventions aussi commode que possible. En règle générale, si l'humain fait bien attention à l'étiquetage et à l'acheminement de l'information en entrée du système, alors le logiciel doit être configuré pour tirer le meilleur parti de toutes ces méta-données.
[modifier] §4
The advice in this chapter is intensely practical, based on experiences with specific software and usage patterns. But the point is not just to teach a particular collection of techniques. It is also to demonstrate, by means of many small examples, the overall attitude that will best encourage good information management in your project. This attitude will involve a combination of technical skills and people skills. The technical skills are essential because information management software always requires configuration, plus a certain amount of ongoing maintenance and tweaking as new needs arise (for example, see the discussion of how to handle project growth in the section called “Pre-Filtering the Bug Tracker” later in this chapter). The people skills are necessary because the human community also requires maintenance: it's not always immediately obvious how to use these tools to full advantage, and in some cases projects have conflicting conventions (for example, see the discussion of setting Reply-to headers on outgoing mailing list posts, in the section called “Mailing Lists”). Everyone involved with the project will need to be encouraged, at the right times and in the right ways, to do their part to keep the project's information well organized. The more involved the contributor, the more complex and specialized the techniques she can be expected to learn.
Le conseil de ce chapitre est principalement pratique, basé sur des expériences avec des logiciels spécifiques et des modèles d'utilisation. Mais l'essentiel n'est pas simplement d'enseigner une collection de techniques particulières. L'essentiel est également de montrer, grâce à de nombreux petits exemples quelle est l'attitude générale qui servira au mieux la bonne gestion de l'information dans votre projet. Cette attitude est la somme de qualités techniques et humaines. Les qualités techniques sont essentielles parce qu'un logiciel de gestion de l'information exige toujours d'être configuré, plus une certaine dose de maintenance continue et de contournements au moment où de nouveaux besoins se font sentir (par exemple, voir la discussion sur la façon de gérer la croissance d'un projet dans la section « Filtrer le système de suivi de bogues en amont » plus loin dans ce chapitre). Les qualités humaines sont nécessaires parce que la communauté humaine a elle aussi besoin de maintenance : il n'est pas toujours évident au premier abord de tirer le maximum de ces outils et dans certains cas les projets adoptent des conventions contradictoires (par exemple, voir la discussion sur la façon de configurer l'en-tête du Répondre à dans le cas des Liste de diffusion, dans la section appelée « Liste de diffusion »). Chaque personne impliquée dans le projet devra être encouragée, au bon moment et de la bonne façon, à faire sa part du travail pour que l'information du projet reste bien organisée. Lorsqu'un participant s'implique plus, il est plus susceptible d'apprendre des techniques complexes et spécialisées.
[modifier] §5
Information management has no cut-and-dried solution. There are too many variables. You may finally get everything configured just the way you want it, and have most of the community participating, but then project growth will make some of those practices unscalable. Or project growth may stabilize, and the developer and user communities settle into a comfortable relationship with the technical infrastructure, but then someone will come along and invent a whole new information management service, and pretty soon newcomers will be asking why your project doesn't use it—for example, this is happening now to a lot of free software projects that predate the invention of the wiki (see http://en.wikipedia.org/wiki/Wiki). Many questions are matters of judgement, involving tradeoffs between the convenience of those producing information and the convenience of those consuming it, or between the time required to configure information management software and the benefit it brings to the project.
Pour la gestion de l'information, il n'y a pas de recette miracle. Il y a trop de paramètres. Vous pouvez, au bout du compte, avoir tout configuré de la meilleure manière qu'il soit en regard de vos besoins et avoir la majeur partie de votre communauté en train de participer et ensuite la croissance du projet rendra certaines de ces pratiques inadaptables. Ou encore, la croissance du projet peut se stabiliser et les communautés de développeurs et d'utilisateurs s'installer dans un relation confortable avec l'infrastructure technique puis quelqu'un arrivera et inventera un tout nouveau service de gestion de l'information et aussitôt on vous demandera pourquoi votre projet ne l'emploie pas. C'est par exemple ce qui arrive en ce moment à beaucoup de projets Open Source qui datent d'avant l'invention du wiki (voir le lien http://fr.wikipedia.org/wiki/Wiki). Beaucoup d'interrogations relèvent surtout d'une question de point de vue, comme la différence entre coté pratique pour ceux qui produisent l'information et coté pratique pour ceux qui la consomment ou entre le temps requis pour configurer un logiciel de gestion de l'information et les avantages qu'il peut apporter au projet.
[modifier] §6
Beware of the temptation to over-automate, that is, to automate things that really require human attention. Technical infrastructure is important, but what makes a free software project work is care—and intelligent expression of that care—by the humans involved. The technical infrastructure is mainly about giving humans convenient ways to do that.
Prenez garde à la tentation de sur-automatiser, c'est-à-dire, d'automatiser les choses qui exigent vraiment une attention humaine. L'infrastructure technique est importante, mais ce qui fait qu'un projet Open Source fonctionne c'est l'attention, ainsi que l'expression intelligente de cette attention, que les humains impliqués vont déployer. Le but principal d'une infrastructure technique est de donner à l'humain les outils les plus adaptés pour faire cela.
