Documenter un projet : oui, mais sous quel(s) angle(s)?

A titre de curiosité, quand on parle de documenter un projet, est-ce

  • sous l’angle muséal
  • sous l’angle fablab (partage des savoirs, reproductibilité de tout ou partie du dispositif etc…)
    ou est-ce les deux à la fois ?
    Merci de m’éclairer

c’est sous l’angle de qq’un qui voudrait le reproduire. (puisque c’est le but d’un prototype)
donc pas nécessairement pour un type de personne/competence en particulier
On lui donne les éléments pour le faire. le Concept. Technos matériel. Raison sur les choix, changements d’avis…

C’est une problématique récurrente des fablabs, d’autant que ce n’est sans doute pas la partie la plus intéressante à réaliser pour un bidouilleur/maker.
http://fablabo.net/wiki/Aide:Documenter

Le LabFab de Rennes a d’ailleurs mis en place des ateliers sur ce thème.


A voir avec eux ?

Par ailleurs, ne serait-il pas intéressant d’intégrer un volet plus en lien avec le musée et la médiation ?
et dans la mesure où Mmx est à durée limitée, le suivi et l’aboutissement des projets après l’évènement. Mais je suppose que ces questions ont déjà été posées ?

Oui à voir avec eux si tu veux : C’est une initiative de Léa (@auregann sur twitter) du réseau doc@rennes
Dans le Trello ça serait plutot au niveau du pole communication (qui accompagne les communicants dans les équipes qui documentent les projets)

Hello, j’ai passé ce topic dans la catégorie ‘événement’.
Je pense que c’est une discussion importante à avoir, à la lumière des années précédentes et de l’expérience de chacun.
@YannickL un avis sur la question ?

De mon côté, plus ça va, plus je pense que la réplicabilité n’est pas le point le plus important…
À mon avis, on cherche plutôt à donner une visibilité à l’équipe et qu’elle explique son process (le problème qu’elle a voulu résoudre et les décisions qu’elle a prise)…

1 Like

On a abordé rapidement le sujet avec @juliendorra et pendant la réunion inter-communautés.
Ca me conforte dans l’idée que ce que nous cherchons avec les prototypes, c’est l’exploration de nouveaux usages (et donc pas forcément la réplicabilité).
On a évoqué la possibilité que chaque année, un seul projet soit ‘sélectionné’ pour être documenté en profondeur (avec le support de l’équipe).

Les autres prototypes pourraient plutôt être documentés sous l’angle de ‘l’expérience’ :

  • une vidéo démo de ~1:00 / 1:30
  • un petit texte sur le pourquoi
  • noms des participants + contact

Rappel : ce sujet set important parce que ça va guider le choix de l’outil nécessaire pour y arriver…

Il me semble que

  • la documentation fait partie de la philosophie des fablab (partage des savoirs etc)
  • un prototype qui fonctionne et qui attire le public peut devenir par là même un dispositif intéressant pour des médiations futures
  • documenter un projet, ça peut être une façon de valoriser et pérenniser le travail fait par les membres des équipes, pour nous et aussi pour eux-mêmes (que MMX ne soit pas juste un one-shot)

Je comprends tout à fait que vous souhaitiez adopter une solution plus légère.
Mais puisque que l’évaluation ne devrait pas me monopoliser les 3 jours, je propose quant à moi d’apporter mon aide en support aux équipes (avec mon appareil photo :), via un groupe de hackpad ou un wiki par exemple.

Que diriez-vous si nous proposions également à chaque équipe une fiche “à compléter” afin de documenter son projet ? Celle-ci pourrait contenir des informations “obligatoires” et d’autres plus facultatives et surprenantes.

Cela nous permettrait également d’adopter un modèle commun à tous les MSX.

Est ce qu’on ne pourrait pas adapter en ligne le squelette et la checklist du manuel du Fablabo ?

NB La doc accessible en ligne permettrait-elle d’apporter plus rapidement une solution à un souci technique ? Quelqu’un a-t-il déjà rencontré cette situation à MMX ou ailleurs ?

http://fablabo.net/wiki/Aide:Documenter#Comment_et_quand_documenter.3F_Quelles_informations_mettre_dans_sa_documentation_.3F

Très bonne idée !

Je m’occupe de faire un Gdoc (aujourd’hui ou demain) et je vous partage ça afin que l’on constitue une fiche à compléter par les équipes tous ensemble !

proposition d’éléments à mettre dedans :

  • la video qui montre le scénario utilisateur
  • comment présenter le prototype (fiche médiation)
  • le pourquoi du départ
  • les changements d’idées en court de route (et raisons)
  • lien vers sources (github ou ailleurs) codes, images HD…
  • comment faire marcher le prototype (fiche technique)
  • membres équipes et contacts
  • rappel licence libre

Voici un premier jet, n’hésitez pas à la modifier, l’enrichir, etc.

Bonjour
Merci de d’être attelée à la tâche. C’est une bonne base de départ mais la forme paginée me gêne un peu. Je la trouve contraignante : AMHA la répartition des volumes guide utilisateur/code/fabrication peut être très différente d’un projet à l’autre.

Je serai au fablab Plateforme C cet après-midi pour me documenter sur la documentation :slight_smile:
Je vous proposerai ensuite une organisation - sûrement sous forme de wiki - avec une intro nom/lieu/date/pitch/participants et des renvois aux différentes parties.

NB pour des raisons de rapidité et de commodité, je serai aussi d’avis que chaque partie soit en lien avec un seul des postes de l’équipe (quand c’est possible).

Plus j’y réfléchis, plus je pense que Hackpad est une bonne solution (pour les équipes).
Ensuite, on peut les mettre en forme de manière synthétique comme on veut sur le site global…

1 Like

juste mon avis : je trouve que l’idée d’un “guide” c’est bien mais que après chaque équipe fasse un peu ce qu’elle veulent, y compris de façon totalement différente. (et sans “fiche à remplir”)
ça permet aux équipe d’être créatif aussi sur la documentation du proto, si elle a envie de faire un format “recette de cuisine” ou “montage ikea”
samuel

1 Like

la fiche à remplir c’est une manière de leur rendre service en leur mâchant le travail. Et je ne suis pas sûre que la créativité des équipes aille sur la doc du proto en aussi peu de temps. AMA c’est plus une check list histoire de ne rien oublier, qu’un ensemble de cases obligatoires à remplir.

ma préférence pour un format non paginé vient sûrement de mon habitude des docs de fablab systématiquement en ligne. En même temps comment faire entre
. un jeu sur tablette entre plusieurs salles : grosse partie code et guide utilisateur, peu ou pas de fabrication,
. un dispositif holographique dans un caisson comme l’Holo fossile du Muséum d’histoire naturelle de Nantes http://www.museomix.org/prototypes/holofossile/ : grosse partie fabrication, pas de code, guide utilisateur réduit au minimum

NB et je trouve qu’en l’en-tête Museomix prend trop de place au moins à partir de la 2e page…

Je suis d’accord avec toi @samuelbausson.
Et je ne suis pas certain que la comparaison avec les fablabs (où le sujet n’est pas encore résolu, en passant) soit adéquate…
Encore une fois, sur un projet de 2 jours, la reproductibilité n’est pas l’objectif premier je pense.
Ce qu’on a besoin de savoir c’est (basé sur ce que Samuel a mis plus haut):

  • une démo (vidéo / photos)
  • pourquoi ils ont fait ça
  • framework de base (les outils, langages, etc.)
  • liens si pertinent
  • membres équipes et contacts
  • licence libre
  • tout autre info qu’ils pensent nécessaire

Certes, mais avec quoi nos muséomixeurs repartiront ils ? des nouveaux amis, de nouvelles adresses dans leur carnet le souvenir du fun et de l’expérience, et c’est tout ? et si par la suite ils veulent reprendre et développer tout ou partie de leur projet ou si le projet d’une autre équipe les intéresse ? ou s’ils sont contactés par une tierce personne (cf l’hologramme) ?
La question pour moi c’est aussi, qu’est ce qu’on leur apporte au delà de Museomix ?

NB Je parlais bien d’une documentation a minima, mais un minimum me semblerait pertinent. A chaque équipe de voir si la doc doit être poussée plus loin, en s’appuyant au besoin sur une aide extérieure.
A rapprocher de ceci en tenant compte du contexte local évidemment

Dans ce cas je concorde avec @samuelbausson, le format hackpad me semble être le plus pertinent.
Il s’agirait alors juste d’un “how-to”, si j’ai bien compris ? Avec des pistes, des indications, mais pas de “cases à remplir” ?

Bonjour

J’ai repris le premier doc et l’ai remixé ICI (un peu à l’arrache)

En fait il me semble que les 3 jours vont se dérouler de la façon suivante (dites moi si je me trompe)
• le vendredi les MMXeurs se rencontrent, arrivent à s’entendre plus ou moins bien, choisissent un projet avec plus ou moins de facilité :
• le samedi les choses se mettent en place, à partir de 16h nos MMXeurs commencent à se dire qu’ils sont en retard, à partie de 19 ou 20h qu’ils sont vraiment en retard
• le dimanche c’est le rush

Donc

. demander un minimum de documentation pour que l’organisation et le musée puissent garder une trace de ce qui s’est fait (et la présentation en page facilite cette tâche)
Les fiches de présentation sont-elles destinées à être montrées aux publicS, notamment aux collectivités et entreprises partenaires ?

. proposer aux équipes d’étoffer leur documentation de manière optionnelle

  • qui constitue un document de travail commun au cours des 3 jours accessible en ligne pour l’équipe et pour toute autre personne qui pourrait les aider à distance
  • qui leur permet de conserver une trace concrète de ce qu’ils ont réalisé (d’ailleurs pour certains dispositifs certaines pièces comme les platines arduino devront-elles être rendues à l’organisation ?)
  • qui leur offre de partager leur travail et leur expérience

Quant à ce qui va être montré au public : présentation, mode d’emploi… est-ce qu’il n’y a pas moyen d’articuler ou de fusionner les deux en laissant un maximum de liberté de création à l’équipe ?

C’est ouvert. Bon week end à tous et toutes :sunny: