Chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, lamessen, Sphinx, peupleLà, lerouge, Sky, Julius22, Astalaseven, Alpha, HgO, michel, Sputnik, goofy, HanX, KoS

Ne vous inquiétez pas, faites confiance

Shaun McCance

Shaun McCance est impliqué dans la documentation de GNOME depuis 2003 en tant que rédacteur, chef de la communauté et développeur d’outils. Il a passé la plupart de ce temps à se demander comment inciter davantage de personnes à écrire une documentation de meilleure qualité, avec un certain succès à long terme. Il propose son expérience de la documentation communautaire à travers sa société de conseil, Syllogist.

Alors que je m’apprêtais à écrire cet article, il s’est passé quelque chose d’énorme : GNOME 3 est sorti. C’était la première version majeure de GNOME depuis neuf ans. Tout était différent et toute la documentation existante devait être réécrite. Au même moment, nous changions notre façon de l’écrire. Nous avions jeté nos vieux manuels et étions repartis sur une nouvelle base, avec un système d’aide dynamique par sujet, en utilisant Mallard.

Quelques semaines avant la sortie, une partie d’entre nous s’est réunie pour élaborer la documentation. Nous passions nos journées à travailler, à planifier, à écrire et à réviser. Nous avons écrit des centaines de pages malgré les changements incessants liés aux ultimes modifications du logiciel. Nous avions des contributeurs en ligne qui proposaient de nouvelles pages et corrigeaient ce qui existait déjà. Je n’avais jamais vu notre équipe de documentation aussi productive.

À quoi avons-nous finalement abouti ? Beaucoup de facteurs sont entrés en jeu, et je pourrais écrire un livre entier sur les nuances de la documentation open source. Mais ce que j’ai fait de plus important a été de m’effacer et de laisser les autres faire le travail. J’ai appris à déléguer ; et à déléguer dans les règles de l’art.

Revenons huit ans en arrière. J’ai commencé à m’impliquer dans la documentation de GNOME en 2003. Je n’avais pas vraiment d’expérience en tant que rédacteur technique à cette époque. Mon emploi m’amenait à travailler sur des outils de publication et j’ai commencé à travailler sur les outils et sur le visualiseur d’aide utilisés par la documentation de GNOME. Peu de temps après, je me suis retrouvé à la rédaction de la documentation.

En ce temps-là, la majeure partie de notre documentation était entre les mains de rédacteurs techniques professionnels de chez Sun. Ils s’occupaient d’un manuel, l’écrivaient, le relisaient et l’envoyaient sur notre dépôt CVS. Après quoi nous pouvions tous le regarder, y apprendre quelque chose et lui apporter des corrections. Mais il n’existait pas d’efforts concertés pour impliquer les gens dans le processus d’écriture.

Ce n’est pas que les rédacteurs de Sun essayaient de protéger ou de cacher quoi que ce soit. Ils étaient avant tout rédacteurs techniques. Ils connaissaient leur travail et le faisaient bien. D’autres personnes auraient pu les remplacer pour d’autres manuels mais ils auraient écrit leurs travaux d’une manière habituelle. Utiliser un groupe de collaborateurs novices, aussi enthousiastes soient-ils, pour chaque page, revient à perdre un temps inimaginable sur des détails. C’est tout simplement contre-productif.

De manière inévitable, le vent a tourné chez Sun et leurs rédacteurs techniques ont été affectés à d’autres projets. Cela nous a laissés sans nos rédacteurs les plus prolifiques, ceux qui disposaient des meilleures connaissances. Pire que cela, nous étions laissés sans communauté et personne n’était là pour ramasser les morceaux.

Il y a des idées et des processus standards dans le monde de l’entreprise. J’ai travaillé dans le monde de l’entreprise. Je ne crois pas que quiconque remette ces idées en cause. Les gens font leur travail. Ils choisissent des missions et les terminent. Ils demandent aux autres de faire une relecture, mais ils n’ouvrent pas leur travail aux nouveaux venus et aux rédacteurs moins expérimentés. Les meilleurs rédacteurs écriront sans doute le plus.

Ces idées sont d’une plate évidence, mais elles échouent lamentablement dans un projet communautaire. Vous ne développerez jamais une communauté de contributeurs si vous faites tout vous-même. Dans un projet de logiciel, vous pouvez avoir des contributeurs compétents et suffisamment impliqués pour contribuer régulièrement. Dans la documentation, cela n’arrive presque jamais.

La plupart des gens qui s’essayent à la documentation ne le font pas parce qu’ils veulent être rédacteur technique ni même parce qu’ils aiment écrire. Ils le font parce qu’ils veulent contribuer. Et la documentation est la seule manière qu’ils trouvent accessible. Ils ne savent pas coder. Ils ne sont artistiquement pas doués. Ils ne maîtrisent pas assez une autre langue pour faire de la traduction. Mais ils savent écrire.

C’est là que les rédacteurs professionnels lèvent les yeux au ciel. Le fait que vous soyez instruit ne signifie pas que vous puissiez écrire une bonne documentation pour l’utilisateur. Il ne s’agit pas simplement de poser des mots sur le papier. Vous devez comprendre vos utilisateurs, ce qu’ils savent, ce qu’ils veulent, les endroits où ils cherchent. Vous avez besoin de savoir comment présenter l’information de façon compréhensible et savoir où la mettre pour qu’ils puissent la trouver.

Les rédacteurs techniques vous diront que la rédaction technique n’est pas à la portée de tous. Ils ont raison. Et c’est exactement pourquoi la chose la plus importante que les rédacteurs professionnels puissent faire pour la communauté est de ne pas écrire.

La clé pour construire une communauté efficace autour de la documentation, c’est de laisser les autres prendre les décisions, faire le travail et en récolter eux-mêmes les fruits. Il ne suffit pas de leur donner du travail en continu. La seule solution pour qu’ils s’intéressent suffisamment et s’accrochent au projet, c’est qu’ils se sentent investis personnellement. Le sentiment de faire partie intégrante d’un projet est une source puissante de motivation.

Mais si vous ne travaillez qu’avec des rédacteurs débutants et que vous leur donnez tout le travail à faire, comment pouvez-vous avoir l’assurance que la documentation ainsi créée sera de qualité ? Une participation massive mais incontrôlée n’aboutit pas à de bons résultats. Le rôle d’un rédacteur expérimenté au sein de la communauté est d’être un professeur et un mentor. Vous devez leur apprendre comment rédiger.

Commencez par impliquer les gens tôt dans le planning. Planifiez toujours du bas vers le haut. La planification du haut vers le bas n’incite pas à la collaboration. Il est difficile d’impliquer les gens dans la réalisation d’une vue d’ensemble de haut niveau si tous n’ont pas la même perception de cette vue d’ensemble. Mais les gens sont capables de travailler sur des segments. Ils peuvent réfléchir à des sujets particuliers d’écriture, à des tâches que les gens réalisent, à des questions que les gens peuvent se poser. Ils peuvent regarder les forums de discussion et les listes de diffusion afin de voir ce que les utilisateurs demandent.

Écrivez vous-même quelques pages. Cela donne un exemple à imiter. Il faut ensuite répartir tout le reste du travail. Laissez à d’autres la responsabilité de rubriques ou de chapitres entiers. Précisez-leur clairement quelles informations ils doivent fournir, mais laissez-les écrire. C’est en forgeant qu’on devient forgeron.

Soyez constamment disponible pour les aider ou répondre aux questions. Au moins la moitié de mon temps consacré à la documentation est passée à répondre à des questions afin que les autres puissent effectuer leur travail. Quand des brouillons sont soumis, relisez-les et discutez des critiques et des corrections avec leurs auteurs. Ne vous contentez pas de corriger vous-même.

Cela vous laisse tout de même le gros du travail à faire. Les gens complètent les pièces du puzzle, mais c’est toujours vous qui les assemblez. Au fur et à mesure qu’ils acquièrent de l’expérience, les gens s’occuperont de pièces de plus en plus grandes. Encouragez-les à s’impliquer davantage. Donnez-leur davantage de travail. Faites en sorte qu’ils vous aident à aider plus de rédacteurs. La communauté fonctionnera toute seule.

Huit ans plus tard, GNOME a réussi à créer une équipe de documentation qui se gère elle-même, résout les problèmes, prend des décisions, produit une bonne documentation et accueille constamment de nouveaux contributeurs. N’importe qui peut la rejoindre et y jouer un rôle. Telle est la clé du succès pour une communauté open source.