Structuration des infos sur le grand jardin

Salut,

Suite à un échange avec anna ce jour:

  • il y’a profusion de groupe sur facebook en ce moment, on aimerait bien que ça se passe ici plutôt que sur FB, et pour ça l’élement différenciant serait la capacité qu’on offre à une communauté de structurer ces infos.

  • c’était pas stratégique par rapport au développement du Moooc, et en même temps avec le confinement ça le devient un peu plus…alors comment faire ?

    pour l’instant on a plusieurs options à proposer pour faire ça, mais nos pratiques sont pas calées, alors c’est le bordel :

  • le wiki natif de humhub: c’est difficile de structurer du contenu et de rendre ça joli, car soit on un index moche mais pratique, soit on fait des pages de gardes mais on a pas d’index…est ce qu’on pourrait pas faire en sorte que : sous la page qu’on aurait défini comme page de garde, appparaissent l’index ? et que le descriptif des pages qu’on a définit comme catagorie apparaissent aussi. ça nous permettrait de beaucoup améliorer l’érgonomie du wiki.

  • Yeswiki en iframe ça serait top mais c’est là aussi un sacré truc à prendre en main

  • ou peut être avec codimd ?? mais pour ça faudrait qu’on le prenne en main ???

  • on a aussi les googldes doc qu’on utilise beaucoup, avec la perspective de passer sur nextcloud / onlyoffice

Bref, est-ce qu’il faudrait pas se faire une réunion anna, adrien, marc et moi pour essayer de poser ça, en mode simple mais efficace en attendant d’avoir mieux ?

Ah oui et dernière question: comment on fait pour mettre plusieurs modules wikis dans un espace?

@MarcFarre

sous la page qu’on aurait défini comme page de garde, appparaissent l’index ?

Possible oui

que le descriptif des pages qu’on a définit comme catagorie apparaissent aussi

Possible également

On peut aussi faire un peu de CSS pour embellir cet index, je peux tenter quelque chose bien que je sois pas un grand artiste…

plusieurs modules wikis dans un espace

C’est pas possible. Par contre, il est possible de créer onglets avec le module custom page qui redirigent vers une page spécifique du wiki qui elle même peut contenir tous les liens vers les pages de ce “sous wiki”. Mais pas d’index possible dans ce cas bien sûr puisqu’il n’y a qu’un index par wiki.

Et pour les 2 premiers c’est long/ça coute cher ou c’est déjà prévu dans l’outil ?

Toujours difficile de dire tant qu’on l’a pas fait (non c’est pas prévu dans l’outil), mais en théorie c’est faisable assez facilement, je dirais un heure de boulot, peut-être moins

Hello !

Je suis complètement d’accord, c’est important en ces temps de confinement de passer un peu de temps sur cette partie Co-Création de ressources/base de connaissance. C’est un sujet central des Jdn et, comme le dit Romain, ça sera plus plus la pratique interne que la fonctionnalité qui va nous différencier de facebook.
Cependant même s’il n’est pas l’essentiel, l’outil me paraît important. On dit bien que notre langue constitue et façonne notre pensée (théorie reprise notamment dans 1984 mais remise en cause aujourd’hui). Par analogie, je dirais que l’outil a une incidence sur ce qu’il produit et notamment sur sa structuration.
C’est d’ailleurs la raison pour laquelle, j’exclue les outils de type traitement de texte tel Google Doc. Les documents produits ne sont pas assez structurés et laissent libre court à chacun pour sa mise en forme => l’outil en plus d’être structurant, doit pouvoir créer des documents uniformisés/standardisés. Imaginerait-on le contenu de Wikipédia rédigé avec un traitement de texte ?

Voici la liste des outils dont nous avons déjà parlé, avec selon moi, leurs points négatifs et positifs :

  • Google Doc (ou plutôt son équivalent sous NextCloud : Only office)
    - - - mise en forme libre / pas assez structurant
    - application orientée édition, moins adaptée pour la visualisation
    - on perd qui a fait quoi une fois les suggestions intégrées
    + éditeur WYSIWYG « what you see is what you get »
    + édition en temps réel
    ++ commentaires possibles sur une partie de texte
  • YesWiki
    - - syntaxe vraiment trop compliquée (moins que Wikipédia, mais non adaptée toutefois aux jardiniers)
    - pas de commentaires sur une partie de texte
    - pas de temps réel (perte d’information si 2 jardiniers modifient au même moment)
    + possibilité de proposer des formulaires pour de la donnée très structurée
  • module Wiki de HumHub
    - visualisation pas très jolie (améliorable toutefois)
    - pas de commentaires sur une partie de texte
    - pas de temps réel (perte d’information si 2 jardiniers modifient au même moment)
    + éditeur WYSIWYG « what you see is what you get »
    + syntaxe cachée derrière le WYSIWYG mais le contenu est écrit avec le standard Markdown
  • CodiMd
    - syntaxe à utiliser pour la rédaction (toutefois, on peut utiliser une barre d’outil pour l’écrire et on a une visualisation en temps réel sur le volet d’à côté)
    - pas de commentaires sur une partie de texte (fonctionnalité intégrée aujourd’hui dans la version entreprise, et certainement disponible prochainement dans la version libre)
    + édition en temps réel
    + standard Markdown utilisé et rendu uniformisé
    + un mode visualisation agréable
    + une fois la syntaxe adoptée, l’édition est plus rapide et agréable que la saisie de texte dans HumHub
    + on garde la trace de qui a écrit telle ligne dans un document

Ainsi, j’ai perso une bonne préférence pour CodiMd. Tout l’enjeu va être d’avoir votre retour en tant qu’utilisateurs.
Nous avons travaillé ce week-end avec Marc pour pouvoir vous faire une proposition en ce sens. Cf le post que je vais écrire tout à l’heure pour les tests.

@RomainVignes

ouaou merci! Suis super “blindée” cette semaine… et je me sens nulle pour décider la dessus. COmment puis je contribuer?

A mon avis, tu es très importante pour contribuer là dessus pour l’aspect “utilisateurice” qui a la flemme de la technique (pour résumé, car je sais que toi tu fais l’effort, mais c’est un effort).

Oui @AnnaCruaud , tu peux contribuer en donnant tes retours par rapport à l’outil qu’on a mis en place avec Marc !! :smile:
Et justement par rapport à ton rôle et ton implication dans les ressources qui sont déjà structurées dans la salle commune, ton retour me semble primordial !! et +1 avec ce que dit @Marlène.

J’ai commencé à faire le test. Je ferais mes commentaires au final. J’ajoute juste un axé à la réflexion depuis mon rôle fabrique des communs: on peux distinguer la partie curation communautaire ( inventorier des ressources dans des ensembles cohérents plus grand comme par exemple: une fiche qui présente les grands principes d’un processus d’inclusion avec des liens vers des fiches animations) et des communs structurés/éditorialistes par un noyau restreint type forge. L’un nourrit l’autre mais on peu peut-être avoir un outil très simple d’utilisation et peu structuré, mais utilisé par beaucoup et qui génére de la conversation (exemple le wiki humhub) et un outil type forge beaucoup plus structuré à utiliser par des personnes avec un rôle, formés et coordonnés entre eux…je dis ça pour ouvrir la réflexion et trouver une 3ème voie à ce dilemme

Je viens de lire les différents commentaires et surtout la problématique telle que posée initialement

il y’a profusion de groupe sur facebook en ce moment, on aimerait bien que ça se passe ici plutôt que sur FB, et pour ça l’élement différenciant serait la capacité qu’on offre à une communauté de structurer ces infos.

Voici en général l’approche que je conseille des groupes dans le choix d’un outil.

  1. Utiliser l’outil essentiellement pour ce à quoi il a été conçu. Exemple : Google Doc est conçu pour co-écrire des documents. Un usage déterminé est d’utiliser Google Drive ensuite pour regrouper des Googles Doc et faire une base de connaissance. Cela reste un usage détourné qui montrera des limites mais permet de mettre le pied à l’étrier (rester dans l’action). C’est ce qui se passe ici avec la fonction Wiki de Humbub mais vous en touchez les limites.
  2. Créer une intelligence entre les outils. Et la première des intelligences est celle des Hommes. Exemple : un outil permet de discuter et partager des ressources comme HumHub le réseau social. Un autre permet de structurer, répertorier et documenter : un outil type wiki. Il faut alors utiliser l’intelligence des Hommes en la stimulant par des formations, animations, conseils, … pour que l’information transite d’un outil à l’autre efficacement et avec sens. Si on prend l’exemple de OpenStreetMap : l’intelligence des Hommes est celle de partir sur le terrain puis organiser un mapathon. Petit à petit les personnes deviennent autonome.
  3. Une fois l’intelligence des Hommes en action, il est possible de percevoir les principaux puis les automatiser. Pour arriver à ce troisième point il faut s’assurer en amont que des API sont disponibles pour programmer l’automatisation des flux.

Donc si on en revient au sujet initial et aux propositions faites. Je proposerais donc plutôt un YesWiki ou un CodiMD. Il y a aussi xWiki : https://xwiki.com/fr/fonctionnalites-cles/ (Open Source too).

Puis j’aurais envie de poser la problématique différemment. Car peut-être que le problème n’est pas l’outil de structuration de l’information.

Par rapport à la problématique initiale, la piste envisagée est celle d’attirer les personnes sur HumHub par une base de connaissances. Mais est-ce que pour autant ils partageront plutôt sur les espaces de discussion mis à disposition ?

Les personnes qui partagent des ressources utilisent toujours leur canal préférentiel. Il est préférentiel pour pleins de raisons propres à chacun (car je veux toucher du monde, car la communauté potentiellement intéressée est plutôt là, car l’outil est sur mobile et je n’ai pas d’ordi, car …). Vouloir que les partages se passent d’abord ici plutôt que sur Facebook c’est un énorme travail sur lequel j’aurais du mal à parier.

J’aurais donc envie de reformuler en deux problématiques :

Comment faire plus participer les personnes présentes dans des groupes Facebook à partager dans le grand jardin ?

Comment faciliter la création et l’amélioration continue d’une base de connaissances communes ?

Merci @LaurentChedanne pour ces réflexions pertinentes.

Personnellement, je conseille surtout la simplicité et le mimétisme avec les outils que les gens ont l’habitude d’utiliser (Facebook et Word).

Ce qu’il faut savoir :

  • il est possible d’améliorer le module Wiki de Humhub car je maîtrise bien ce code
  • bien qu’intégré dans la plateforme, il peut être consulté sans avoir à créer de compte et même si on le souhaite sur une URL dédiée, comme si c’était un Wiki à lui tout seul

Améliorations possible (nécessite du dev de ma part) :

  • Créer une API permettant de à d’autres applis externes de récupérer le contenu automatiquement
  • Permettre de voir qui a écrit quoi (par exemple etherpad affiche une couleur différente pour chaque personne)
  • Améliorer la présentation
  • Permettre d’éditer des pages sans compte comme YesWiki (ce que je ne conseille pas, mais possible)

Ce qui serait plus difficile à faire évoluer :

  • améliorer l’éditeur de texte (concernant les puces, ils vont y bosser pour améliorer le problème d’indentation).
  • permettre l’édition à plusieurs simultanément (par contre on pourrait afficher un avertissement aux autres si quelqu’un est en train d’éditer)

Quels sont les autres inconvénients à utiliser le wiki de Humhub ?

Autre point dont on ne parle jamais : on sait tous que le web génère du CO2. D’une appli à l’autre, pour faire à peu près la même chose, il peut y avoir un facteur 100 voire plus de consommation de ressources systèmes. Donc je plaide toujours pour des applis légères. Or les wiki permettant d’éditer à plusieurs en même temps sont très demandeuses en ressources.

Je trouve cela chouette comme approche car elle relie les deux questions. Et la solution réside aussi dans les ressources disponibles pour la mettre en œuvre et apparemment tu es un super atout :smiley:

Comment faciliter la création et l’amélioration continue d’une base de connaissances communes ?

Actuellement j’accompagne un réseau de coopérative pour amener plus de personnes à contribuer sur leur système de documentation centrale. Cette expérience m’a amené à un constat : ils sont toujours peu nombreux à avoir la capacité (et la motivation) de se libérer du temps pour cela. La stratégie repose donc sur l’animation d’un noyau dur de contributeurs qui remontent ce qui est à documenter + des temps de rencontre et de partage (en synchrone) apportant de la matière pour ces contributeurs. Avec ce que tu proposes, cela permet de soutenir un noyau de contributeur en prenant soin de leurs principales difficultés :

  • Permettre de voir qui a écrit quoi
  • Améliorer l’éditeur de texte

Comment faire plus participer les personnes présentes dans des groupes Facebook à partager dans le grand jardin ?

Cette liste de propositions est top :

  • Améliorer la présentation
  • Créer une API permettant à d’autres applis externes de récupérer le contenu automatiquement
  • Consulter le wiki sans avoir de compte : cela permet à l’extérieur de découvrir ou redécouvrir que le grand jardin est là et avec une invitation bien présentée à se connecter / créer un compte pour commenter le contenu, ce serait top (peut-être que cela existe, je ne suis pas un familier).

Je partage aussi ton conseil : ne pas permettre d’éditer des pages sans compte comme YesWiki.

A mon avis, le noyau dur est composé de personnes participant activement sur le HumHub. Donc la priorité serait de faciliter la rédaction en restant sur HumHub. Côté présentation, là il y aurait un choix stratégique à faire qui implique des compétences de dev différentes.

  1. Le contenu est toujours présenté plus ou moins sommairement dans HumHub pour satisfaire le besoin de ceux y naviguant mais sans en faire des tonnes. En parallèle un effort est fait pour synchronisé ce contenu markdown (de HumHub vers extérieur). Un moteur de rendu propose une consultation agréable et publique à l’extérieur en invitant à contribuer sur le grand jardin. Les solutions pour cela ne manquent pas et je peux aider à les identifier si cette stratégie est préférée.
  2. Le contenu n’est présenté que via HumHub et un travail pour facilitation la consultation publique est entrepris.

Dans les deux cas, une consultation agréable égale :

  • Pouvoir rechercher facilement dans le contenu via mots clés (sans avoir des résultats d’autres trucs dans HumHub)
  • Etre capable à tout moment de se repérer où l’on est dans la documentation quand on la consulte
  • Rendre la lecture agréable (police adaptée, texte aéré et texte ne se lisant pas au kilomètre d’un bout de l’écran à l’autre).

En tout cas chouette réflexion car c’est un problème épineux pour beaucoup de réseaux !

Merci @LaurentChedanne ! Tout à fait d’accord avec ta réflexion.

Compléments d’infos :

  • les pages du wiki de Humhub sont stockées dans la base de données en pur Markdown. Donc si on fait une API permettant de partager le contenu à l’extérieur, on enverra le contenu en Markdown
  • Moteur de recherche : en effet, celui de Humhub mélange tout et en plus les résultats de la recherche ne sont pas terrible. Mais il est possible de créer un moteur de recherche dans le Wiki, ce serait pas bien compliqué vu que le contenu est bien structuré dans la base de données.
  • Se repérer : en effet, on devrait afficher un fil d’ariane (breadcrumb) pour indiquer où nous sommes dans l’index (facile à faire).
  • Rendre la lecture agréable : n’importe quelle personne qui maîtrise CSS et a des talents de graphisme est capable de nous améliorer ça

Du coup, si on fait tout ça, ce serait peut-être intéressant de voir si d’autres structures seraient intéressées pour mutualiser le coût de ces devs car, même si techniquement je sais faire tout ça, je demande une rémunération de 20 euros de l’heure ce qui peut être lourd pour les JdN seuls.

Concernant le dev “Permettre de voir qui a écrit quoi” je pense pouvoir demander une contribution à SEVE, l’autre asso qui me rémunère pour une plateforme Humhub. Mais pas pour le reste, ça ne les intéressera pas. Je pourrai voir avec l’équipe de Humhub aussi peut-être si on peut faire quelque chose ensemble.

Super idée le moteur de recherche dans le wiki… Je peste à chaque recherche que je fais ca tombe a coté….

Pour le reste je comprend pas grand chose :wink:

J’aime beaucoup la teneur de vos échanges, et tes apports Laurent quand tu essayes de repositionner la problématique.

  1. Utiliser l’outil essentiellement pour ce à quoi il a été conçu

Je rajouterai à ce conseil « et à quel type d’utilisateur il est destiné ». Au niveau des outils, nous avons deux extrêmes : l’outil GitLab, forge destinée à des développeurs et le traitement de texte en ligne destiné au grand public. Notre objectif d’élaboration de communs nous rapproche dans la pratique de ce que GitLab permet de faire, mais nous voudrions également toucher un public novice au niveau des outils numériques.
Le curseur est à placer entre ces deux extrémités, et sur cette ligne nous pourrions positionner :

[+ développeur] ——-GitLab ———YesWiki———CodiMD ——— wiki d’HumHub(ou Xwiki) ——- [+ novice]

La difficulté réside dans le fait qu’il n’existe pas à ma connaissance de solution de type “forge à documents”, et nous essayons donc de bricoler une solution afin qu’elle soit le plus accessible possible.

Une autre difficulté est que nous n’avons pas encore une vision claire de l’organisation que nous voulons mettre en place, des process internes pour aboutir à l’élaboration de ces communs. Et déjà très globalement : est-ce que nous voulons compter sur un petit noyau de personnes qui vont récupérer la matière et la compiler dans des documents ou nous voulons que toute personne sans aucun pré-requis puisse contribuer ?

CodiMD, me semblait un bon candidat, proche d’une forge tout en s’ouvrant au grand public car il démocratise grandement l’usage de la syntaxe markdown réservé jusqu’alors aux développeurs. Or puisqu’il nécessite un minimum de prise en main, il pourrait convenir à un petit noyau de personnes qui se chargent de mettre en forme ce que leur signale la communauté comme ressources (les ressources sont discutées/signalées dans des posts par exemple). Ce que m’enseigne ces tests, c’est que notre équipe a plus la vision d’un outil qui soit le plus simple possible afin que tout un chacun puisse y contribuer. Peut-être pas non plus sans aucun prérequis, car les contributeurs devront respecter certaines règles co-construite pour la forge, mais qu’ils ne doivent pas avoir en plus à consulter un guide d’utilisation pour pouvoir manier l’outil.

Les priorités étant éclaircies, le wiki d’HumHub semble le plus adapté à nos besoins, même si pour mieux les couvrir, nous devrons le faire évoluer petit à petit avec l’aide de Marc.

  1. Créer une intelligence entre les outils.

Cet aspect est important dans le contexte d’une forge car il est nécessaire d’établir des process pour pouvoir proposer/élaborer/bonifier des communs. A la fois, HumHub nous permet de regrouper plusieurs outils qui judicieusement utilisés nous aiderait à ce travail coopératif, et à la fois sa dimension sociale est mise au profit de ce projet fédérateur. Comme tu nous témoignes, Laurent, dans ton expérience de réseau de coopérative, le “comment amener plus de personnes à contribuer ?” (qui rejoint “Comment faciliter la création et l’amélioration continue d’une base de connaissances communes ?”) est le nerf de la guerre. Nous avons, déjà un réseau, une plateforme La grand Jardin, et des utilisateurs mais il manque je crois, des raisons, des objectifs communs pour faire davantage vivre cette plateforme. Humhub semble donc l’endroit idéal pour porter cette dimension humaine qui motive les contributeurs : mettre en avant le travail et l’investissement de chacun (mise en place de liste des contributeurs, de statuts de reconnaissance dans la communauté…), proposer des défis, organiser des journées après-midi de co-working à distance, mettre en place des rdv présentiels : les Common’s party…

  1. Une fois l’intelligence des Hommes en action, il est possible de percevoir les principaux ??? puis les automatiser.

Flux ? Process ? Ca me paraît en tout cas important d’être agile, d’améliorer petit à petit les outils et process afin que l’intelligence soit davantage mis aux endroits nécessaires. Comme nous en discutions avec Romain, il peut y avoir à terme plusieurs niveaux de contribution à cette forge : un premier niveau avec un outil accessible à tous, et un autre avec un outil plus structurant réservé à un petit noyau d’initiés. Bien entendu, chaque niveau pourra disposer d’API pour s’échanger facilement les infos nécessaires. Je vois ce deuxième niveau comme un agrégateur d’infos venant de plusieurs sources, et notamment d’autres réseaux pour permettre de mutualiser. Le projet inter-orga “Tour de Babel” sur lequel Yannick et Romain ont collaboré ces derniers temps pourrait par exemple être intégré à ce niveau puisque cela concerne des fiches “outils d’animation” plus structurés (chaque fiche partage une même structure et des listes de référentiel).
Au niveau de l’outil, YesWiki serait ici plus adaptée que CodiMd de par sa customisation facile et sa gestion intégrée de formulaire de saisie (+ le fait que nous utilisons déjà bcp et que nous contribuons à ses devs).

Puis concernant :

Par rapport à la problématique initiale, la piste envisagée est celle d’attirer les personnes sur HumHub par une base de connaissances. Mais est-ce que pour autant ils partageront plutôt sur les espaces de discussion mis à disposition ?

Les personnes qui partagent des ressources utilisent toujours leur canal préférentiel. Il est préférentiel pour pleins de raisons propres à chacun (car je veux toucher du monde, car la communauté potentiellement intéressée est plutôt là, car l’outil est sur mobile et je n’ai pas d’ordi, car …). Vouloir que les partages se passent d’abord ici plutôt que sur Facebook c’est un énorme travail sur lequel j’aurais du mal à parier.

+1, et ta reformulation de problématique rejoint nos dernières réflexions à ce sujet. Cf la réponse de Romain sur le post “Mobiliser les communautés à venir sur les Jardins” de Christine Marsan.

Pour le reste, je suis complètement d’accord avec vos propositions de fonctionnalités, mais il me semblait plus important de prendre le temps de clarifier ce que j’ai perçu de nos besoins avant de descendre au niveau des fonctionnalités/priorités/moyens. J’ai toutefois noté ici dans notre bac à sable des idées l’ensemble de vos propositions (feel free to comment).

Ok merci de ce retour. Et que dis tu de spécifier 2 usages, 2 types de contributeurs et donc 2 outils:

  • La curation de connaissance (en gros cartographier des ressources existantes, écrire des textes très simples de retours d’expérience : contributeurs très large, donc outil très facile type wiki humhub, et à terme une base de connaissance sous yeswiki

  • la productoin de ressource pédagogiques libres : une forge pour faire respecter un process de création, une charte éditoriale, tracer les contributions….jusqu’à la mise en ligne. Et là faut concevoir cette pratique de co production de ressources, en prototypant à partir des outils existanttes (goglsheet+googledoc+trello)…

Oui, je spécifie bien deux niveaux, 2 types de contributeurs et 2 outils principaux pour gérer la production.

Par contre ces deux niveaux participent à la forge à documents et il me semble important qu’au niveau 1 on ait aussi un process de création/bonification, une charte éditoriale (même s’ils sont plus simples) et qu’on trace les contributions car comme nous l’expliquait @YannickLaignel, cette reconnaissance joue grandement dans la contribution.

En m’appuyant sur ce que tu as écrit, je propose cela :

  • niveau 1 : la curation de connaissances (oui, la cartographie des ressources existantes, le buttinage d’info) où chacun est encouragé à contribuer sous le wiki d’humhub

  • niveau 2 : la production de ressources pédagogiques libres (à voir si la dénomination est suffisamment large) qui repose sur un process de co-production s’appuyant sur plusieurs outils et qui permet à des personnes initiées d’aboutir à des produits finis (pdf, page web, vidéo avec un numéro de version).
    YesWiki a ensuite ce rôle de publication et de mutualisation au sein de notre réseau. On y expose par exemple des contenus provenant du niveau 1 qui ont un acquis un niveau de maturité suffisant, des fiches co-construites avec d’autres acteurs (telles les fiches d’outils d’animation du projet Tour de babel), etc.

super, ça se clairifie !