Je suis d’accord avec l’idée du vote, et le format wiki ne signifie pas un wiki.
Et, ça fait longtemps que je n’avais pas entendu la remarque déplacée : le fait que ceux qui veulent des fonctionnalités n’ont qu’à se bouger le cul. Déplacée car c’est justement ce que je fais ici : me bouger le cul. Tu remarques que je n’exige rien, je laisse l’équipe faire comme elle l’entends. Ce qui est normal, je ne code pas. Mais si ils ont aucun retours, c’est d’une part pas très encourageant, d’autre part ça ne leur permet pas d’améliorer le site. Bien sur qu’il faut prioriser, mais pour ça il faut des idées, des gens qui proposent des trucs.
La remarque serais plutôt à faire à ceux qui ne font rien, critiquent dans le vent, ou exigent des choses alors qu’il ne sont pas moteur. Et qui pour l’immense majorité, ne sont pas sur ce forum.
Donc pour revenir au wiki : bien sur qu’il ne faut pas une plateforme wiki classique.
Je me suis rendu compte qu’il y a deux types de savoirs dans les fablabs : ya les savoirs « projets », à savoir une documentation délimitée par un objet, lié à un ou des auteurs définis, avec un début et une fin et une évolution relative. (la grande majorité des projets seront documentés une fois, avec d’éventuelles mises a jours puis basta.)
Et ya des savoirs « process » qui ne sont pas délimités par un projet. Entendre par là : une technique, un process qui sera utile pour bien plus qu’un projet. Elle n’a pas de début ni de fin et une évolution théoriquement infinie (un process évolue, et si il deviens obsolète on le garde quand même en archive. Il est toujours intéressant de savoir comment on sculptait la pierre au 13eme siècle par exemple en revanche la 300eme déclinaison de linteau de porte, on s’en fout).
Si on prends le process « sculpter la pierre », les étapes n’ont aucun sens. Ya le concept de base, puis les déclinaisons des techniques, chose qui s’enrichit au fur et à mesure des contributions. Le projet est lié à un auteur, pas le process (ou très rarement). On est donc dans un savoir qui est encyclopédique, destiné à s’enrichir théoriquement à l’infini.
Tout le truc, qui est pas évident du tout, c’est de faire simple.
Si on part dans une organisation « wikipédiale » il va falloir classifier tous les process. Au début ça sera facile, mais si les contributions sont nombreuses, on est pas sorti, je suis d’accord. Le but n’est pas non plus de refaire un wikipédia, qui survole les techniques (on parle de la théorie, rarement de la pratique, et si on veut apprendre la sculpture, il faut se référer à des ouvrages spécifiques). C’est pourquoi je suis d’accord avoir toi sur un point, les wikis « de base » ne sont pas pratique pour documenter des projets.
Dans la pratique, on aura forcément des process mais aussi des machines spécifiques, et un contexte, charge au lecteur d’adapter l’information à son propre contexte, ses propres machines… (le bio fablab est un bon exemple)
Cela reste quand même très utile. Un endroit ou on trouve une liste des techniques d’assemblages possibles à la découpe laser, les différentes techniques de lissage du plastique, le recyclage de certains matériaux, comment est organisé un fablab, etc.
Ainsi, le format texte classique (un article de base, avec photos et des chapitres) s’y prête mieux à mon sens. Le formatage de la doc varie énormément d’un process à un autre. Il faut donc quelque chose de plus souple tout en restant simple.
Reste plusieurs solutions.
-
Soit on fais rien, et les process seront documentés ailleurs (ou ? Dans des wikis disparates et pas visités ?) c’est une option envisageable, mais bon.
-
Si on distingue les projets des process, il va y avoir le cas ou certains vont documenter des projets dans les process et inversement. Si on élimine la contrainte « auteur » pour passer sur des articles co-écrits pour les process, on peut réduire cet effet. Mais il sera toujours présent. Et il faudra trouver un moyen d’organiser tout ça.
-
On peut fondre les projets et les process. On ne fais pas de distinction véritable sur le site. L’auteur choisis au début son format (étapes ou article). Dans ce cas, on risque d’avoir des redondances (la co-écriture n’est pas possible). On peut résoudre le problème de dispersion par un système de tri des process/projets amélioré et des collections comme dans Instructable qui permet de regrouper des projets/process selon une thématique, et chaque utilisateur peut faire ses collections. Un système de popularité crée un classement des meilleures collections. Je sais pas si c’est dur à faire, mais c’est simple pour l’utilisateur.
Ce sont des pistes, yen a surement d’autres.
De rien pour le pavé 
