Bienvenue LibreOffice 4.0 !

-> Nouveautés et correctifs de la version 4.0

• Source : LibreOffice 4 est disponible au téléchargement ? (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

21/42 ! Tiens, nous voilà déjà à mi-chemin de la traduction d’Open Advice.

Deux ou trois articles petits ou grands chaque jeudi, traduits en un temps record par une bande de furieux, ceux qui sont là depuis le début et ceux qui débarquent et demandent s’ils peuvent participer, ceux qui travaillent d’arrache-clavier et ceux qui en profitent pour déconner échanger des propos sur le chat du pad, ceux qui choisissent un pseudo et ceux qui restent anonymous, ceux qui négligent tranquillement l’orthographe et les grammar nazis qui rectifient, ceux qui traduisent avec Google translate et ceux qui se battraient pour une majuscule à Libre… on rencontre tout un peuple là, et jusqu’à présent tout se passe dans l’enthousiasme et la bonne humeur, l’échange et l’entraide devant un passage un peu ardu sur lequel on s’amuse à chinoiser…

Mais cette fois-ci c’est l’auteur de l’article lui-même qui nous a fait le plaisir de nous rejoindre pour contribuer à la traduction, ce qui est tout de même assez confortable. Merci Guillaume !

Malgré nos relectures croisées, nul doute que des coquilles auront échappé à notre vigilance et que nous trouverons des lecteurs pour les signaler, ce qui nous est précieux car la révision avant l’édition du framabook en sera d’autant facilitée.

D’ici là, en avant pour la deuxième moitié : chaque jeudi à 21h, rendez-vous sur le framapad de traduction, le travail collaboratif sera ensuite publié ici même.

Traduction Framalang : Nyx, Sphinx, peupleLà, Kalupa, Guillaume Paumier, Husi10, lenod, Sky, Julius22, Alpha, RavageJo, KoS, Sputnik, goofy, lamessen

Apprenez de vos utilisateurs

Guillaume Paumier

Guillaume Paumier est photographe et physicien, il habite à Toulouse. Wikipédien depuis longtemps, il travaille actuellement pour la Wikimedia Foundation, l’organisation à but non lucratif qui héberge Wikipédia. En tant que responsable de l’ergonomie multimédia, il a notamment étudié le comportement des utilisateurs afin de créer un nouveau système d’import de fichiers pour Wikimedia Commons, la médiathèque libre associée à Wikipédia.

Vous connaissez Wikipédia, l’encyclopédie libre et gratuite que tout le monde peut modifier ? Elle a été créée en 2001 et a récemment fêté son dixième anniversaire. Bien qu’elle soit l’un des dix sites les plus visités au monde, son interface reste très « 1.0 » quand on la compare aux possibilités qu’offrent les technologies web modernes. Certains peuvent trouver ça bien : Wikipédia est un « truc sérieux » et les utilisateurs n’ont pas à être distraits par des « paillettes » dans l’interface. Pourtant, si Wikipédia a eu du mal à recruter de nouveaux contributeurs ces dernières années, c’est en partie à cause de son interface que certains considèrent comme archaïque. Ceci explique peut-être pourquoi les enquêtes sur les participants à Wikipédia ont montré à maintes reprises qu’il s’agit principalement d’une population d’hommes jeunes, attirés par la technologie, la plupart ayant une formation en informatique et en ingénierie. En dehors du fait que la connaissance libre et les licences libres sont issues du terreau fertile du logiciel libre et open source, l’interface compliquée a découragé beaucoup de contributeurs éventuels.

En 2011, alors que la majorité des plates-formes de publication collaboratives en ligne (comme WordPress, Etherpad et Google Documents) offrent un éditeur graphique, même rudimentaire, Wikipédia utilise toujours, par défaut, un ancien éditeur de texte wiki qui utilise des guillemets (“”) et des crochets ([[]]) pour la mise en forme. Des efforts sont en cours afin de passer à un éditeur graphique par défaut en 2012, mais ce n’est pas un défi facile à relever.

Mais laissons l’éditeur de côté un moment. L’interface de Wikipédia demeure assez compliquée. Et de nombreuses fonctionnalités utiles sont difficiles à découvrir. Savez-vous que Wikipédia possède un système de contrôle de versions intégré ? Et que vous pouvez voir toutes les anciennes versions d’une page ? Savez-vous que vous pouvez voir la liste de toutes les modifications effectuées par un contributeur ? Savez-vous que vous pouvez créer un lien vers une version donnée d’une page ? Savez-vous que vous pouvez exporter une page en PDF ? Savez-vous que vous pouvez créer un vrai livre personnalisé à partir du contenu de Wikipédia ? Et que vous pouvez le faire livrer chez vous ?

Le modèle d’implémentation

La plupart des lecteurs de Wikipédia y arrivent via des moteurs de recherche. Les statistiques montrent qu’ils passent peu de temps sur Wikipédia une fois qu’ils ont trouvé l’information qu’ils cherchaient. Un petit nombre seulement s’attarde et explore les outils que propose l’interface. Par exemple, on critique régulièrement Wikipédia sur sa qualité et sur sa fiabilité. Nombre de ces outils rarement explorés et presque cachés pourraient s’avérer bien utiles aux lecteurs pour les aider à vérifier la fiabilité de l’information, telles que les « pages de discussion » qui témoignent des discussions (passées et en cours) entre les différents contributeurs de chaque article ayant abouti à son contenu actuel.

Wikipédia et ses projets frères (tels que Wikisource et Wikimedia Commons) sont propulsés par le moteur de wiki MediaWiki — et sont soutenus par la Wikimedia Foundation ; rien que ces noms, dans leur confusion, sont un péché contre l’ergonomie. Pendant longtemps, le développement de MediaWiki a été conduit par des développeurs de logiciels. La communauté MediaWiki est forte de nombreux développeurs ; à vrai dire, la communauté est presque exclusivement composée de développeurs. Ce n’est que récemment que des designers ont rejoint la communauté, et ils ont été recrutés par la Wikimedia Foundation pour ce rôle. Il n’y a quasiment aucun designer bénévole dans la communauté. De ce fait, l’application a été construite et « maquettée » exclusivement par des développeurs. Par conséquent, la forme de l’interface a naturellement suivi de très près le « modèle d’implémentation », c’est-à-dire la manière dont le logiciel est implémenté dans le code et les structures de données. Le modèle d’implémentation ne correspond que rarement au « modèle utilisateur », c’est-à-dire à la manière dont l’utilisateur imagine que le logiciel fonctionne.

Il serait injuste de dire que les développeurs ne se soucient pas des utilisateurs. Quand on crée un logiciel, le but — outre le plaisir d’apprendre des choses, d’écrire du code et de résoudre des problèmes — c’est de le publier afin qu’il puisse être utilisé. Ceci est particulièrement vrai dans le monde du logiciel libre et open source, où la plupart des développeurs donnent bénévolement de leur temps et de leurs connaissances. On pourrait avancer que les développeurs sont, de fait, des utilisateurs de leurs propres produits, notamment dans le monde du logiciel libre et open source. Après tout, ils les ont créés ou ont rejoint leurs équipes pour une bonne raison, et c’est rarement l’argent. Par conséquent, les développeurs de ce type de logiciels devraient être dans une position idéale pour savoir ce que veulent leurs utilisateurs.

Mais soyons honnêtes : si vous êtes en train de lire ceci, c’est que vous n’êtes pas votre utilisateur lambda.

Le point de vue du développeur

Si vous êtes développeur, il vous est particulièrement difficile de vous mettre à la place de l’utilisateur. Tout d’abord, votre connaissance du code et de l’implémentation du logiciel vous force à observer ses fonctionnalités et son interface à travers un prisme très particulier. Vous connaissez chacune des fonctionnalités de l’application que vous avez créée. Vous savez où trouver chaque menu. Si quelque chose paraît légèrement bizarre dans l’interface, il est possible que vous l’ignoriez sans le vouloir, parce que vous savez inconsciemment que c’est lié à la façon dont la fonctionnalité est implémentée.

Imaginons que vous soyez en train de créer une application qui enregistre des données sous forme de tableau (par exemple, dans une base de données). Quand vous devrez ensuite afficher ces données pour les montrer à l’utilisateur, il est très probable que vous les représentiez comme un tableau, car c’est la façon dont vous avez implémenté leur stockage. Il vous paraîtra logique d’afficher les données dans un format qui est cohérent avec le format de stockage. Vous aurez probablement le même réflexe pour tout autre type de structure de données séquentielles : vous aurez tendance à l’afficher sous forme de séquence dans l’interface, peut-être comme une liste. Et pourtant, un autre format d’affichage aurait peut-être été plus pertinent et facile d’utilisation pour les utilisateurs, par exemple sous forme d’une série de phrases, d’un graphique ou d’une autre représentation visuelle.

Un autre défi est votre niveau d’expertise. Comme vous souhaitez que votre application soit extraordinaire, vous allez probablement vous documenter sur le sujet pour la concevoir. En fin de compte, vous n’allez pas seulement connaître votre application sur le bout des doigts, vous allez également devenir un expert dans le domaine lui-même. Un grand nombre de vos utilisateurs n’auront pas ce niveau d’expertise — ou n’en auront pas besoin. Ils pourraient être perdus par le niveau de détail de certaines fonctionnalités ou ne pas être familiers avec des termes inconnus des profanes.

Alors, que pouvez-vous faire pour arranger cela ?

Observez les utilisateurs. Vraiment

Observer les utilisateurs à l’œuvre avec votre application est une expérience réellement révélatrice.

Bon, pour observer comment les gens utilisent votre application, vous pouvez faire appel à une société de conseil en ergonomie ; cette société va alors recruter des volontaires avec des profils différents au sein d’un vivier de plusieurs milliers de testeurs, elle va mettre au point une grille d’entretien, louer une salle dédiée aux tests d’ergonomie qui comprendra un dispositif pour enregistrer ce qui se passe sur l’écran et une caméra pointée vers le testeur, et vous serez derrière une vitre sans tain, dans une salle d’observation, à vous taper la tête contre les murs et à jurer à chaque fois que l’utilisateur fait quelque chose qui, selon vous, n’a aucun sens. Si vous avez les moyens de le faire, alors n’hésitez pas, foncez. Ce que vous y apprendrez vous permettra de complètement changer votre point de vue. Si vous n’avez pas les moyens de recourir à une procédure de test professionnelle, tout n’est pas perdu ; vous allez juste devoir le faire par vous-même. Asseyez-vous derrière un utilisateur pendant qu’il vous montre comment il effectue ses tâches et les intègre à son mode de travail. Soyez un observateur silencieux : votre but est d’observer et de noter tout ce qui se passe. Beaucoup de choses vont vous surprendre. Une fois que l’utilisateur a terminé, vous pouvez relire vos notes et lui poser des questions afin de mieux comprendre comment il fonctionne.

Pour vous aider à conduire ces tests vous-même, il existe d’excellents ouvrages comme Don’t Make Me Think: A Common Sense Approach to Web Usability [NdT: Traduit en français : Je ne veux pas chercher: Optimisez la navigation de vos sites et menez vos internautes à bon port], écrit par Steve Krug, About Face 3: The Essentials of Interaction Design, d’Alan Cooper, Robert Reimann et David Cronin, et le projet OpenUsability. Être observé peut être un peu intimidant pour les utilisateurs, mais je parie qu’ils seront nombreux à se porter volontaires pour vous aider à améliorer votre application. Les utilisateurs qui ne peuvent pas contribuer au code sont généralement heureux de trouver d’autres façons de contribuer au logiciel libre : vous montrer comment ils utilisent le logiciel est une manière simple de le faire. Les utilisateurs sont reconnaissants du temps que vous avez donné pour développer le logiciel et veulent vous rendre la pareille.

Vous devrez garder un esprit critique et ne pas forcément accepter toutes les modifications demandées par vos utilisateurs. Écoutez attentivement leurs histoires : elles vous donneront l’occasion d’identifier des problèmes. Mais ce n’est pas parce qu’un utilisateur réclame une fonctionnalité qu’il en a absolument besoin ; peut-être que le meilleur moyen de résoudre le problème sous-jacent est de mettre en place une fonctionnalité complètement différente. Gardez du recul par rapport aux commentaires de vos utilisateurs. Mais cela, vous le saviez probablement déjà.

Et au passage, ne faites pas non plus appel à votre famille.

Je ne dis pas ça méchamment, je suis sûr que vos parents, frères et sœurs sont des gens très bien. Mais si vous créez une application comptable et que votre sœur n’a jamais tenu la moindre comptabilité, elle sera sans doute perdue. Vous perdrez plus de temps à lui expliquer ce qu’est la comptabilité en partie double qu’à tester votre logiciel. Par contre, votre mère, qui s’est acheté un appareil photo numérique l’année dernière, pourrait être un cobaye idéal si vous travaillez sur une application de gestion de photos numériques ou d’envoi sur un site de partage en ligne populaire. Pour votre application de comptabilité, il vaut mieux demander à l’un de vos collègues ou amis qui a déjà quelques notions de comptabilité.

Variez vos cobayes

Pour des raisons qui resteront éternellement mystérieuses, les gens trouveront toujours d’innombrables façons d’utiliser et de maltraiter votre application. Ils trouveront des manières de la casser que vous n’auriez même pas imaginées dans vos pires cauchemars. Certains mettront en place des processus et des méthodes de travail avec votre application qui n’ont absolument aucun sens à vos yeux. Et, de désespoir, vous vous cognerez la tête contre les murs. D’autres utiliseront votre application avec tellement d’intelligence que vous vous en sentirez idiot. Essayez de rencontrer des gens qui utilisent votre application avec des objectifs différents.

Les utilisateurs sont de drôles d’oiseaux. Mais ils sont de votre côté. Apprenez d’eux.

Si vous ne retenez rien d’autre…

… alors retenez ceci :

• Vous serez tenté de modeler l’apparence et le comportement de votre interface sur la façon dont le logiciel fonctionne en coulisses. Vos utilisateurs peuvent vous aider à éviter ce piège.
• Les utilisateurs sont des oiseaux capricieux. Ils vont casser, maltraiter et optimiser votre application à un point que vous ne pouvez pas même pas imaginer.
• Apprenez de vos utilisateurs. Améliorez votre application en fonction de ce que vous avez appris. Vous avez tout à y gagner.

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

Traduction Framalang : peupleLà, SaSha_01, lerouge, Kalupa, lenod, michel, KoS, michel, goofy, HanX, Asta, lamessenJulius22

Mon projet m’a appris à grandir

Runa Bhattacharjee

Depuis 10 ans, Runa Bhattacharjee a traduit et travaillé à la localisation(1) de nombreux projets open source — des interfaces de bureau aux outils de systèmes d’exploitation en passant par beaucoup de choses entre les deux. Elle croit fermement que les dépôts de codes en amont sont les meilleurs endroits pour soumettre toutes les modifications possibles. Elle gère également un portefeuille professionnel spécialisé dans la localisation chez RedHat. Runa traduit et maintient des traductions en Bengali (version indienne) mais est toujours heureuse d’aider quiconque débute dans la localisation.

Introduction

Carburer tard dans la nuit est l’une des formes de rébellion préférée des jeunes partout dans le monde. Que ce soit pour lire un livre avec une lampe de poche sous les couvertures, regarder les rediffusions TV ou (entre autres choses) traîner sur un canal IRC et s’acharner sur un problème agaçant dans son projet open source favori.

Comment tout a commencé

Voici comment tout a commencé pour moi. Permettez-moi d’abord d’écrire quelques lignes sur ma personne. Lorsque j’ai été présentée au groupe d’utilisateurs de Linux de ma ville, je partageais ma vie entre des emplois et mes études de master. Très vite, j’étais devenue contributrice sur quelques projets de localisation et j’avais commencé à traduire des interfaces de bureau (principalement). Nous utilisions des éditeurs de texte personnalisés avec des systèmes intégrés pour l’écriture et les polices. Les moteurs de rendu n’étaient pas assez matures pour afficher le scénario sans erreur sur les interfaces. Mais, malgré tout, nous continuions à traduire. Je me concentrais sur la méthode de travail que j’avais créée pour mon usage. Je récupérais le contenu à traduire des personnes qui savaient comment les choses fonctionnaient, je le traduisais du mieux que je pouvais, j’ajoutais des commentaires pour aider les réviseurs à comprendre comment j’avais appréhendé le texte, je renseignais les informations requises pour les copyrights et les crédits, puis je renvoyais tout ça aux coordinateurs.

Comment je faisais

C’était avant tout une manière simple de faire les choses. Mais, surtout, c’était ma manière à moi de les faire. Je prenais le temps de planifier mon travail sur les traductions. Celles-ci étaient ensuite révisées avant de m’être retournées pour modification. De nouveau, je planifiais quand je pourrais les reprendre en fonction de mon temps libre disponible entre les études et le travail. Lorsque je me mettais finalement au boulot, je m’asseyais pour neuf à dix heures d’un coup, en général jusqu’à l’heure où blanchit la campagne, ressentant alors un grand sentiment d’accomplissement, jusqu’à la fois suivante.

Ce qui comptait

Ce que je ne savais pas, c’est que je jouais un rôle crucial sur un plan plus global. À savoir, la planification des releases(2). Donc, quand j’achevais mes modestes contributions et les envoyais aux autres, je ne prenais pas en compte leur possible inutilité du fait qu’elles arrivaient trop tard pour la version en cours et trop tôt pour la suivante (qui inclurait forcément de nombreux changements qui obligeraient à se remettre au travail). Au-delà de ça, je n’avais aucune idée de l’importance que ça prenait dans le processus de release : intégration, création de paquetages, tests de l’interface, suivi et résolution des bogues.

Comment cela m’a fait grandir

Tout cela a changé radicalement quand je me suis tournée vers un rôle plus professionnel. Subitement, je faisais la même chose mais d’une manière plus structurée. J’ai appris que faire cavalier seul comme j’en avais pris l’habitude n’était pas adapté quand on devait jongler avec deux ou trois versions planifiées. Il fallait être méticuleusement synchronisé avec les feuilles de route des projets. En travaillant sur une traduction d’interface de bureau, je devais aussi vérifier que le calendrier de traduction concordait avec celui du projet principal.

Les travaux devaient idéalement commencer immédiatement après le gel de tous les messages d’origine de l’interface. Les traducteurs pouvaient alors travailler librement jusqu’à l’échéance de la période de traduction, après quoi ils pouvaient marquer la traduction comme stable dans le dépôt principal et, finalement, les paquetages pouvaient être générés. De plus, quelques distributions de systèmes d’exploitation se synchronisaient sur ce calendrier. Les traducteurs avaient donc la responsabilité supplémentaire de s’assurer que les pré-versions des systèmes d’exploitation embarquant ce bureau seraient un minimum testées afin de s’assurer que les traductions de l’interface avaient du sens et ne contenaient pas d’erreur.

Ce que j’aurais dû savoir

La transition ne fut pas aisée. Je fus soudain inondée par un flot d’informations que je devais gérer et par des tâches supplémentaires que je devais réaliser. Ce qui était au départ un passe-temps et plus important encore un anti-stress est devenu tout à coup une affaire sérieuse. En y repensant, je peux dire que cela m’a probablement aidée à comprendre le processus dans son intégralité étant donné que j’ai dû tout apprendre depuis le début. Ainsi armée de cette connaissance, je peux analyser des situations avec une meilleure compréhension de toutes leurs dimensions. Au moment où j’ai commencé à travailler sur les projets open source qui m’intéressaient, il y avait beaucoup moins de professionnels qui travaillaient à plein temps dans ce domaine. La plupart des contributeurs bénévoles travaillaient ailleurs la journée et voyaient ces projets comme un moyen d’alimenter les idées créatives qui s’étiolaient dans leurs tâches quotidiennes. Donc, beaucoup de nouveaux arrivants n’étaient jamais guidés vers une manière plus professionnelle d’organiser leurs projets. Ils ont grandi pour devenir merveilleusement doués dans ce qu’ils faisaient et ont finalement compris comment ils aimeraient équilibrer leur travail avec le reste de leurs activités.

Conclusion

Aujourd’hui, j’encadre les nouveaux arrivants et l’une des premières choses que je leur fais comprendre est comment et dans quelle partie du projet leur travail aura un impact. Élaborer un modèle de travail personnel est essentiel car cela permet de se construire un environnement où il est agréable de travailler. Cependant, avoir conscience de la structure qui est affectée par le travail inculque la discipline nécessaire pour pouvoir tenir bon face aux caprices.

(1) La localisation englobe tout le processus d’adaptation d’un produit logiciel ou documentaire à une région donnée. Cela comprend la traduction dans la langue de la région mais aussi l’adaptation aux normes, à la culture et aux besoins spécifiques de cette région du monde.

(2) Il s’agit de la publication d’un logiciel, sa mise à la disposition du public.

Cette décennie est et sera marquée par le développement tous azimut du matériel libre.

Sera-t-on à terme capable de réellement modifier la donne dans le secteur industriel ?

Difficile à dire aujourd’hui mais rien n’empêche d’essayer, d’explorer, de bidouiller, même dans les secteurs les plus fous comme l’aviation…

MakerPlane : L’open source prend son envol dans l’aviation

MakerPlane: Open source takes flight in aviation

Ted Brunell – 7 janvier 2013 – OpenSourceWay
(Traduction : tibs, Kenoris, RavageJo, KoS, ehsavoie, goofy, lamessen + anonymous)

J’ai parlé avec John Nicol du projet MakerPlane à propos de leur équipe passionnée de contributeurs des quatres coins du monde qui conçoivent et construisent un ULM biplace complet. Leur objectif est de « créer des avions innovants et de changer la donne dans l’avionique et ses systèmes connexes ainsi que dans les procédés de fabrication ».

Quand avez vous entendu parler de l’open source pour la première fois, et qu’est-ce qui vous a le plus impressionné à propos de celui-ci ?

J’ai évolué dans l’industrie de haute technologie depuis plus de 20 ans, à des postes différents, comme vice-président de la branche ingénierie d’une entreprise cotée au NASDAQ à Fremont (Californie), et PDG de mes propres entreprises en Nouvelle-Zélande et au Canada. J’ai donc été confronté à l’open source depuis un certain temps. J’ai utilisé et développé des logiciels et ressources open source tout au long de ma carrière et je continue à le faire pour un autre projet que je mène actuellement (je ne veux pas vendre la mèche, mais j’espère pouvoir publier des logiciels de modélisation 3D open source l’année prochaine).

Ce qui m’impressionne le plus, c’est qu’une communauté intéressée peut grandir et stimuler l’innovation de manière exponentielle. Elle peut devenir autonome et, dans de bonnes conditions, peut être très prolifique. Ce que je veux dire, c’est que de nouveaux développeurs motivés peuvent toujours prendre le relais et apporter de la fraîcheur au logiciel ou au système en cours de développement. Bien sûr, la communauté est la clé de ce genre de projet et c’est là que tout se joue : l’open source peut survivre en dehors des entreprises et sans la présence de personnalités.

Les principes de l’open source sont désormais tout aussi bien ancrés dans le domaine matériel, et j’ai récemment présenté MakerPlane à l’Open Source Hardware Summit (NdT : Sommet du matériel libre) à New York.

Comment est utilisé l’open source dans le projet MakerPlane ?

Pour résumer, nous fournissons du matériel open source et le logiciel dirigeant l’avion « fait maison ». Ce logiciel est toujours en cours de développement, mais il contiendra un système de visualisation électronique (EFIS), qui est une sorte d’ordinateur de bord qui affiche des informations sur le vol et les moteurs. Il contient également des micrologiciels pour des périphériques comme Android et Arduino.

Le matériel se trouve dans deux domaines principaux : l’avionique et l’avion. Les instruments de bord et l’électronique à l’intérieur de l’avion constituent l’avionique. A ce jour, nous avons 24 plans de matériel avionique open source disponibles en téléchargement dans nos dépôts, pour que tout le monde puisse les construire. La gamme de projets s’élargit en permanence. Pour ce qui est des avions, nous sommes en train de concevoir et de construire notre premier ULM open source (un ULM biplace grandeur nature). Nous cherchons à améliorer le design pour qu’il puisse être construit à la maison, grâce à des machines à commande numérique ou des imprimantes 3D. Avec la démocratisation de celles-ci, et la vague du « fait maison », on profite à la fois de la technologie et du matériel de construction à bas prix, indispensables à ceux qui veulent construire leur propre avion.

Les chiffres que nous avons indiquent que 75% des projets de construction d’avion en kit ou à partir de plans sont abandonnés avant d’être terminés. Les entreprises aéronautiques qui fournissent des kits ou des plans font faillite, laissant à l’abandon de nombreux projets. Notre but est de rassembler le plus possible de plans d’avions open source, avec des notices semblables à celles d’IKEA pour les assembler (enfin, en espérant qu’elles soient plus facile à comprendre que celles d’IKEA !). Ces plans, étant open source, seraient disponibles pour quiconque voudrait y accéder, et pourraient survivre aux fondateurs de MakerPlane.

Les gens ont tendance à s’inquiéter quand je parle d’avion open source. Leur principale préoccupation est le fait que n’importe qui peut venir modifier les plans, les rendant du même coup dangereux. Mais un ingénieur en aéronautique est responsable des plans. Comme pour un logiciel open source, il surveille les modifications et aucune ne sera appliquée sans son accord. Bien sûr, tout le monde peut modifier et personnaliser l’avion à sa convenance, et c’est une des principales qualités de l’open source. Cependant, dans 99% des pays, tout avion doit normalement être inspecté par les autorités aériennes ou leurs représentants, avant de recevoir l’autorisation de décoller. Aux Etats-Unis, c’est le rôle de la Federal Aviation Administration (FAA) (Administration Fédérale de l’Aviation). Ces règles sont élaborées pour assurer la sécurité des pilotes, des passagers, et des populations au sol. Vous devez aussi avoir un brevet de pilote, particulièrement pour la catégorie des avions que nous concevons et fabriquons.

Quels sont les défis avec le projet ?

Le financement est le plus gros défi, comme pour la plupart des sociétés à initiatives open source ! De nombreuses personnes n’imaginent sans doute pas qu’un nombre important de projets open source sont financés par des grosses sociétés. La base des mouvements open source semble être toujours sous-financée et nous ne faisons pas exception. La dimension supplémentaire avec nous, c’est que nous avons besoin d’acheter beaucoup de matériel et d’équipements pour arriver à construire un avion. Nous sommes conscients que pour demander des dons et continuer, nous devons faire des progrès et faire voler l’avion. Or nous ne pouvons pas l’envoyer dans les airs sans argent pour acheter les fournitures, c’est donc en quelque sorte un cercle vicieux.

Les modèles commerciaux pour soutenir les initiatives open source sont de fournir des produits et/ou services qui gravitent autour du produit open source libre. Pour aider à financer notre projet nous avons donc ouvert une boutique en ligne et nous y vendons des pièces et des kits pour l’avionique et finalement pour l’avion. Pour le moment l’ensemble de l’entreprise est financé par mes propres économies et cartes de crédits, c’est comme ça. Cela signifie que la progression est plus lente que je le voudrais étant donné que je ne peux malheureusement pas sortir et acheter les pièces quand je le veux. Je voudrais plus que tout avoir une plus grosse machine à commande numérique et une imprimante 3D, mais nous faisons avec ce que j’ai actuellement. Si nous avions le financement, nous aurions sans doute beaucoup plus avancé.

Quel sera selon vous l’impact de MakerPlane sur le monde ?

L’utilisation de technologies de fabrication à domicile change la façon dont les gens font des choses et la vitesse à laquelle ils le font. Une bonne machine-outil à commande numérique peut être faite ou assemblée à partir de kit pour quelques milliers de dollars et une personne peu qualifiée peut utiliser une machine à commande numérique ou une imprimante 3D pour produire quelques objets très précis et le faire de nombreuses fois. Au lieu de prendre une paire d’années pour faire des pièces d’avion, je devrais être capable de découper les pièces en quelques jours, les assembler et terminer avec un avion complet. Je ne veux plus avoir à faire expédier des pièces par un fabriquant ou un distributeur. Je veux pouvoir faire mes propres kits comme j’en ai besoin. J’aurais juste besoin de télécharger un fichier, charger les matériaux dans la machine et les couper. Les méthodes que nous explorons pour assembler l’avion comprennent des fentes et des languettes, ce qui permet aux pièces de ne se monter que dans un sens et sont auto-équerrés. Il est à espérer que de nombreuses techniques permettant de gagner du temps que nous avons appris grâce à MakerPlane trouveront leur place chez les grands constructeurs d’avions en kit.

Comment peut-on s’impliquer dans MakerPlane ?

Il y a plusieurs manière pour les gens de contribuer à notre ambition de changer le monde de l’aviation ! Voici quelques idées :

• Rejoignez le forum MakerPlane et participez aux discussions. Dites-nous quelles sont vos compétences et même si vous ne pouvez pas contribuer directement de façon technique, dites simplement « Salut » et dites nous ce que vous aimez ou n’aimez pas sur les designs.

• Reprenez un projet open source déjà disponible dans le dépôt. De très bons projets ont déjà été envoyés, mais beaucoup ont encore besoin de TLC, de mises à jour, et d’une documentation plus aboutie.

• Commencez un nouveau projet ! Si vous avez une idée géniale pour quelque chose en rapport avec l’aviation open source et quelques compétences pour l’implémenter, ouvrez un nouveau projet sur le dépôt et allez-y ! Si vous avez déjà du code, ou du matériel que vous avez conçu et construit, alors nous serions ravis de le voir dans le dépôt également.

• Parlez de MakerPlane à vos amis, qu’ils soient pilotes ou pas. Aimez notre page Facebook, suivez-nous sur Twitter, partagez, envoyez des courriels, ou des vraies lettres ! Faites passer le mot, pour que nous puissions vraiment construire notre communauté.

• Nous acceptons avec gratitude des dons de pièces détachées, de ressources, et/ou d’argent. Et nous sommes toujours à la recherche de sponsors. Merci beaucoup pour votre aide !

Quel est votre utilisation de l’open source en dehors de votre projet ?

J’utilise quotidiennement OpenOffice pour le travail et Inkscape, Gimp, et Blender de façon plus occasionnelle. J’ai de l’expérience en électronique, donc je m’amuse avec du matériel Arduino open source, et mon téléphone et ma tablette sont bien entendus sous Android. L’open source est partout dans ma vie !

Voir cette vidéo illustrant les étapes de la création d’un prototype de MakerPlane.

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.

• Source : Hadopi : vers une amende systématique de 140 euros ? (Numerama)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

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

Traduction Framalang : lamessen, lerouge, Kalupa, Sky, Astalaseven, Alpha, LuD-up, CoudCoud, peupleLa, goofy

La documentation et moi, avant et après

Anne Gentle

Anne Gentle est une rédactrice technique acharnée et la coordinatrice de la documentation communautaire à Rackspace pour OpenStack, un projet open source d’informatique dans le nuage. Avant de rejoindre OpenStack, Anne travaillait en tant que consultante de publication communautaire, en donnant une direction stratégique aux rédacteurs professionnels qui veulent produire du contenu en ligne sur des wikis contenant des pages et des commentaires générés par les utilisateurs. Sa passion pour les méthodes communautaires de documentation l’a amenée à écrire un livre sur les techniques de publication collaborative pour la documentation technique intitulé Conversation et communauté : la documentation dans le web social. Elle s’occupe aussi bénévolement de la maintenance de la documentation pour les manuels FLOSS qui proposent de la documentation open source pour les projets open source.

Voilà une prémisse bien étrange : vider mes tripes sur ce que j’aurais voulu savoir de l’open source et de la documentation. Plutôt que de vous dire ce que je veux que vous sachiez sur l’open source et la documentation, je dois vous dire ce que j’aurais aimé que mon moi antérieur sache. Cette demande suscite un sentiment de nostalgie ou de remords voire cette horrible énigme : « à quoi pouvais-je bien penser ? ».

En ce qui me concerne, avec juste cinq ans de moins, mon moi antérieur était une trentenaire bien installée dans sa vie professionnelle. D’autres, au contraire, se souviennent qu’ils n’étaient qu’adolescents lors de leurs premières expériences open source. Jono Bacon dans son livre L’art de la Communauté, raconte comment il s’est tenu devant la porte d’un appartement, le cœur battant, alors qu’il était sur le point de rencontrer quelqu’un à qui il n’avait jamais parlé que sur le réseau, par le biais d’une communauté open source. J’ai moi aussi fait cette expérience de la première rencontre physique de gens que j’avais découverts en ligne, mais ma première incursion dans le monde de la documentation open source s’est produite lorsque j’ai répondu à une demande d’aide par courriel.

Le courriel provenait d’un ancien collègue qui me demandait de l’aide pour la documentation de l’ordinateur portable XO, le projet fondateur de l’organisation One Laptop Per Child (un portable pour chaque enfant). J’ai réfléchi à ce que je pensais être une proposition intéressante, j’en ai parlé à mes amis et à mon époux en me demandant si ce n’était pas une bonne occasion d’expérimenter de nouvelles techniques de documentation et d’essayer une chose que je n’avais jamais faite auparavant : une documentation basée sur un wiki. Depuis cette première expérience, j’ai rejoint OpenStack, un projet open source sur une solution d’informatique dans le nuage, et je travaille à plein temps sur la documentation et le support communautaires.

Je pense immédiatement aux nombreuses contradictions que j’ai rencontrées tout au long de la route. J’ai découvert que pour chaque observation il existe des champs et contre-champs surprenants. Par exemple, la documentation est absolument indispensable pour l’aide aux utilisateurs, l’éducation, la possibilité de choisir ou bien la documentation promotionnelle qui amène à adopter un logiciel. Pourtant, une communauté open source pourra continuer d’avancer malgré le manque de documentation ou de la doc complètement défectueuse. Voici une autre collision apparente de valeurs : la documentation pourrait être une très bonne tâche pour démarrer, un point de départ pour les nouveaux volontaires, pourtant les nouveaux membres de la communauté savent si peu de choses qu’il ne leur est pas possible d’écrire ni même d’éditer de manière efficace. En outre les petits nouveaux ne sont pas bien familiers des différents publics auxquels doit servir la documentation.

Ces derniers temps on entend dire un peu partout : « les développeurs devraient écrire la doc de développement » parce qu’ils connaissent bien ce public et par conséquent cela lui serait aussi utile qu’à eux-mêmes. D’après mon expérience, un regard frais et neuf est toujours le bienvenu sur un projet et certaines personnes ont la capacité d’écrire et de partager avec d’autres ce regard frais et empathique. Mais vous n’allez sûrement pas vous mettre à créer une culture « réservée aux novices » autour de la doc parce qu’il est important que des membres essentiels de la communauté technique apportent leur contribution aux efforts de documentation, et qu’ils encouragent aussi les autres à y participer.

Une partie du vilain petit secret sur la documentation des projets open source est qu’il n’existe qu’une frontière pour le moins floue entre leur documentation officielle et leur documentation officieuse. Si seulement j’avais su que les efforts de documentation devraient être sans cesse renouvelés et que de nouveaux sites web pourraient apparaître là où il n’y en avait pas… Une documentation extensive n’est pas le moyen le plus efficace pour s’initier à des projets ou des logiciels mais un parcours sinueux dans les méandres de la documentation sur le Web peut s’avérer plus instructif pour ceux qui veulent lire entre les lignes et avoir ainsi une idée de ce qui se passe dans la communauté grâce à la documentation. Avoir beaucoup de forks(1) et des publics variés peut indiquer que le produit est complexe et qu’il est très suivi. Cela peut aussi signifier que la communauté n’a mis en place aucune pratique quant à la documentation de référence ou que les efforts désorganisés sont la norme.

À mes débuts, j’aurais aimé avoir la capacité de ressentir la « température conviviale » d’une communauté en ligne. Quand vous entrez dans un restaurant rempli de tables nappées de blanc, de couples qui dînent et de conversations feutrées, l’information visuelle et auditive que vous recevez détermine l’ambiance et vous donne quelques indices sur ce que vous vous apprêtez à vivre lors de votre repas. Vous pouvez tout à fait transposer ce concept de température conviviale à une communauté en ligne.

Une communauté open source vous donne quelques indices dans ses listes de discussion, par exemple. Une page de présentation de la liste qui commence par de nombreuses règles et conventions sur la manière de poster indique une gouvernance très stricte. Une liste de discussion qui contient de nombreuses publications mettant l’accent sur le fait qu’il « n’y a pas de question bête » est plus accueillante pour de nouveaux rédacteurs de documentation.

J’aurais aussi aimé connaître un moyen de faire non seulement de l’audit de contenu, c’est-à-dire lister le contenu à disposition pour le projet open source, mais aussi de l’audit de communauté, donc lister les membres influents de la communauté open source, qu’il s’agisse ou non de contributeurs.

Pour terminer, une observation à propos de l’open source et de la documentation que j’ai pu vérifier avec plaisir, c’est l’idée que la rédaction de la documentation peut s’effectuer via des « sprints » — grâce à des de brusques dépenses d’énergie avec un public ciblé et un but précis, pour aboutir à un ensemble documentaire de référence.

J’ai été très contente d’entendre lors d’une conférence à SXSW Interactive que les sprints sont tout à fait acceptables pour la collaboration en ligne, qu’il faut s’attendre à des fluctuations du niveau d’énergie de chacun et que c’est OK. La documentation des logiciels est souvent faite à l’arrache dans les moments d’accalmie d’un cycle de release(2) et ça ne pose aucun problème dans la documentation open source qui est basée sur la communauté. Vous pouvez adopter une approche stratégique et coordonnée et continuer tout de même de proposer des évènements de grande intensité autour de la documentation. Ce sont des moments exaltants dans l’open source et mon ancien moi les a pleinement ressentis. C’est une bonne chose que vous continuiez à passer de votre moi antérieur à votre moi actuel avec un paquet de conseils en poche.

(1) Un fork est un nouveau logiciel créé à partir du code source d’un logiciel existant.

(2) La release est la publication d’un logiciel.

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

Traduction Framalang : peupleLa, goofy, lamessen, SaSha_01, lerouge, Kalupa, RavageJo, lenod, Sky, Astalaseven, Alpha, KoS, purplepsycho +tala

De L’importance des bonnes manières

Rich Bowen

Rich Bowen a travaillé dans le domaine du logiciel libre et open source pendant près de quinze ans. La majeure partie de son travail a porté sur le serveur HTTP Apache ; il a également travaillé sur Perl, PHP et diverses applications web. Il est l’auteur de Apache Cookbook, The Definitive Guide to Apache et divers autres livres. Il fait également de fréquentes apparitions dans diverses conférences sur les technologies.

J’ai commencé à travailler sur le projet de documentation du serveur HTTP Apache en septembre 2000. Du moins, c’est à ce moment-là que j’ai réalisé mon premier commit dans les docs. Auparavant, j’avais présenté quelques corrections par courriel, et quelqu’un d’autre les avait appliquées.

Depuis cette période, j’ai réalisé un peu plus d’un millier de modifications de la documentation du serveur HTTP Apache, ainsi qu’une poignée de modifications du code lui-même. Ceux qui s’impliquent dans les logiciels libres et open source le font pour tout un tas de raisons différentes. Certains tentent de se faire un nom. La plupart essaient de « gratter là où ça les démange » comme ils disent, s’efforçant d’ajouter une fonctionnalité, ou de créer une nouvelle brique logicielle pour satisfaire un de leurs besoins.

Je me suis impliqué dans l’écriture de la documentation sur des logiciels parce que j’avais été enrôlé pour aider à l’écriture d’un livre et que la documentation existante était vraiment horrible. Donc, pour rendre le livre cohérent, j’ai dû discuter avec différentes personnes du projet afin qu’elles contribuent à donner du sens à la documentation. Lors de la rédaction de l’ouvrage, j’ai amélioré la documentation, avant tout pour me faciliter la tâche. À peu près à la même époque, Larry Wall, le créateur du langage de programmation Perl, promouvait l’idée selon laquelle les trois principales qualités d’un programmeur étaient la paresse, l’impatience et l’arrogance. Selon moi, Larry avançait des arguments fondés et avec un sens de l’humour certain. Néanmoins, une partie non négligeable de la communauté des programmeurs a pris ses paroles comme un permis de connerie.

La paresse

Nous écrivons de la documentation pour ne pas avoir à répondre aux mêmes questions tous les jours pour le restant de notre vie. Si la documentation est insuffisante, les gens auront des difficultés à utiliser le logiciel. Bien que cela puisse être la source d’une activité lucrative de consultant, il s’agit aussi du meilleur moyen de faire avorter un projet, car les gens abandonneront, frustrés, et se tourneront alors vers d’autres choses qu’ils n’auront pas à passer des heures pour comprendre.

Ainsi, la paresse est la première vertu d’un rédacteur de documentation. Quand un client pose une question, nous devrions répondre à cette question en profondeur. Et même, de la façon la plus complète possible. Nous devrions alors enregistrer cette réponse pour la postérité. Nous devrions l’enrichir avec des exemples et si possible des diagrammes et des illustrations. Nous devrions nous assurer que le texte est clair, grammaticalement correct et éloquent. Nous devrions alors l’ajouter à la documentation existante dans un endroit facile à trouver et largement référencé partout où quelqu’un pourrait le chercher.

La prochaine fois que quelqu’un posera la même question, nous pourrons lui répondre avec un lien vers la réponse. Et les questions que l’on pourrait poser après l’avoir lue devraient être la source d’améliorations et d’annotations à ce qui a déjà été écrit. C’est la vraie paresse. La paresse ne signifie pas simplement se dérober au travail. Cela veut aussi dire faire le travail si bien qu’il n’aura pas à être refait.

La patience

ll existe une tendance dans le monde de la documentation technique à être impatient et querelleur. Les sources de cette impatience sont nombreuses. Certaines personnes pensent que, comme elles ont dû travailler dur pour comprendre ces choses, vous le devez aussi. Beaucoup d’entre nous dans le monde du technique sommes des autodidactes et nous avons peu de patience pour ceux qui viennent après nous et veulent accéder rapidement au succès. J’aime appeler ça le comportement du « tire-toi de mon chemin ». Ce n’est pas vraiment constructif.

Si vous ne parvenez pas à être patient avec le client, alors vous ne devriez pas être impliqué dans le service clientèle. Si vous vous mettez en colère quand quelqu’un ne comprend pas, vous devriez peut-être laisser quelqu’un d’autre gérer la question.

Bien sûr, c’est très facile à dire, mais beaucoup plus difficile à faire. Si vous êtes un expert sur un sujet particulier, les gens vont inévitablement venir à vous avec leurs questions. Vous êtes obligé d’être patient, mais comment allez-vous y parvenir ? Cela vient avec l’humilité.

L’humilité

J’ai fait de l’assistance technique, en particulier par liste de diffusion, pendant à peu près deux ans, quand j’ai commencé à suivre des conférences techniques. Ces premières années ont été très amusantes. Des idiots venaient sur une liste de diffusion et posaient des questions stupides que des milliers d’autres perdants avaient posées avant eux. Et si seulement ils avaient regardé, ils auraient trouvé toutes les réponses déjà données auparavant. Mais ils étaient trop paresseux et trop bêtes pour le faire.

Ensuite, j’ai assisté à une conférence, et j’ai constaté plusieurs choses. Tout d’abord, j’ai découvert que les personnes qui posaient ces questions étaient des êtres humains. Ils n’étaient pas simplement un bloc de texte écrit noir sur blanc, à espacement fixe. Il s’agissait d’individus. Ils avaient des enfants. Ils avaient des loisirs. Ils connaissaient beaucoup plus de choses que moi sur une grande variété de sujets. J’ai rencontré des gens brillants pour qui la technologie était un outil qui servait à accomplir des choses non techniques. Ils souhaitaient partager leurs recettes avec d’autres cuisiniers. Ils souhaitaient aider les enfants d’Afrique de l’Ouest à apprendre à lire. Ils étaient passionnés de vin et voulaient en apprendre davantage. Ils étaient, en bref, plus intelligents que moi, et mon orgueil était le seul obstacle sur la route de leur succès.

Quand je suis revenu de cette première conférence, j’ai regardé les utilisateurs de listes de diffusion sous un tout autre jour. Ce n’étaient plus des idiots posant des questions stupides, simplement des gens qui avaient besoin d’un peu de mon aide pour pouvoir accomplir une tâche. Pour la plupart, la technologie n’était pas une passion. La technologie était seulement un outil. Il était donc compréhensible qu’ils n’aient pas passé des heures à lire les archives de la liste de diffusion de l’année passée et choisissent plutôt de reposer des questions.

Bien entendu, si un jour les aider devient pénible, la chose la plus polie à faire est de prendre du recul et de laisser quelqu’un d’autre répondre à la question plutôt que de leur dire que ce sont des imbéciles. Mais il faut aussi se rappeler toutes les fois où j’ai eu à poser des questions stupides.

La Politesse et le Respect

En fin de compte, tout cela se résume à la politesse et au respect. J’ai principalement abordé la question de l’assistance technique, mais la documentation n’est rien d’autre qu’une forme statique d’assistance technique. Elle répond aux questions que vous attendez des gens et elle offre des réponses dans une forme semi-permanente à titre de référence.

Lorsque vous écrivez cette documentation, vous devriez essayer de trouver le juste équilibre entre penser que votre lecteur est un idiot et penser qu’il devrait déjà tout savoir. D’un côté, vous lui demandez de s’assurer que l’ordinateur est branché, de l’autre, vous utilisez des mots comme « simplement » et « juste » pour faire comme si chaque tâche était triviale, laissant au lecteur l’impression qu’il n’est pas tout à fait à la hauteur.

Cela implique d’avoir beaucoup de respect et d’empathie pour votre lecteur, en essayant de vous rappeler ce que c’est que de débuter ou d’avoir un niveau intermédiaire dans l’apprentissage d’un nouveau logiciel. Cependant, les exemples de mauvaise documentation sont si répandus qu’il ne doit pas être difficile de s’en souvenir. Il y a des chances que vous en ayez fait l’expérience au cours de la dernière semaine.

J’aurais aimé…

J’aurais aimé être moins arrogant quand j’ai commencé à travailler sur la documentation open source. Quand je relis ce que j’ai pu écrire sur des listes de diffusion archivées publiquement, gravées à jamais dans le marbre d’Internet, j’ai honte d’avoir été aussi grossier.

La plus grande vertu humaine est la politesse. Toutes les autres vertus en découlent. Si vous ne pouvez pas être poli, tout ce que vous accomplirez importera peu.