Groupe "Encourager le partage de documentation, retours d'expériences au sein du réseau français"



  • Bonjour,

    Pour les choix techniques coté serveur, j'attends d'autres avis et je lancerai des trucs après, même si personnellement je ne suis pas très au fait de NodeJS.

    Comme tu le dis @Couby , GitHub est plutôt bien. J'y mets tous mes FabMoments aussi :
    https://github.com/loic-fejoz/loic-fejoz-fabmoments/

    L'avantage est que cela reste compatible ThingTracker aussi comme je le fais dans mon GitHub ci-dessus. Il faudrait par contre une petite interface pour faciliter les mises à jour, etc. Bref pas grand chose à développer mais faut juste le faire...
    L'autre avantage est que de plus en plus de personnes doivent déjà avoir un compte GitHub pour collaborer sur un projet, et donc il y a un frein en moins comparé à un wiki par FabLab (cf discussions lors du FabLab Festival 2015).

    L'inconvénient de GitHub est qu'il peut apparaitre comme complexe pour un néophyte comparé à une interface comme Fab-Manager.com.

    Loïc



  • Re,

    Après réflexion, il faudrait plutôt un truc genre ElasticSearch ou Solr pour le backend...
    Un avis ?



  • En effet les avis ça peut être bien. En même temps ça se précipite pas, et puis c'est bien aussi que le ou les gens qui mettent la main à la patte prenne une orientation qui les inspire :).
    Je ne pense pas que j'aurai de temps pour cela dans l'immédiat, alors si tu laisses Node de côté, ca va pas me froisser 😊.
    Entre ElesticSearch et Solr, aucune idée.

    Côté Git j'aime bien GitHub aussi. Après ce n'est qu'un remote très populaire. Un autre qui gagne à être connu est Cubehero. C'est aussi un git remote qui offre une interface plus user friendly, à la fab-manager peut-être je ne sais pas je ne connais pas assez ce dernier pour comparer.
    Ce qui est dommage côté Cubehero c'est que son auteur n'a pas ouvert le code de la plateforme, à ma connaissance. Ce qui n'est pas vraiment un soucis, on peut toujours pusher sur plusieurs remotes.

    Mais en effet je te rejoins, Git ne s'apprend pas en 5 minutes. D'où l'intérêt de travailler aussi sur sa vulgarisation pour que ce soit plus sexy et que ça ne demande pas des semaines.



  • Bonjour et désolé pour l'absence.

    Comme a dit Olivier dans son mail, "tout le monde est pris par le quotidien", et ... j'ai fait comme tout le monde ^^

    J'avoue que je n'arriverai pas à vous suivre sur les histories de backend, de serveur, etc ... car ce n'est pas mon domaine, et je préfère vous faire confiance sur ce sujet afin d'avancer plus rapidement.

    Concernant les différents outils, déjà merci à Loic pour la mise à jour du wiki avec la bibliographie.

    Ensuite, j'entend le faite que makake soit fermé et centralisé ( c'est d'ailleurs la première remarque que j'ai faites à ces créateurs ). Maintenant, je ne pense pas qu'il faille abandonner un outil parcequ'il est fermé. Je suis plutôt du partit d'expliquer aux gens les forces et les faiblesses de chaque outil afin qu'ils puissent choisir en connaissance de cause.

    Je pense également que pratiquement tous les outils peuvent permettre de documenter correctement 80% des projets. Encore faut-il savoir ce que l'on entend par "correctement" 🙂

    Ainsi, si vous êtes d'accord avec cette remarque, j'aimerais proposer quelques points pour avancer dans ce sens :

    • Faire une liste des outils de documentation connus avec points faibles/forts, niveau d'accessibilité, et autres critères qui nous sembleraient pertinents. Je pense par exemple à la liste des Lab qui l'utilise avec un lien vers leurs doc.
    • Etablir une liste de bonnes pratiques sur la documentation ainsi que les moyens pour y arriver ( en gros : documenter la documentation ^^). J'avais commencé à faire ce travail sur notre wiki. Il me reste beaucoup de points à voir ^^ http://wiki.lamachinerie.org/projects/documenter-son-projet/wiki
    • Mettre un lien pour chaque outil vers un exemple de documentation qui nous semble complet et pertinent afin d'établir un maitre étalon.

    Autres idées qui me viennent par la tête. Je partage, on verra si c'est pertinent ou pas :

    • Diffuser des projets d'outils physiques qui peuvent aider à la documentation (éclairage open source pour les photos, différents tests de micros/caméras pour la documentation vidéo, ...)
    • Etablir un système de grade de la documentation. Du - au + documenté selon le niveau d'utilisation des bonnes pratiques par exemple ?
    • Ou encore, une notation par les utilisateurs ?
    • Du, coup récompenses dans les labos par du temps machine ?

    Vous en pensez quoi ?

    Bonne journée !



  • @Adrien Oui il faudrait faire tout cela aussi mais, pour moi, la priorité n'est pas là mais dans la mise en place d'un truc minimal de partage décentralisé qui permettra ensuite à chacun des outils d'évoluer tout en formant un réseau.

    Dit autrement, pour moi, l'urgent et important sont les cas d'utilisation suivant :

    • Quand j'ai acheté du nouveau matériel, je cherche des projets les utilisant afin de trouver une idée de projet.
    • Quand j'ai une idée de projet, je cherche des projets similaires afin de connaitre les écueils à éviter.
    • Quand on me demande ce que l'on fait dans un FabLab, je peux facilement montrer un portfolio.

    Bien évidement, il y en a d'autres mais je mets cela en priorité.
    Mon deuxième point d'intérêt est effectivement les bonnes pratiques de documentation mais malheureusement cela ne réponds pas aux urgences ci-dessus.



  • Bien d'accord avec les points que tu évoque, mais cela sous entend qu'une documentation existe déjà, qu'elle est utilisable et exploitable ... Donc quand tu dis que :

    • Quand j'ai acheté du nouveau matériel, je cherche des projets les utilisant afin de trouver une idée de projet.
    • Quand j'ai une idée de projet, je cherche des projets similaires afin de connaitre les écueils à éviter.
    • Quand on me demande ce que l'on fait dans un FabLab, je peux facilement montrer un portfolio.

    Ça veux dire que :

    • Les documentations doivent donner le matériel utilisé et mettre l'information bien en évidence et a disposition
    • Des mot-clefs ont été attribués par projet et documentation afin de simplifier les recherches.
    • Des photos corrects du projet ont donc été prises afin de le documenter proprement.

    Pour moi ce que tu énonce fait donc références directement à des bonnes pratiques de documentation qui doivent être respectée avant de continuer à avancer ?



  • La poule et l’œuf...

    Si l'on veut savoir quoi écrire comme doc, il faut bien savoir ce que l'on veut en faire.
    Donc si ce sont bien ces usages qui nous intéresse dans la doc, alors ça veut dire que...
    Et donc cela veut dire qu'il faut des outils, templates, recommandations, qui disent que...

    Mais c'est bien l'usage de la documentation qui tire les besoins, non ?



  • Oui effectivement.

    Donc pour avancer selon toi, il faudrait lister ce que nous aimerions avoir dans une doc et regarder quoi mettre en face pour y arriver (outils, bonnes pratiques, tutos, etc ... ) ?



  • Pour moi, il faut savoir pourquoi on veut une doc, ce que l'on veut en faire, ensuite nous verrons comment arriver à cet état où la doc est utilisable.

    On peut vouloir une doc pour plein de raisons. D'ailleurs dans le domaine pro, nous avons des choses bien identifiées :

    • guide utilisateur,
    • guide de montage,
    • cahier de laboratoire (pour lister ce que l'on fait, les erreurs, etc),
    • le cahier de spécification,
    • concept opérationnel,
    • etc.

    Bref tout un monde de subtilité mais surtout d’objectifs différents qui ont donc des réponses différentes mais que nous, FabLab, recoupons sous le terme de "doc"...



  • Ok donc commençons par regarder pourquoi souhaiterions nous avoir une doc alors. On y verra plus clair sur la suite de la démarche ?

    Pour travailler sur ce point, on liste dans le forum, dans un pad ou dans une carte heuristique ?



  • On peut en discuter ici d'abord et synthétiser dans le wiki...
    http://wiki.fablab.fr/Partage_de_documentation,_retours_d'expériences



  • Ok je me lance.

    J'ai scindé ma réflexion en trois selon que j'était responsable du lab, utilisateur ou maker car je pense que les attentes ne sont pas les même.

    Pour moi et le lab, en tant que FabManager, j'ai besoins d'une doc pour :

    • Lister les projets réalisés dans le lab
    • Pouvoir greffer des makers au projet
    • Connaitre les besoins et usages sur les machines afin d'améliorer leur utilisation

    Coté utilisateur, quand je vois un projet, j'ai besoins d'une doc pour :

    • Comprendre comment le projet fonctionne
    • Permettre de le recréer
    • Comprendre ce qui a fonctionné ou pas
    • Connaitre les projets similaires

    Coté makers, j'ai besoins d'une doc pour :

    • Structurer mes notes de projets
    • Stocker mes idées, liens, inspirations
    • Stocker et structure mes fichiers de projet par version
    • Discuter avec les gens du projet ( forum, avis, commentaires )


  • A quelques nuances près, je suis d'accord avec tout cela...
    Maintenant, il faut prioriser. C'est ce qui a donné

    @loic_fejoz a dit :

    [...]
    Dit autrement, pour moi, l'urgent et important sont les cas d'utilisation suivant :

    • Quand j'ai acheté du nouveau matériel, je cherche des projets les utilisant afin de trouver une idée de projet.
    • Quand j'ai une idée de projet, je cherche des projets similaires afin de connaitre les écueils à éviter.
    • Quand on me demande ce que l'on fait dans un FabLab, je peux facilement montrer un portfolio.
      [...]


  • @loic_fejoz a dit :

    A quelques nuances près, je suis d'accord avec tout cela...
    Maintenant, il faut prioriser. C'est ce qui a donné
    [...]

    Ok, je comprend ton cheminement maintenant. A moi de prioriser maintenant 😉

    1 - Portfolio : Ça on est d'accord, on doit avoir une vitrine de ce qui est fait pour pouvoir la présenter
    2 - Les mots clef : Permettre de trouver facilement par recherche de mots clefs dans la description du projet, soit des projets similaires, soit des projets utilisant le même matériel, soit des projets utilisant la même machine/technique
    3 - Stocker des fichiers : Permettre au makers de déposer un fichier afin de pouvoir le partager et permettre une amélioration



  • Bonjour tout le monde,
    Dsl de ne pas avoir pris part à la conversation avant mais je dois avouer qu'au début c'était beaucoup trop technique pour moi et que je n'y comprenais pas grand chose. Et il faut aussi reconnaitre que je n'ai pas pris assez le temps ...
    Pour les différents besoins de docs je suis assez d’accord avec vous, c'est vrai qu'en tant que fabmanager ou qu'utilisateur ce ne sont pas les mêmes choses qui sont recherchées.

    Pour les priorités ça me semble être un bon début, le portfolio est essentiel pour tout le monde, et la recherche par mots clés est pour moi ce sur quoi il y a le plus de chose à faire et qui apporterait vraiment beaucoup.



  • Bonjour à tous,

    Hier soir s'est tenue la réunion copil de retour sur les groupe de travail. J'ai pu représenter ce groupe ( de manière complètement arbitraire ... Il faudrait choisir une personne de manière collégiale pour la prochaine fois 🙂 ).

    Le Pad est disponible ici : https://semestriel.framapad.org/p/ffflabs_20150608

    Globalement, nous n'avons pas eu le temps d'aborder en profondeur la partie documentation etc ... car d'autre sujets nous semblaient prioritaires (structuration, valeurs, communications, etc ...). La prochaine réunion se tiendra le lundi 13 juillet, et les suivantes se tiendront tous les 2eme lundi du mois.


    Revenons sur la documentation.

    Si tous le monde est d'accord pour prioriser le portfolio et les mots clefs, je pense qu'on a déjà une bonne base pour continuer le travail et aboutir a des moyens et des bonnes pratiques ?



  • Tout à fait.
    Maintenant que les besoins sont explicités et priorisés, j'en arrive à ces deux familles de solutions :

    • un moteur de recherche / agrégateur
    • des outils de publication

    Clairement thingtracker.net répond à la problématique des besoins, donc il s'agirait de faire un moteur de recherche basé dessus.

    Pour la publication, comme nous aimons la diversité, il faut adapter quelques outils emblématiques :

    • fab-manager.com
    • plugin wordpress
    • générateur hors-ligne pour gestionnaire de version
    • template Mediawiki


  • On peut adapter Redmine aussi ? Sinon on va devoir changer notre outils de doc une nouvelle fois ^^

    Sinon, je suis tombé sur ça ce matin : http://www.makery.info/2015/06/09/do-doc-et-opendoc-le-design-a-la-rescousse-de-la-documentation/

    L'initiative est super intéressante. Cela rejoint un peut le projet de Le Cube Media et le notre de créer une table de documentation facile à manier.



  • Je viens de lire le fil pour comprendre où vous en êtes, et d'après ma compréhension je dirais qu'on pourrait tabler sur la combinaison de deux choses :

    • agrégateur RSS pour constituer le portfolio : déjà en place sur http://fablab.fr même si le paramétrage actuel agrége des articles généralistes on pourrait faire la même chose avec des
      fils RSS spéciaux, dédiés à la publication des projets.
    • moteur de recherche : YaCy, un moteur P2P que j'ai expérimenté avec succès mais que j'ai dû désactiver à cause du tout petit quota disque...

    @+
    Yann



  • @yannlossouarn a dit :

    Je viens de lire le fil pour comprendre où vous en êtes, et d'après ma compréhension je dirais qu'on pourrait tabler sur la combinaison de deux choses :

    • agrégateur RSS pour constituer le portfolio : déjà en place sur http://fablab.fr même si le paramétrage actuel agrège des articles généralistes on pourrait faire la même chose avec des fils RSS spéciaux, dédiés à la publication des projets.

    J’ai mis en place http://planet.fablab.fr/.


 


Creative Commons License Sauf mention contraire des auteurs, le contenu des échanges est partagé
sous licence internationale Creative Commons Attribution-ShareAlike 4.0.