les premières idées qui me viennent :
Merci Philippe pour ces suggestions.
De mon coté je pensais peut-être à la mise en place d’un Trello. Pas d’install à faire, simple d’utilisation. Ton avis ?
Preneur d’autres pistes : hésitez pas !
Pour la documentation, je suis 100% d’accord. Les étapes sont bien pour les objets mais ne vont pas pour documenter un process de fabrication. Hors, on a tous besoin de ça. Dans notre fablab on pensais utiliser un wiki en parallèle mais ça multiplie les outils… Surtout que, à l’identique des projets qui sont visibles sur les multiples plateformes, partager des process (techniques de découpe, de moulage, etc) est très puissant. Plus même à mon sens que les projets. Au niveau de la forme, il faut y réfléchir. le format wiki se prête bien à ça car la documentation de process se rapproche de la logique encyclopédique.
On est super OK ! Et ce serait effectivement très enrichissant de pouvoir mutualiser ces bases de connaissances. Cela passe pas l’intégration d’une brique orientée wiki à l’intérieur de Fab Manager : c’est clairement le meilleur format. Je vais voir de mon côté nos marges de manoeuvre pour financer ce dev. Je reviens donner des news rapidement 
Pour la gestion d’une roadmap via Trello, j’ai trouvé un article intéressant : Going Public! Roadmapping With A Public Trello Board.
On en discute !
Pascal
Je vois plutôt Trello comme une façon élégante de gérer des post-it. il n’y a pas « d’intelligence » derrière, pas d’assistance pour organiser les besoins de roadmap ou backlog.
Je pense également que dés que l’on (vous) va avoir besoin d’une fonctionnalité un peu plus pro, il faudra utiliser nécessairement la version GOLD.
J’ai des doutes également sur les « exports » des données si vous décider de passer à autre chose, comment ne pas perdre le travail déja fait ?
pour la doc, le wiki me semble la solution la plus dynamique, mais effectivement, il faudrait éviter de sortir de l’outil.
un [[mot clé]] dans un texte (si on utilise la syntaxe media wiki, ou celle de markdown, utilisé sur le wiki de GitHub) doit permettre d’aller directement sur la page. Tous les utilisateurs pouvant modifier les pages wiki.
on trouve déjà un certain nombre de wiki pour Ruby www.ruby-toolbox.com/categories/wiki_apps
Je rajoute d’autres trucs qui pourraient aider les labs à propos des réservations / ateliers
La possibilité d’appliquer un tarif à l’heure dégressif.
On pensais mettre en place un prix minimum incompressible (qui serais le prix de la mise en place de l’impression, vu que nos temps de location sont « accompagnés » c’est à dire avec un fabmanager). Par exemple, une impression serais 10€ + 2€/h. Le must serais un tarif dégressif (on détermine des intervalles de prix et on y applique un tarif).
Je crois que ça a déjà été demandé : pouvoir passer les abonnements de date à date en période fixe, avec pourquoi pas un système d’abonnement « en avance » (comme pour la carte de transport, si on s’abonne le dernier mois par exemple, ça compte pour la période prochaine). En fait le système de tarif dégressif sur la période fonctionne aussi.
Pouvoir lier des matériaux (dans éléments projets) sur une machine.
Autres chose plus « spécifique » mais je pense que ça peut intéresser des labs : pouvoir créer une sorte de « demande de machine » en gros, la possibilité pour un usager de demander l’usage d’une machine qui serais en accès spécifique ou restreint, (le lab n’a pas accès à ses disponibilités) utile dans le cas de partenariat avec d’autres structures. Par exemple, nous avons acces à une impression métal via un partenaire qui peut nous faire de temps en temps une impression (disons pas plus de deux par semaine). on peut « gruger » en donnant deux créneaux de dispo par semaines, (je pense que c’est ce qu’on fera) mais c’est pas tres clair.
Si on peut gérer une machine non pas sur un créneau donné mais sur un nombre d’utilisations/semaines par exemple, ça peut résoudre le problème : l’usager envoie une demande, le fabmanager valide ou non (il vérifie que la pièce est correcte) et donne des dates ou l’usager pourra venir récupérer la pièce. Le prix n’est pas annoncé du coup, ou alors indicatif.
J’écris tout en réfléchissant, mais je pense que ça peut etre utile pour tous les cas ou le calendrier de la machine est incertain. De cette manière, chaque demande sera suivie d’un échange ou le fabmanager ayant vérifié les dispos de la semaine propose des créneaux disponibles.
Autre cas qui va surement se présenter, les machines I3D à frittage de poudre sont facturées au cm3 et pas à l’heure. Une solution pouvant englober tous ces cas particuliers peut etre vraiment utile aux fablabs.
Voilà pour mon pavé du jour
Salut Dimitri,
Pour les abonnements en période fixe, il me semble que ta demande est déjà implémentée. A la création d’un abonnement, tu peux spécifier s’il est glissant ou non : Un abonnement glissant prendra effet seulement le jour de la première formation. Dans le cas contraire, il prendra effet dès sa date d’achat.
Pour restreindre l’accès aux machines à certains utilisateurs, tu peux passer par le système d’étiquettes qui permet de mettre un tag sur un utilisateur et un tag sur un créneau. Un utilisateur qui n’a pas le tag ne peut pas s’inscrire sur le créneau. Ca ne répond pas à tous tes enjeux mais c’est une piste je pense.
A+
Pascal
Justement je ne comprends pas tres bien : il prend effet à partir d’un moment, donc je suppose qu’il peut etre antérieur à la date d’inscription ?
Un abonnement non glissant commence dès que l’utilisateur paye en ligne ou en guichet son abonnement
Un abonnement glissant commence quand la personne vient se former sur la machine qui l’intéresse:
Ex : elle prend un abonnement mensuel le 1er janvier mais s’inscrit à une formation le 20 janvier : son abonnement mensuel commencera le 20 janvier et s’achèvera le 20 février.
Pouet !
STOOOOOP.
(Avertissement Troll et version « sechement dit »)
Pour ma part, et beaucoup d’utilisateurs, les wikis, c’est l’enfer.
C’est aussi pour ca que je me tourne vers fabmanager, car cest visuellement joli, ludique, simple, step by step. (Ou dokuziki chez les americains non open sources)
Pour les adeptes du wiki, installez des wikis ! Merci ! Il y en a deja pleins (cf liste framasoft des wikis)
Merci de pas donner une mauvaise idee a l’equipe de dev ! Il y a deja pas mal de boulot pour ameliorer cet outil magnifique (par ce que c’est pas du wiki!) sans reinventer la roue (les wikis).
On a pas besoin de cette brique, mais de pleins d’autres.
Les wikis ont deja ete suffisamment discutés dans le reseau et depuis des annees. Faut inventer autres chose maintenant, faut inventer fabmanager !
Mercii !
Pour ce qui est de « developper une usine a gaz pour repondre a pleins de demandes individuelle de cas particulier », il serait bien aussi que les utilisateurs se prennent par la main et detourne le logiciel dans un premier temps, tester l’usage pendant un mois, et si c’est vraiment un besoin vital, proposer au vote pour le dev. Sinon on va lancer des dev pour des choses qui serviront pas. Il faut savoir detourner l’outils pour creer des usages non permis pour l’instant, sans que ca requiert du dev, pour se concentrer sur les besoins « de la majorité », qui sont les besoins recurents de tous
Histoire de pas gaspiller les ressources (dev / temps / motivations)
Trello est pratique pour gerer 3 post it, mais beaucoup moins qd tu en gere 300. Et c’est vite le bordel.
Pour moi trello c’est un outil virtuel pour faire la meme chose qu’avec des post it, faire du bordel ^^
Sinon, y’a Loomio
Sur les fonctionnalités à faire figurer sur une roadmap, effectivement, c’est parfait si l’on peut voter pour des fonctionnalités. Ca permettrait de voir ce qui intéresse ou pas les Fabs Labs et de faire des choix.
Sur l’aspect base de connaissances, les choses sont à définir d’un point de vue fonctionnel, mais comme le note Dimitri, on ne documente pas forcément que des objets, il peut aussi y avoir des process, des pratiques etc…
Je prends un cas concret : La Casemate est en train de travailler sur la mise en place d’un espace Bio Lab. Il va y avoir des choses à documenter, mais le format projet tel qu’il est présenté pour le moment ne va pas forcément bien correspondre aux productions issues de ce type d’espace. Du moins, c’est une question à creuser mais je suis quasi certain qu’il faudra imaginer quelque chose d’un peu différent. Si c’est bien fait, je ne pense pas que ça transformera Fab Manager en usine à gaz. Il faut penser un système ergonomique qui ne soit justement pas du wiki traditionnel. Mais comme nous avons déjà effectué ce travail sur les projets, je pense que c’est jouable.
Dimitri notait aussi que, ce qui est intéressant, c’est d’avoir un module intégré à Fab Manager pour ne pas avoir à en sortir (donc créer encore un compte ailleurs typiquement) et tout retrouver facilement au même endroit.
Autre argument : pouvoir partager ces bases de connaissances dans le réseau Fab Manager, comme pour les projets. Je pense que ça aussi, c’est une piste intéressante.
A noter aussi que cette demande ne me semble pas spécifique : ça fait plusieurs fois qu’elle remonte à mes oreilles.
Bref, le sujet est conséquent, et passionnant J’aimerai bien le creuser pendant la journée Fab Manager qui aura lieu en janvier à La Casemate : plus d’infos la semaine prochaine
@clemclem Ok avec toi pour Trello : si tout le monde y va de son post-it, ça devient rapidement ingérable.
Après, si on s’accorde sur un système de fonctionnement simple et rigoureux, ça pourrait peut-être éviter le coté foire aux post-it incompréhsensible:
Hypothèse:
Je rentre moi des cartes sur la base des demandes émises sur le forum et / ou Github (si elles ne proviennent pas de l’espace ou qu’elles sont pas complètement spécifiques)
Les utilisateurs votent pour des cartes sur une durée donnée. Ils peuvent les commenter au besoin (Trello permet de faire cela)
Ensuite et de façon classique, les cartes qui remportent l’adhésion passent en état « à faire développer » (sous réserve qu’il y ait le budget pour bien entendu !)
En procédant ainsi, je pense que l’on reste sur un système transparent et collaboratif sans virer dans le coté anarchique du mur de post-it.
Je ne pense pas que l’on aura des centaines et des centaines de demandes non plus à roadmaper sur un espace de temps limité, ou si c’est le cas on s’orienterait surement vers une usine à gaz.
Plus largement sur Trello, on s’est par exemple servi de cet outil pour gérer le projet Fab Manager. Aux vues du résultat, tu imagines bien qu’il y avait pas mal de cartes, mais ça s’est révélé plutôt efficace au final.
A discuter !
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é 
Hello Dimitri, je passe en coup de vent ! Je répondrai plus en détails d’ici quelques jours mais j’aime bien cette solution. D’autant plus que la collaboration sur projet est déjà dispo : plusieurs personnes peuvent travailler sur un même objet : Fab Lab de La Casemate
A+
Pascal
plop,
si c’etais en php/mysql, je me sortirais les doigts du code.
mais c’est du ROR, donc ma contribution en code, vous vous la mettez sur l’orreille 
j’arrive deja meme pas a installer le soft en diy sans diwo… XD
pour documenter un process, il suffit de faire une seule etape dans un projet, et modifier cette etape a l’infinie, non ?
sinon pourquoi pas une solution article, tant que c’est pas un wiki XD
ou alors une case « process » qui transforme les etape par etape, en article.
Pourquoi pas, ya une grosse réflexion à avoir. créer quelque chose d’intuitif est vraiment pas évident. Il me semble que l’organisation « foutoir » ou « bazar » (entendre par la que les contributeurs balancent des docs en vrac qui sont classées par ordre d’apparition) est la meilleure solution, car la plus simple. Dans ce cadre, c’est les outils de tri qui vont etre déterminent pour retrouver des choses le plus facilement possible.
Mais peut etre aussi que pour des process décrits avec minutie, je réfléchissais à une solution possible avec le RFF. ça serais de co-écrire des livres en utilisant Framabook. Par exemple, on fais des sessions de quelques mois ou on écris une aide technique sur la découpe laser, le moulage, etc. Il existe déjà des livres sur l’Arduino faits comme ça. On crée ainsi une sorte de bibliothèque de référence libre, et on peut faire ensuite des MAJ de certaines parties. Il est aussi possible de faire de la traduction de références existante, et de regrouper tous les livres en format ouvert qui existent déjà.
[quote=« Dimitri, post:20, topic:134 »] ça serais de co-écrire des livres en utilisant Framabook.
[/quote] ou sur wikibooks
du coup, avec la fonctionnalité inter-fabmanager, partager une base de conaissance commune (mais mono hébergée) serait une possibilité ?
Là revient le pb de la gestion d’un UUID unique pour identifier un utilisateur d’un Fabmanager vis à vis des autres, sans risques de doublons. Un peu comme MetaWiki sur wikipédia. (l’ID de Stripe pourrait t’il servir à ça ?)