Les flashs !

Il est 9h du matin, la salle est presque pleine, on a le droit à des tables et malgré la soirée sur la péniche organisée la veille, c’est salle comble ! La liste des intervenants est publié sur cette page wiki.

Le marketing nous a été présenté par Joe Brockmeier non pas comme un sport qu’on regarde mais qu’on pratique ! Une petite blague sur le don du sang a le mérite de bien refléter la situation, si on en demande trop d’une seule personne… vous savez. Nous sommes invités à écrire plus, parler de nos activités à l’extérieur mais aussi à destination de l’équipe Marketing pour qu’elle puisse communiquer pour nous.

Scott Collier d’OpenShift nous a présenté sa préparation sur le support d’Atomic sur Amazon Web Services en nous expliquant les différentes étapes de leur travail, ils cherchent des contributeurs pour tester l’approvisionnement, l’installation sur AWS, lancer des diagnostics et aider à la mise en place.

Second sujet marketing, cette fois-ci mené par Justin W. Flory plus orienté communication interne, au début, le Fedora magazine était focalisé vers les contributeurs, puis vers octobre 2015, lancement du communityblog, focalisé vers les contributeurs afin de répondre à la question : donne une réponse à « qu’est ce qui se passe dans la communauté ces temps ci ? » Idem que flash N°1, peu importe ce qu’on fait, ne pas hésiter à aller voir le community blog pour en parler, voir écrire soi-même !

Loopabull présenté par Adam Miller semble être un moteur d’exécution lançant des instances ansibles. Ils lancent les « book » ansibles à partir de fedmsg afin d’automatiser le plus de chose possible et cherchent à créer de nouvelles connexions pour automatiser plus de sujets.

Kushal Das parle de son projet DGPlug qui fait des cours en ligne pendant 3 mois chaque été où tous les étudiants sont sur IRC. Leur objectif à terme est de convertir des utilisateurs en contributeurs, les cours sont librement accessibles, et vont de l’écriture d’un courriel jusqu’aux langages de programmation, et rassemblent des utilisateurs à travers le monde entier : Inde, Pakistan, Corée, État-Unis, Canada, etc.

Milan Navratil nous parle maintenant de la documentation en cherchant un parallèle entre les LEGO et leur documentation quand on lit un guide d’instruction pour comprendre comment construire une maison LEGO, on comprend facilement, c’est clair, c’est l’idéal de ce que nous devrions réussir à faire. Traditionnellement, la documentation actuelle est trop orientée vers la description de la liste des fonctionnalités, l’archétype est ce qu’on trouve les pages man, mais cela rend difficile le travail du lecteur pour trouver la réponse à ses questions. Donc tentative de changement de paradigme en focalisant sur le cas d’utilisation et l’utilisateur. Nous devons essayer de comprendre ce que l’utilisateur tente de faire et pourquoi, puis le guider. Puis en second sujet dans le même thème, plutôt que de fournir d’énorme pavés, ils cherchent à atteindre une documentation minimalisme.

Le noyau Linux a été évoqué avec Laura Abbott, afin de rappeler que ce n’est pas un domaine inaccessible et qu’il existe par exemple le site http://kernelnewbies.org/ pour entrer dans le sujet plus facilement.

Lors de mon intervention, j’ai rappelé que la majorité des humains n’étaient pas natifs de pays anglophones et qu’aujourd’hui, Fedora est construit de façon verticale, projet par projet. Chaque correction d’un texte passe par la source du projet puis est empaqueté par les mainteneurs puis seulement accessible à l’utilisateur. Cela prend rarement quelques jours, souvent entre 3 semaines et 6 mois. Maintenant quand on regarde l’outil Logiciels de GNOME, plusieurs centaines de description de logiciels sont à traduire, quand arriverons-nous à finir cet énorme travail ? Dans 10 ans ? Nous devons penser une nouvelle façon de produire Fedora, de façon horizontale, par langue.

Pravin Satpute explique que chaque produit est un équilibre entre fournisseurs et consommateurs, ou dans notre cas entre développeurs et utilisateurs. Son souhait est de penser Fedora comme une plateforme comprenant de nombreux produits et de trouver les liens pour renforcer soit la communauté des développeurs soit celle des utilisateurs.

Jens Petersen nous parle désormais du Haskell, langage plutôt orienté pour les mathématiques, avec des dépendances qui sont assez forte et restrictives et nous donne l’explication de ce qui arrive dans Fedora 25.

Un log anglais existe pour cette conférence, accédez-y via meetbot

Documentation

L’atelier de travail organisé par l’équipe de documentation de Fedora et présenté par Paul Frields nous a expliqué la migration de Publican vers AsciiDoc. Aujourd’hui, tout le contenu a été déplacé Pagure, et c’est Pintail qui sera utilisé publier les sites internet. Il y a fort à parier que pendant plusieurs versions de Fedora, les deux formats vont vivre en parallèle, sachant qu’il s’agit probablement le plus gros projet à utiliser Pintail et qu’en conséquence de nombreux soucis surviendront.

Des fichiers dockers vont être diffusés afin d’aider à mettre en place le nécessaire et éviter d’arriver à la situation actuelle où presque personne ne peut publier de nouveaux contenus. Plusieurs interrogations sont soulevées, sachant que la transformation de l’ancien format au nouveau format ne semble pas pouvoir être automatisée. Que fait-on des anciens guides ? Devons-nous tout reprendre et transcrire dans le nouveau format ?

En plus du changement de processus de publication, l’équipe souhaite se réorienter vers une documentation par cas d’utilisation plus que de livres contenant tout, en plus de pointer vers les sources de référence déjà existantes.

Une bonne partie des informations qui sont présentées par Paul Frields qui n’existent pas ailleurs, j’ai demandé à ce qu’il y ait plus d’informations écrites sur le wiki, car il souhaitait attendre l’actualisation du guide du contributeur pour transmettre toutes les informations.

Le retour d’expérience de GNOME pour changer le paradigme c’est de ne rien reprendre et réécrire ! Cela leur a également permit de changer la licence et de repartir depuis une base saine. Les participants considèrent tous que la documentation GNOME est un bon exemple à suivre.

Les débats sont nombreux sur ce que nous devons ou ne pas documenter, qui font partie de la stratégie de documentation que souhaite mettre en œuvre Fedora.

En complément, Paul souhaite impliquer d’avantage les communautés consommatrices de Fedora (downsteam), comme le projet Atomic https://www.ansible.com/. En insistant que le plus important dans une communauté c’est de créer une communauté, en conséquence, la mission de docs c’est de créer une communauté. Dans les problèmes rencontrés aujourd’hui, quand on voit un guide pour Fedora 24, c’est que quelqu’un l’a publié, pas qu’il a été revu et actualisé.

Ma perception que l’équipe de documentation est bien rentré dans le sujet de la publication, mais reste encore en recherche sur le sujet du processus de construction et les objectifs (et évidemment ce n’est pas facile à décider !).

Sur le même sujet, lisez l’article https://dhanvi1.wordpress.com/2016/06/23/example-of-newer-document-writing-for-fedora-docs/

C’est la fin de mes transcriptions francophones

Je vais maintenant écrire sur nos deux propositions concernant la traduction.

Où trouver d’autres transcriptions, éventuellement en anglais ?