MediaWiki ou Drupal/Vardoc

Je travaille à développer un projet de manuel/knowledgebase en ligne. C’est comme une réédition 2.0 d’un guide qui existe déjà, en production maraichère. Je convoite deux plateformes qui sont pas mal faites pour ça, Semantic MediaWiki et Drupal avec la distribution VarDoc.

Au niveau du contenu, on aurait 3 ou 4 niveaux hiérarchiques: Modules > Chapitres > Sections > Pages

Pour l’édition collaborative, ce qu’on a identifié qu’on veut jusqu’à maintenant c’est ça:

  • Accorder droits d’édition à certains usagers, par module/section et par niveau hiérarchique (donner accès à toutes les sections d’un module ou juste à une section)
  • Les suggestions doivent parvenir aux responsables des modules et être liées aux pages (affichées dans le backend)
  • Une section révision/discussion pour chaque page (Slack intégré?)

Maintenant, au niveau du frontend, on veut pouvoir mettre ça très beau et ça doit être flexible. On a prévu afficher les éléments suivants:

Gauche

  • Table des matières du site (avec signet?) rétractable

Milieu

  • Fil d’ariane
  • Auteurs (multiples)
  • Date de dernière modification
  • Corps
  • Pagination (chap. préc / suiv)
  • Carroussel des médias liés (photos, vidéos)
  • Références
  • Voir aussi (liens externes)
  • Commentaires publics

Droite

  • Boîte de recherche
  • Table des matières de la page
  • Imprimer
  • Partager
  • Vos suggestions
  • Autres articles reliés
  • Mots-clés (tag cloud)
  • Cultures? (taxo)

Page d’accueil

  • Les 13 modules
  • Derniers contenus
  • Articles les plus populaires
  • Mots clés les plus populaires

Je pense que la plus grosse différence entre les deux serait le système de révision/discussion pour l’édition collaborative, il faudrait que je les regarde de plus près… Mais sinon, niveau appréciation générale, est-ce qu’il y en a parmi vous qui connaissez les deux systèmes et sauraient me dire les points forts et faibles de l’un et l’autre?

1 « J'aime »

Je ne connais pas profondément ni l’une ni l’autre des plateformes: bien que j’ai de l’expérience en Drupal et Mediawiki, je ne connais pas les extensions en particulier, donc je ne peux me prononcer à leur sujet.

Par contre, je dois dire que j’ai abandonné l’utilisation de logiciels « dynamiques » (e.g. Mediawiki, Drupal, etc) pour construire des manuels. Je préfère maintenant des générateurs de sites statiques. Pour un manuel du genre, je conseillerais peut-être Sphinx et « Read the docs », bien que ça demande une certaine connaissance de Git au préalable, ce qui peut être une limitation catastrophique en terme d’utilisabilité… GitLab ont un « site editor » qui aide un peu à contourner ces limites, mais ça peut être quand même trop difficile à utiliser pour le grand public, malheureusement.

1 « J'aime »

Bonjour @geoffm,

Je suis du même avis que @anarcat. Si c’est pour faire un manuel, mon opinion est qu’un wiki (MediaWiki) ou un CMS (Drupal) sont les mauvais outils. MediaWiki, il est possible de locker certaines pages je pense.

Si le guide/contenu existe déjà, alors, ce contenu va être livré à toi sous forme de fichiers source (*md, *.txt, *.html, *MediaWiki, *tex, …).

L’arborescence aurait l’air de ça:

Manuel-v.2/
                .git/
                README.md
                CODEOWNERS
                Module-X/
                              Chapitre X-1/
                                                      page-1.md
                              Chapitre X-2/
                                                      page-1.md
                              Chapitre X-3/
                                                      page-1.md
                Module-Y/
                              Chapitre Y-1/
                                                      page-1.md
                              Chapitre Y-2/
                                                      page-1.md
                              Chapitre Y-3/
                                                      page-1.md
                              Chapitre Y-4/
                                                      page-1.md
                                                      page-2.md
                Module-Z/
                              Chapitre Z-1/
                                                      page-1.md
                                                      page-2.md
                                                      page-3.md
                              Chapitre Z-2/
                                                      page-1.md

Je recommande l’utilisation d’un format de fichier composable et texte. De tels fichiers peuvent être versionnés avec la plateforme collaborative libre GitLab.

Il y a de beaux outils libres comme:

Typiquement, les changements à une page sont discuté dans la Merge Request.

Il faut, je crois, découpler les tâches suivantes:

  • Préparer l’intrant qui sera utilisé pour générer le manuel (Markdown, fichiers d’entrées Sphjnx, Javadoc, Doxygen)
  • Collaborer avec les générateurs de contenu du manuel (modules, chapitres, sections, pages)
  • Édition du contenu
  • Production du manuel avec un outil comme pandoc
  • Distribution du manuel

Si le contenu existe déjà, l’activité principale sera l’édition de contenu, et le concept de « Merge Request » de GitLab sera pertinent.

Ce qui tu appelles « le frontend » est en fait, je pense, ce que j’appelle « La production et la distribution du manuel ».

Pour cette partie: GitLab !
Tu peux même ajouter une job de « Continuous Delivery (CD) » pour générer le manuel (ou le déployer avec Docker, si c’est une app qui le distribue).

J’ai travaillé avec MediaWiki. Je ne pense pas que ça va être facile de faire ton layout « frontend » avec MediaWiki. MediaWiki ça va bien pour éditer des pages dans le language wiki de MediaWiki, et voir l’historique. Typiquement, chaque page d’un wiki dans MediaWiki a une page de discussion pour les changements proposés pour la page.

Drupal, je n’ai jamais utilisé.

1 « J'aime »

Je pense qu’un générateur de sites statiques serait mon premier choix, sauf évidemment si des non-geeks doivent pouvoir participer à la rédaction. Si la rédaction, la révision et les commentaires doivent passer par une interface web ou une application mobile, MediaWiki et Drupal deviennent plus intéressants. Pour MediaWiki, il faut s’assurer d’installer et d’activer l’éditeur visuel, qui a une dépendance envers parsoid, une patente externe en nodejs, sinon les utilisateurs/trices doivent apprendre le wikicode. Semantic MediaWiki est puissant, mais aussi plus technique. Il faut être certain d’avoir besoin du web sémantique pour l’utiliser à la place de MediaWiki tout court, qui offre à mon avis bien assez de fonctionnalités pour un manuel et/ou une base de connaissances.

Je m’en voudrais de ne pas signaler un autre logiciel libre de type wiki qui est bon pour des manuels et des bases de connaissance : Tiki Wiki.

1 « J'aime »

Quelques clarifications, puisque plusieurs me suggère de créer un site statique et ça ne me semble pas approprié. La plateforme doit être dynamique, elle sera en édition constante avec contributions de la communauté.

On a aussi clarifié davantage ce qu’on voulait comme fonctionnement collaboratif.

  • 1 équipe par module (il y en a 13) appelée « groupe de rédaction »
    • Le groupe de rédaction comprend un pilote (coordonnateur)
    • Les modules ont des sous-éléments: chapitres et sections.
  • Chaque page a sa section discussion, à la wikipédia, ainsi qu’une section modification.
    • La section discussion est ouverte au public (l’édition peut être réservée aux comptes utilisateurs sans droits particuliers)
    • Les membres du groupe de rédaction doivent pouvoir contrôler le niveau de notifications qu’ils veulent recevoir quand il y a du nouveau dans les discussions dans les sections du module.
  • On peut donner des droits d’édition (du contenu, directement) à des collaborateurs (un rôle) mais leurs changements ne sont pas publiés, ils sont vérifiés par des membres du groupe de rédaction pour ce module.
    • Leurs suggestions d’éditions doivent être validées par le groupe de rédaction.
    • Le pilote doit être notifié dune soumission d’édition
  • Un tableau de bord doit présenter aux membres du groupe de rédaction les derniers changements aux discussions ou aux contenus dont ils sont responsables.

Merci pour vous suggestions

2 « J'aime »

As-tu décidé quelle plateforme web tu vas utiliser pour réaliser ton projet ?

Voici globalement comment Tiki Wiki CMS Groupware (tiki.org) se distingue:

Et voici les fonctionnalités demandées:

Tiki.org fait partie de WikiSuite.org, qui représente plus de US$50 million de développement:
https://wikisuite.org/50-millions

Au plaisir,

Marc
Fondateur, WikiSuite.org
Admin, Tiki.org

Regardez aussi parmi ces projets (et le reste de la page):

Je pensais à Bookstack, entre autres.