Ce qui est sur, c’est qu’il est prévu de filmer les conférences, mais rien n’empèche de compléter avec des interview ou autre video individuelle. Il faudra juste quelqu’un pour s’en occuper.
PS : tu n’est pas après la bataille, mais après le première envoi de programme pour préparer la com. à diffuser.
Finalement, j’ai eu un remord. J’ai créé des outils permettant de prévoir facilement la perte de statut de membre par non-renouvellement d’adhésion et expiration de trop de certifications. Je vais bientôt publier une nouvelle version de WotWizard incluant ces outils. Dans les périodes qui arrivent, ces informations seront importantes, me semble-t-il. Je peux donc en faire une rapide présentation (une 1/2 heure devrait suffire). Et j’aimerais toujours faire un atelier d’installation de WotWizard (~ 2 heures).
Désolé d’arriver si tard.
J’envisage aussi (scoop) de porter plus tard WotWizard, non pas en Rust (désolé @elois), mais en Go, où je me sens relativement à l’aise.
Le portage en Go m’intéresse beaucoup ! Non pas spécialement contre Rust, mais parce que c’est toujours intéressant de regarder ce qui se fait ailleurs. Si tu fais cet atelier, je suis prêt à payer ma place 
Ton intervention m’encourage.
Je ne compte pas spécialement parler de Go dans cet exposé, sauf s’il y a des questions, mais ce n’est pas le sujet prévu.
J’ai déjà porté mes outils fétiches sur Go et je commence à en faire un peu le tour. De tout ceux que j’ai regardés, c’est sans doute le langage le plus proche de Component Pascal par l’esprit, et je n’ai donc pas de difficultés majeures à y faire des portages.
À votre bon cœur, messieurs dames. Je suis d’accord pour cette promotion de la G1. Prix libres.
Ce serait bien de réussir à porter WotWizard en go, ça permettrait de l’ouvrir à d’autres contributeurs.
Par exemple cela faciliterait l’intégration avec une interface web, afin d’améliorer wot-wizard.duniter.org notamment.
En lisant la discussion, j’ai eu une idée que je vais soumettre. Pourquoi ne pas demander un tarif d’inscription aux ateliers ? En monnaie libre évidemment 
Par exemple : 10 Ğ1 l’inscription. Les organisateurs pourraient en conserver une partie (par exemple 10%) et reverser le reste aux intervenants.
Sinon, je ne sais pas encore si je pourrai venir. Au pire, on pourrait ptet organiser, à distance, une présentation autour de la wotmap si jamais je ne pouvais pas venir. Est-ce que ce serait possible ?
Possible, oui j’espère, optimal, non. Tiens moi au courant 
Si tu ne peux pas venir, c’est une question de dispo ou de budget ?
Personnellement et en tant que co-organisateur des RML12, je suis contre (et je pense que les autres co-orga bordelais seront contre également).
Je trouve dommage de restreindre l’accès, je trouve rébarbatif de contrôler l’accès, je suis pour privilégier le soutient volontaire (facultatif donc) plutôt que la barrière à l’entrée. De plus, pour inclusivité des nouveaux, qui ne sont pas encore membre parce qu’il découvre juste, ça veux dire soit qu’on les empêche de participer (ce qui me semble très domage au moins pour tout ce qui est grand public), soit on réserve grâce au bureau de change à ceux qui on accès à de la MNL.
En-revanche, si en tant qu’intervenant vous souhaitez rendre votre atelier payant (en Ǧ1), libre à vous d’expérimenter cela (tant que vous organisez vous même le contrôle d’accès). Et libre a vous d’en reverser une part à l’organisation des RML.
Un peu des deux. En tous cas, je vais savoir ça rapidement.
Je comprends. C’était une idée comme ça
Je viens de me dire là comme ça (donc idée pas encore mûre, à développer) que j’organiserais bien un contrib’atelier non dev, histoire de factoriser certaines tâches (en terme de com’ ou d’organisation d’événements, tout ça…) et de rassembler des junistes d’un peu partout. Est-ce que ça rentrerait dans le cadre de ces journées même si ce n’est pas technique ?
Il faudrait bien segmenter les choses. Les RML ont tendance à s’ouvrir au non-technique, c’est bien (ça permet de croiser développeurs et utilisateurs), mais il ne faut pas oublier que l’objectif principal est d’attirer des contributeurs.
Justement, le but est de contribuer à la monnaie, mais pas au code
Maintenant, si ça le fait pas, c’est pas grave, je me vexerai pas
Selon moi, ça rentre idéalement dans le thème du vendredi : Faciliter les interactions entre utilisateurs et développeurs
Ou si la journée est booké, dans le thème du lundi (pas le thème initial, mais le thème qui se profil au vu des propositions d’atelier.
Bref, peux tu proposer ça sous forme :
Type et titre : (atelier, conf… + titre)
Durée :
Public :
Contenu :
Objectifs :
Pourquoi pas segmenter justement et intercaler au milieu du rendez-vous bi-annuel, 2 rendez-vous non-technique?
Les RDML : renommage des RML en Rencontres Développeurs de la Monnaie Libre
Les RUML : Rencontres Utilisateurs de la monnaie Libre, plus orienté marché libre, enchères et autres Ǧeconomicus, sur un calendrier qui produirait 4 rdv dans l’année à intervalle réguliére …
L’inconvénient que j’y vois : Si on sépare, utilisateur et développeur vont encore moins se croiser, on risque donc d’avoir des outils de développeur développé par des développeur et qui répondent à des besoin de développeur, et des utilisateur qui fantasment des produits dans le vide faute de lien avec les développeur pour concrétiser leur besoin d’usagers.
PS : pour les RML12 nous avons :
1 jour grand public ludique
1 jour exploration de notions d’économique, de modèle sociétal…
1 jour d’exposé R&D sur ce qui se fait dans l’écosystème des crypto (même si on aura probablement du moins technique en parallèle)
1 jour sur les modèles économique (réparti entre le mardi matin et une partie du vendredi pour l’instant)
1,5 jours forum ouvert/hackathon, pour que les présents face ce qui leur semble le plus important à leur yeux à ce moment.
1 jour pour les dev de l’écosystème
1 jour pour les dev du coeur/protocol
0,5 jour explicitement dédié à connecter développeurs et utilisateurs
1 jour pour pratiquer la Ǧ1
Du coup, on garde au moins les 2 jours traditionnels destinés aux développeurs, mais les aficionados pourrons consacrer jusqu’à 5 jours pour du dev durant ces RML12.
Et les utilisateurs ont 2 jours de découverte et pratique, qu’ils peuvent étendre à 7 jours pour ceux qui veulent approfondir même sans être informaticien…
Après, peut-être effectivement que si cette formule est reprise, parler d’université d’automne des monnaies libres ou de semaine des monnaies libres serait plus pertinent que RML… Mais je n’ai pas l’impression que la contribution au dev de la Ǧ1 y perde. On verra bien par la pratique.
La vrai difficulté pour les dev m’a l’air de se rendre disponible plus que les 2 ou 3 jours pour profiter pleinement de l’évènement.
Rien ne t’empêche de créer l’événement annuel ou biasannuel que tu veux avec qui tu veux ! Mais donne lui un nom qui justement ne percute pas un existant créé par d’autres. Si ton événement est bien défini et bien organisé, il pourra parfaitement prendre un essor.
Pour moi (j’y réfléchis pour les RML13) ce ne sont pas les mêmes contraintes de lieu. On n’a pas les mêmes besoins pour accueillir un “coder camp” et pour accueillir le grand public.
Il y aura des gens présents aux 2 types d’évènements qui feront le lien. À l’occasion du Fabulous Contribution Camp organisé l’an dernier, on avait retenu que mettre des intermédiaires entre dev et grand public est souvent utile. Un bon dev n’est pas forcément quelqu’un qui ait envie de communiquer (même si a le droit, je ne veux rien empêcher).
Au contraire, pour répondre à des gens remplis de revendications fantasmées, il vaut mieux quelqu’un qui ait envie de le faire, et il n’y a aucune raison que cette personne soit core-dev, juste un peu au courant (il peut hein, c’est comme il veut, mais c’est pas indispensable).
Et de même, pour tenir informé les dev des besoins, il vaut mieux quelqu’un qui ait fait un premier tri, et qui connaisse un peu les termes techniques.
Type et titre : atelier Meet your devs
Durée : 1h30
Public : tout public, présence de quelques développeurs souhaitée
Emplacement : le vendredi
Contenu :
10 minutes pour mettre un cadre à tout ça
séparation entre les différents softs, en gardant un pôle pour rediriger le public vers le bon endroit. Le but est de remonter les besoins et envies du public, et de proposer au besoin un intermédiaire “semi-technique” pour les devs qui souhaiteraient de l’aide à la vulgarisation (même si j’en connais une bonne partie qui n’ont pas besoin de cette aide sur ce projet)
Objectifs : faire le lien entre les devs (oui, ce sont des humains !) et les utilisateurs des logiciels (oui, ce sont des humains aussi, qui peuvent avoir des idées et des envies sans forcément être des mécontents)
@gpsqueeek, que dirais-tu d’inclure (ou d’ajouter) une partie : Apprendre à soutenir un dev surchargé.
Contenu : expliquer par des exemples le travail qui se cache derrière une demande, du tri parmi les demandes au différentes briques de réalisation, au test technique, au retour utilisateur sur l’ergonomie… jusqu’a arriver à répondre avec pertinence à une demande.
Objectif : aider les usagers à proposer des choses simple à réaliser, ou à expliciter qu’ils ont conscience de l’ampleur de ce qu’il demande, mais que oui, c’est quand même ça qui leur semble prioritaire pour répondre à leurs besoins.
Je ne sais pas si c’est pertinent, mais il me semble que très peu d’utilisateurs non devs sont capables de créer une “issue” sur gitlab. Cela pourrait faire une parenthèse utile en tant que passerelle entre “les deux mondes”.