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

Adrien

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 !

loic_fejoz

@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.

Adrien

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 ?

loic_fejoz

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 ?

Adrien

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 ... ) ?

loic_fejoz

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"...

Adrien

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 ?

loic_fejoz

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

Adrien

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 )

loic_fejoz

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.
[...]

Adrien

@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

laurine

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.

Adrien

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 ?

loic_fejoz

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

Adrien

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.

yannlossouarn

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

Olivier G.

@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/.

loic_fejoz

Merci @Olivier-G

Pour Yacy ou elasticsearch ou ..., qui peut le faire tourner et l'adapter pour récupérer les thingtrackers ? J'ai commencé à regarder tout cela mais pas beaucoup avancé pour le moment...

loic_fejoz

Pour information, on retrouve les même cas d'utilisation mais exprimer encore autrement :
http://www.labfab.fr/rendez-vous/pizza-doc-2-viens-documenter-ton-projet-dans-la-bonne-humeur/

daweeed

Bonjour,

Je ne fais pas partie de ce groupe de travail, mais la problématique du partage de la documentation nous (FabLab de la Cité des sciences) tient particulièrement à cœur et je me permets de venir ici partager nos réflexions ainsi que de vous faire part de ce que nous avons dans les cartons.

J'avais participé en septembre dernier au workshop "Documentation" à Nantes (http://fablabo.net/wiki/WorkshopDocumentation ) et je retrouve dans les échanges ci-dessus, les problématiques que nous y avions évoquées.

L'une des pistes les plus prometteuses à mon sens est constituée par la "standardisation" des flux de sorties des projets documentés afin qu'ils soient facilement aggrégeables et interrogeables. Nous avions justement commencé à dresser une ontologie commune en s'appuyant sur les travaux autour du FabML (j'ai vu la référence dans la biblio sur le wiki).

C'est justement dans la continuité de ce workshop que nous étudions actuellement la possibilité de développer une plateforme d'interrogation de ces fameux flux standardisés. Mais cela devrait s’appuyer éventuellement sur une API d'interrogation de ces flux, une visualisation claire de cette ontologie (ainsi que son adoption et une appropriation de celle-ci par la communauté), des plugins pour pouvoir publier ces flux normalisés à partir des plateformes déjà utilisées (mediawiki, dokuwiki, wordpress, etc.), etc.

J’ai vu passé sur le fil certaines solutions techniques déjà évoquées, mais je pense que le principal défi n’est pas tant l’aspect technique mais plutôt l’adoption par la communauté de pratiques communes autour d’un effort de convergence (principalement l’utilisation d’une ontologie partagée et faisant consensus). Bref, vous voyez le topo.

Cela fait déjà quelques temps que nous avions cette réflexion en cours mais pas le temps de s’y atteler. Nous sommes en train de lancer une étude d’avant-projet afin de débroussailler le terrain et de ne pas partir dans tous les sens. Bien évidemment, tout ce travail ne peut se faire qu'avec la communauté et il va sans dire que toutes les productions seront librement disponibles.

Je viens donc ici pour continuer cette démarche initiée lors du workshop nantais de la manière la plus ouverte possible.

Je suis bien évidement à disposition pour échanger autour de cette problématique et vous solliciterai régulièrement au fur et à mesure de nos avancées.
Chaleureusement,
David

PS : je me suis dit qu’il était pertinent de faire ce post dans ce fil, mais si cela gêne le reste du déroulé de celui-ci, je le bougerai ailleurs.

PS2 : Désolé pour la longueur du post, mais cela méritait un développement.