Priorisation des chantiers du wiki

A la suite de la réunion du 26 juin 2017, voici comment ont été priorisés les différents chantiers envisagés. Les chantiers sont répartis en catégories en fonction des personnes susceptibles d'intervenir dessus. Ils sont ordonnés dans chaque grande partie du plus prioritaire au moins prioritaire.

A l'heure actuelle le nombre de pages à lire avant de pouvoir participer au wiki est de nature dissuasif:

• Comment participer et améliorer cette documentation ?
• Ligne éditoriale de la documentation
• Ligne éthique de la documentation
• Syntaxe de mise en page
• Liste des pages modèles
• Mini-tutoriels
• Ce qu'il faut vérifier pour savoir si une page est conforme aux règles du Wiki

L'idée est de proposer un tutoriel simplifié au strict minimum permettant de comprendre comment rédiger une page harmonisée avec les règles du wiki et de renvoyer vers des pages qui permettent de creuser chaque thématique lorsque les gens se posent des questions. Ce tutoriel devra au maximum éviter de lister des possibilités et de distinguer des cas de figure: il faut être synthétique et aller droit au but.

Le mini tutoriel avec les droits d'administration existe déjà. Il renvoie vers la page sudo. Au début du chantier, le contenu de cette page correspondait à l'actuel tutoriel Sudo : effectuez des tâches administratives, où il a été déplacé depuis. En effet l'idée était que la page sudo référencée par le mini tutoriel devait expliquer le concept de manière simplifiée et allant à l'essentiel, de manière à se rendre accessible aux débutants, tout en renvoyant vers une page plus détaillée pour ceux qui ont besoin de creuser.

Le contenu actuel de la page sudo correspond donc au consensus élaboré au cours du présent chantier, et mergé dans la documentation principale en date du 21/08/2017. Pour parfaire ce chantier, il reste à finaliser la page Sudo : effectuez des tâches administratives, qui a besoin d'être actualisée notamment à cause des bonnes pratiques qui ont évolué sur la manière de lancer une application graphique.

Il s'agit de lister l'ensemble des ressources francophones autour d'Ubuntu qui sont externes à la documentation.

Ce chantier est un prérequis à l'effort, voulu par l'équipe de coordination de recentrer le wiki sur ce qui est spécifique à Ubuntu, moins généraliste, et plus facile à maintenir. Il va permettre de répertorier les ressources francophones sur le monde de linux vers lesquelles on peut renvoyer au lieu de refaire en moins bien sur le wiki (particulièrement pertinent lorsqu'il s'agit du site officiel d'une technologie, par essence plus à jour qu'une page de wiki miroir).

Accessoirement ce chantier est aussi un prérequis pour le chantier du méta moteur de recherche qui permettra de rechercher aussi bien sur le wiki que sur le forum ou sur une liste de ressources pertinentes.

Le chantier est déjà démarré, les contributeurs sont invités à ajouter les ressources dont ils pourraient avoir connaissance sur ce framapad.

Ce chantier n'est pas vraiment nouveau, c'est un processus continu qui est relancé à chaque nouvelle sortie. Il y a une page pour décrire ce qu'il faut faire: Tags des anciennes versions d'Ubuntu. Ce qui est nouveau c'est qu'il est désormais acté comme mauvaise pratique d'ajouter sur une page un tag de version non LTS, sauf dans le cas où aucune LTS ne supporte encore ce qui est décrit.

Ce chantier suppose que des contributeurs qui sont là depuis un petit moment et qui connaissent bien le wiki se portent volontaires pour aider les administrateurs en apportant leur expertise sur la liste et en encadrant les nouveaux. Ca permettrait aussi de mettre éventuellement en place ponctuellement un système de parrainage. Se renseigner auprès de l'équipe d'administration.

NB: Au final l'équipe a renoncé à mettre en place des modérateurs, préférant le concept de "Contributeur chevronné" afin d'instaurer une dynamique dans laquelle les membres de cette équipe de confirmés aident les nouveaux mais sans se sentir en responsabilité vis à vis de l'équipe.

Pour comprendre les raisons qui motivent ce chantier, se reporter au paragraphe "à propos des scripts" du Compte rendu de la réunion du 26 juin 2017.

Les scripts sont a proscrire de la doc. Il a été acté qu'il valait mieux préconiser à toute personne souhaitant ajouter un script dans la doc d'ouvrir en lieu et place un topic dédié à son script sur le forum, puis de mettre le lien vers ce topic dans la doc. Il a été envisagé de proposer un cartouche commun pour standardiser la présentation des scripts.

Deux questions restent en suspens:

• Que faire des scripts existants? (le plus simple étant qu'un contributeur fasse le transfert vers le forum)
• En cas d'export de la doc il faudra s'assurer que les scripts soient embarqués. Cette contrainte pourrait mener à un choix alternatif au forum pour le lieu d'hébergement des scripts.

L'idée est de placer un cartouche en haut des pages de la doc pour inciter les lecteurs à participer. Le contenu est à définir, ainsi que la forme. Potentielle dépendance vis à vis du chantier design.

L'idée est de mettre en place des scripts qui effectueraient certaines tâches automatiques. Par exemple enlever les images obsolètes, mettre les espaces insécables dans la ponctuation qui le nécessite, corriger les tags mal orthographiés, corriger les balises mal fermées (cas des balises italiques en fin de page par ex.). La manière standard de procéder serait a priori de passer par un plugin dokuwiki

Dans l'idéal il faudrait qu'un contributeur intéressé dans dokuwiki déploie une version locale de la doc (avec le support des admins), puis regarde comment il pourrait être possible de sélectionner un tag de version et que partant de là seules les pages portant ce tag soient accessibles. Le besoin et les priorités de ce chantier sont trop vagues. A creuser ou à abandonner.

Évaluer la possibilité de figer la documentation à chaque version dans une branche garage gelée (à la façon svn). Ainsi les pages ou remarques obsolètes peuvent être supprimées sans scrupules dans les pages de la nouvelle version. Par exemple on pourrait, au moment de la sortie de la 18.04, copier coller toute la doc dans un répertoire archive en lecture seule. Ce qui permettra de supprimer sans remord les pages périmées en sachant qu'au pire il reste possible d'en retrouver le contenu.

Il y aurait aussi la solution de faire un gel partiel, consistant à déplacer toutes les pages supprimées mais non dangereuses dans une archive en lecture seule avec un cartouche avertissant que le contenu est à prendre avec des pincettes car non mis à jour.

A l'heure actuelle l'archive ZIM permettant de consulter la doc hors ligne est générée manuellement, ce qui explique son rythme de release très espacée. L'idée serait de mettre en place une régénération automatique et d'étudier d'autres solutions d'export de pages, par exemple au moyen de plugins adéquats

Le certificat de sécurité de https://tour.ubuntu-fr.org/fr/index.html est expiré depuis le 20 mai. Il faudrait le renouveler et envisager de le mettre à jour vers une version récente d’ubuntu (au lieu de la 14.04 actuellement)

Il va s'agir de tester et ajouter les plugins dokuwiki suggérés.

Dans le cas de l'onglet discussion, voici un exemple de wiki dokuwiki qui l'implémente.

Ce plugin peut faire crasher le navigateur du fait du trop grand nombre de pages qui sont orphelines.

Il s'agit de mieux expliquer en quoi consiste le boulot d'un admin de la doc afin de peut être susciter des vocations. Il pourrait être intéressant au passage de creuser la notion de modérateur qui a été proposée en réunion et d'étudier qu'elles seraient les prérogatives associées (ce rang existe déjà dans dokuwiki mais nous ne l'utilisons pas à date

Il s'agissait d'opérer la mise à jour vers la version la plus récente de dokuwiki. Ce chantier a déjà été mené à bien.

On souhaite que la présentation du wiki s'adapte automatiquement en fonction de la taille de l'écran de l'utilisateur. Avec la dernière version de dokuwiki, le thème par défaut est responsive, mais pas le thème actuel du wiki. Voir la page Chantier Responsive Design pour plus d'infos

En coordination avec le chantier Lister les ressources externes sur Ubuntu. L'idée est d'avoir un moteur de recherche interne qui indexe aussi bien le wiki, le forum, et des sites externes comportant des ressources francophones sur l'écosystème Linux, et qu'il soit possible de rechercher dans tous ces supports en même temps.