Aujourd’hui, ce n’est pas un jour comme les autres. Journée de l’amour pour les uns, journée commerciale à bougonner pour les autres, elle ne laissera personne indifférent. Pourquoi ne lui donner une dimension toute différente, en en profitant pour déclarer notre amour aux logiciels libres, et aux développeurs du libre que nous torturons à longueur d’année, en bons utilisateurs exigeants et spécialistes du yakafokon que nous sommes.

C’est ce que nous propose la FSF avec sa campagne I love Free software, reconduite cette année. Il est important parfois de savoir lâcher prise pour clamer haut et fort que nous les aimons, ces logiciels libres.

Nous avons choisi pour notre part de vous proposer un fork de poèmes que vous devez tous connaître… Demain dès l’aube, de Victor Hugo et Le dormeur du Val d’Arthur Rimbaud.

 

Demain dès l’aube (v1.337)

Demain, dès l’aube, à l’heure des châteaux en Espagne,
Je râlerai. Vois-tu, je sais que tu m’entends.
De toi j’exigerai de coder des montagnes.
Je ne puis retenir mes commits plus longtemps.

Ce jour, je te le souhaite sans bug à obvier,
Nulle exigence en moi, nulle attente s’induit,
Seul, ton labeur, le dos courbé, mains au clavier,
Fier, voit le fruit de l’écran qui a blanchi tes nuits.

Je ne t’apporterai ni les bitcoins qui tombent,
Ni le vert des dollars qui ternit leur valeur,
Mais bientôt avec toi nous ferons la bombe
Une main sur la bière et l’autre sur le cœur.

 

Le codeur d’eval()

(v. 4.2)

Dans un réduit obscur il chante une rengaine
Enchaînant follement les semaines aux semaines,
Content quand des lignes obscures s’empilent
Et il boit du maté quand son code compile.

Un codeur jeune, Git ouvert, tête nue
Et la face baignant dans de frais rayons bleus
Dort ; il est vautré dans le PHP chenu
Pâle dans son t-shirt geek au Tux globuleux

Les mains dans le cambouis, il dort. Souriant comme
Sourirait un géant, ce n’est pourtant qu’un homme :
Le livreur de pizzas seul nourrit cet ermite.

Les crashtests, il s’en est déjà bien trop nourri ;
Il dort sur son clavier, la main sur la souris,
Tranquille. Il a deux bugfix dans son commit.

Plein de datalove à vous !

Chez Framasoft, on ne code pas (ou très peu). On utilise le code développé par des personnes formidables, par des communautés de passionné-e-s, et on le propose au grand public sous forme de services libres et gratuits.

Nous tenons donc aujourd’hui à déclarer notre amour aux équipes développant Etherpad (Framapad), Ethercalc (Framacalc), studs & le fork framadate, Wisemapping et Mindmaps (FramindMap), SVG-Edit (Framavectoriel), TinyTinyRSS (Framanews), Wallabag (Framabag), Diaspora* (Framasphère)… et tant d’autres !

Et un spécial chaton d’amour aux équipes (et à la fondation Mozilla) derrière FireFox qui vous permettent  d’utiliser ces applications web depuis un navigateur Libre.

Le développement du plugin a démarré mi-décembre, dont cette annonce aura été le témoin.

La feuille de route prévue était basée sur le fait que que le développeur consacrerait environ la moitié de son temps à MyPads et ce, jusqu’à la fin du mois de février.

Le calendrier est en réalité quelque peu décalé et compressé. Outre les fêtes de fin d’années, le prestataire a préféré en terminer avec ses autres engagements professionnels. Il n’a donc que très peu avancé sur MyPads.

Il a désormais assuré qu’il se dédierait exclusivement jusqu’à la fin du mois de février au plugin. Des progrès rapides devraient être visibles sur notre espace Gitlab (en maintenance pour le moment), à travers le code source, les tickets et le wiki.

Si les tests en conditions réelles ne se feront que dans quelques semaines, la date de sortie annoncée n’est pas pour autant remise en cause : le plugin reste prévu pour la fin du mois de février.

MyPads: development is back

The development of MyPads has begun from the second half of December. Here is the annoucement.

The initial roadmap was based upon the fact the programmer would dedicate half of his time to MyPads development, from December to the end of February.

The schedule will actually be postponed and compressed. In addition to year’s end celebrations, the contractor has chosen to finish his other professional commitments. Consequently he hasn’t done much work for MyPads.

He has confirmed that he will be dedicated full time working on the plugin til the end of February. You’d be able to see significant progress in our Gitlab instance (at the moment down for maintenance), through the source, tickets and the wiki.

If real world tests can only be possible within a few weeks, the announced publishing date isn’t challenged: MyPads remains scheduled before March.

(english version below)

Notre éditeur de texte libre et collaboratif Framapad est une implémentation du logiciel libre Etherpad. Ce  service est mis à la disposition de tous et cela démontre en même temps que ce service peut être proposé de manière décentralisée (même si nous sommes peu nombreux à proposer une instance publique d’Etherpad, des milliers d’instances privées existent).

Au mois de juin dernier, Framasoft a lancé une campagne de financement participatif visant à contribuer activement à l’amélioration d’Etherpad pour y ajouter la gestion des comptes utilisateurs, des groupes et des pads privés. Il n’aura fallu que trois semaines pour que l’objectif soit atteint. Nous vous en remercions une fois encore.

Le but de ce projet  est de permettre aux utilisateurs d’Etherpad, et donc de Framapad, de créer un compte en leur nom, d’y associer des groupes et, pour chaque groupe, des pads. Ces pads pourront être publics, privés sur invitation ou encore d’accès restreints par l’usage d’un mot de passe. Le tout doit prendre la forme d’un plugin pour Etherpad, publié sous licence libre et s’installant de la même manière que tous les autres plugins du logiciel.

Il était prévu que la réalisation débute à la rentrée et que le plugin soit livré en fin d’année. La feuille de route a quelque peu glissé du fait de la surcharge temporaire du prestataire sélectionné. Le coup d’envoi est néanmoins lancé cette semaine et l’ensemble du développement se déroulera sur notre Gitlab via le projet ep_mypads https://git.framasoft.org/framasoft/ep_mypads .

Le plugin est attendu pour la fin du mois de février 2015. Il devrait comporter de petits bonus par rapport au cahier des charges initial.
Les premières semaines seront consacrées à l’écriture du code serveur, à sa documentation et à ses tests. Il faudra attendre début 2015 avec la création de l’interface graphique afin que MyPads puisse commencer à être testé.

Pour rappel, le cahier des charges originel est disponible sur ce pad : http://lite4.framapad.org/p/LEpEOUoQb3/timeslider#24.

Un point sur l’avancement du développement sera réalisé environ toutes les deux semaines.

——-

MyPads : development launched

Our free/open source and collaborative editor named Framapad, is an application of the free software Etherpad. This GoogleDoc-like service is opened for everybody and demonstrate simultaneously that it can be proposed in a decentralized way (even if only few organizations can propose such an open service, thousands private instances are running).

In last June, Framasoft has launched a crowdfunding campaign aiming to to contribute actively to Etherpad’s improvement, by adding the management of users, groups and private pads. Only three weeks have been necessary to reach the goal. We want to thank you again.

The purpose of this funding is to let Etherpad and so Framapad’s users create an account, link some groups and for each group some pads. These ones may be public, privates with invitation or protected by a password. All of this must be an Etherpad plugin, pubished under open source license. This have to be installed like any other Etherpad plugin.

The beginning of the plugin’s cofing was planned at the fall this year. The roadmap has moved forward because of the contractor’s overloading. However the project is launched this week and the development will be made on our Gitlab instance with the ep_mypads project  https://git.framasoft.org/framasoft/ep_mypads

The plugin is expected on the end of February, 2015. It might include several little extra comparing to the original specifications.
First weeks will be dedicated to server side programming, its documentation and tests. You’ll have to wait for 2015 with the creation of the user interface if you want to test MyPads.

As a reminder, you will find the initial specifications on this pad http://lite4.framapad.org/p/LEpEOUoQb3/timeslider#24

A stage news will be made around every two weeks.

En 1995, l’un des plus brillants informaticiens au monde, le professeur Donald Knuth, écrivait une lettre au bureau américain des brevets (USPTO) que nous vous proposons traduite ci-dessous.

Les arguments pour refuser les brevets sur le logiciel sont déjà là et fort bien exposés. Ce qui n’empêche pas de devoir se battre régulièrement depuis contre cette néfaste tentation.

Lettre à l’Office des Brevets, par le professeur Donald Knuth

Donald Knuth – 1995
(Traduction : rocherd, audionuma, r0u, FMy1, simon, Omegax)

Letter to the Patent Office From Professor Donald Knuth

Chers membres de la commission,

De même que beaucoup d’autres chercheurs en informatique, je voudrais vous demander de reconsidérer la politique actuelle de cession de brevets sur les processus informatiques (NdT : computational processes). J’ai pu en effet constater une inquiétude considérable parmi la communauté des chercheurs en informatique, la peur que les décisions des tribunaux spécialisés dans le droit des brevets et du Bureau des Brevets et des Marques Déposées (NdT : Patent and Trademark Office) rendent la vie des programmeurs bien plus difficile.

Durant la période 1945-1980, il était communément admis que les lois sur les brevets n’étaient pas appliquables au logiciel. Cependant, certaines personnes auraient apparemment obtenues des brevets sur des algorithmes d’une importance capitale — par exemple, la compression Lempel-Ziv et le chiffrement par clé RSA publique — et aujourd’hui ils interdisent en toute légalité aux autres programmeurs d’utiliser ces algorithmes.

C’est un changement radical par rapport aux pratiques précédentes qui ont rendu possible la révolution informatique, et je crains que ce changement ne soit dommageable pour la société. Cela aurait pu avoir un fort impact négatif sur mon propre travail : par exemple, j’ai développé un logiciel appelé TeX qui est actuellement utilisé pour la conception de plus de 90 % des livres et revues de mathématiques et physique mais aussi de centaines de milliers de rapports techniques dans toutes les disciplines scientifiques. Si les brevets logiciels avaient été monnaie courante en 1980, je n’aurais jamais pu créer un tel système, ou penser à le créer, ni même imaginer que quelqu’un puisse le faire.

On me dit que les tribunaux essaient de faire une distinction entre les algorithmes mathématiques et les algorithmes non-mathématiques. Pour un informaticien, c’est un non-sens, car chaque algorithme est un objet mathématique s’il en est. Un algorithme est un concept abstrait sans relation avec les lois physiques de l’Univers.

Il n’est pas non plus possible de faire la distinction entre des algorithmes « numériques » et « non-numériques », comme si les nombres étaient en quelque sorte différents des autres formes d’information exacte. Toutes les données sont nombres, et tous les nombres sont données. Les mathématiciens travaillent bien plus avec des entités symboliques qu’avec des nombres.

L’idée d’adopter des lois affirmant que certains algorithmes sont mathématiques et d’autres ne le sont pas me parait tout aussi absurde que la tentative de l’Assemblée Générale de l’Indiana, au XIXème siècle, d’adopter une loi stipulant que le rapport de la circonférence d’un cercle à son diamètre est exactement 3 ou que l’Église médiévale décidant que le Soleil tourne autour de la Terre. Les lois des Hommes peuvent être significativement utiles, mais pas lorsqu’elles contredisent les vérités fondamentales.

Il y a bien longtemps, le Congrès avait judicieusement décidé que les objets mathématiques ne pouvaient pas être brevetés. Il est certain que personne ne pourrait utiliser les mathématiques s’il fallait payer un droit de licence à chaque utilisation du théorème de Pythagore. Les idées de base de l’algorithmique que certaines personnes poussent à faire breveter sont si fondamentales, que le résultat menace d’être similaire à ce qui arriverait si on autorisait les auteurs à breveter les mots et expressions. Les romanciers ou les journalistes ne pourraient plus écrire sans que leurs éditeurs n’obtiennent les permissions des propriétaires des mots. Les algorithmes sont au logiciel ce que les mots sont pour les écrivains, parce qu’ils sont les briques fondamentales nécessaires pour construire quelque chose d’intéressant. Qu’arriverait-il si les juristes pouvaient breveter leurs méthodes de défense ou si les juges de la Cour Suprême pouvaient breveter leurs jurisprudences ?

J’ai bien conscience que les tribunaux de brevets essaient de faire de leur mieux pour servir la société. Le Bureau des Brevets a ainsi admirablement rempli cette mission en ce qui concerne les aspects de technologies reposant sur les lois concrètes de la physique plutôt que les lois abstraites de la pensée. Je suis moi-même titulaire de quelques brevets sur des dispositifs matériels. Mais je pense fermement que cette récente tendance à breveter les algorithmes ne profite qu’à un petit nombre d’avocats et d’inventeurs alors qu’elle entrave la grande majorité de personnes qui veulent faire des choses utiles avec les ordinateurs.

Quand je songe aux programmes informatiques dont j’ai besoin quotidiennement pour travailler, je ne peux m’empêcher de réaliser qu’aucun d’entre eux n’existerait aujourd’hui si les brevets logiciels avaient prévalu dans les années 60 et 70. Changer les règles aujourd’hui aura pour conséquence de geler le progrès à peu près à son niveau actuel. Si cette tendance se confirme, la seule alternative pour la majorité des brillants développeurs américains de logiciels sera d’abandonner ou émigrer. Les États-Unis perdront alors leur position dominante.

Merci de faire votre possible pour inverser cette tendance alarmante. Il existe de bien meilleures façons de protéger les droits de propriété intellectuelle des développeurs de logiciels que de les empêcher d’utiliser des briques fondamentales.

Sincèrement,
Donald E. Knuth
Professeur émérite

Gee est en vacances, on fait ce qu’on peut, soyez indulgents 😉

Crédit : Simon Gee Giraudot, Christophe Masutti et Luc Didry (Creative Commons By-Sa)

Source :

• Le code source de MS-DOS à télécharger (attention aux conditions d’utilisation 😉 )

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

Vous participez ou administrez directement une école de musique ? Ou plus généralement vous vous occupez d’un lieu associatif qui doit organiser la gestion des plannings, des adhérents et des contacts, la réservation des salles, la planification des cours, le prêt du matériel… ?

Sachez qu’il existe une excellente application développée depuis plus de dix ans par deux passionnés de musique et d’informatique !

Le logiciel s’appelle ALGEM (le L c’est donc pour Libre) et il méritait assurément une petite mise en avant.

Rencontre avec Bruno Mauguil (au centre sur la photo) et Jean-Marc Gobat (à droite) qui travaillent tous deux à Musiques Tangentes (Malakoff) d’où l’aventure ALGEM a vu le jour.

Interview ALGEM

Bonjour Bruno et Jean-Marc, pouvez-vous vous présenter succinctement ?

Jean-Marc : agrégé d’éducation musicale et diplômé de l’école d’ingénieurs du CNAM de Paris, j’ai la chance de pouvoir pratiquer au sein de Musiques Tangentes mes deux passions que sont la musique et l’informatique. Je participe au développement d’ALGEM depuis quelques années déjà et intervient dans l’école en tant que professeur de M.A.O. Je suis aussi membre fondateur du groupe de fusion World « Transbohêm ».

Bruno : à l’origine musicien de Jazz, j’ai créé Musiques Tangentes à l’âge de 20 ans au milieu d’un grand vide intersidéral : pas de locaux de répétition, pas d’école de musiques actuelles… Après avoir fondé l’école, épaulé de quelques furieux musiciens, l’informatique nous a permis de structurer ce milieu embryonnaire. J’ai tout de suite compris l’immense intérêt de ce nouvel outil : création, gestion, bureautique, etc. Après m’être débattu sur Prologue (système d’exploitation français de Bull) puis fait un court et malheureux passage sur Windows, je participe aux balbutiements du Libre grâce à la rencontre providentielle d’Eric. C’est la révolution ! Bien que je ne sois pas du tout informaticien, je ne jure depuis que par l’Open Source. Cela fait maintenant 15 ans que nos outils bureautique sont sous Linux. La musique viendra plus tard sur ce système et en partie seulement. ALGEM est né du fait de l’absence totale d’outil de gestion pour notre activité. La suite reste à écrire….

Alors ALGEM c’est quoi ?

Jean-Marc : strictement parlant, ALGEM est l’acronyme d’Application Libre de Gestion d’Ecole de Musique. C’est au départ un logiciel de gestion dédié aux écoles de musiques actuelles. Axé sur la gestion de plannings et de contacts, il s’est enrichi au cours des années et peut très bien convenir aujourd’hui à d’autres types de structures.

Quelle est la répartition des rôles entre vous deux ?

Jean-Marc : je suis chargé du développement, de la maintenance chez nos partenaires et de tous les aspects techniques liés à l’installation, le fonctionnement et les rapports d’erreurs signalés par nos utilisateurs.

Bruno : je suis responsable de l’Association et initiateur du projet. Je suis donc à la fois maître d’œuvre et maître d’ouvrage, responsable du cahier des charges, définissant les grandes lignes et les besoins, et de plus en plus concerné par les problèmes de déploiement. Je joue beaucoup aussi le rôle de bêta-testeur, avec l’ensemble de l’équipe, et suis bien sûr utilisateur au quotidien depuis maintenant plus de 10 ans.

C’est parti d’un besoin interne ? Il n’existait rien de similaire sur le marché ?

Jean-Marc : effectivement, il n’y avait rien de comparable sur le marché à l’époque de sa mise en chantier. Les quelques solutions existantes, très coûteuses de surcroît, étaient réservées aux utilisateurs de Windows et ne correspondaient pas aux besoins des écoles de musiques actuelles. Il fallait donc choisir entre une solution bancale ou le développement d’un logiciel en interne. C’est ce dernier choix qui a été fait, grâce à la participation d’Eric. Ses compétences en Java, langage à l’époque en pleine expansion, lui ont permis en quelques mois de fixer l’ossature du logiciel et de le rendre opérationnel dans nos locaux.

Quand avez-vous décidé d’en faire un logiciel libre et pourquoi ? Et avez-vous constaté une amélioration dans la diffusion et participation du projet ?

Jean-Marc : depuis les débuts, Musiques Tangentes s’investit dans le libre, en privilégiant les systèmes et logiciels Open Source et les applications sous Linux. Il était naturel avec ALGEM d’ajouter une pierre à l’édifice. Comme il a fallu pas mal de temps pour refaçonner l’application, réorganiser les sources et produire quelque chose de plus cohérent, ce passage n’a pu se faire qu’assez récemment, début 2012 (les sources sur GitHub). C’était aussi l’objectif/rêve de Bruno, celui de pouvoir partager un outil avec les confrères et de contribuer à la communauté du libre.
La diffusion du logiciel est encore assez réduite, mais de nombreuses demandes nous ont été faites depuis les derniers mois. Et nous avons constaté un regain d’intérêt depuis le début de l’année scolaire et la publication sur Framasoft.

Le logiciel évolue comme vous voulez ? Résistez-vous au « cloud » ?

Jean-Marc : beaucoup de projets en cours, oui. Des fonctionnalités en chantier : gestion de stages, importation de carnets d’adresse, pré-réservation en ligne, etc. Quant au « Cloud », s’il présente indéniablement des avantages, comme la simplification des procédures pour les novices, son adoption à grande échelle par les entreprises dominantes symbolise pour nous une certaine forme de retour au Minitel, comme l’avait remarqué à juste titre Benjamin Bayart dans sa fameuse conférence. S’en remettre à des entreprises comme Google, Facebook, Apple ou Microsoft, c’est un peu renier l’Internet des origines, décentralisé et pluriel. Afin de répondre aux besoins d’une certaine frange de nos utilisateurs, nous avons essayé néanmoins avec Algem Webstart de concilier les deux mondes : déployer localement l’application tout en profitant de l’hébergement en ligne.

Dans combien de structures ALGEM est-il déployé ? Elles s’occupent toutes de musique ?

Jean-Marc : Officiellement, une demi-douzaine de structures, dont deux à Toulouse et à Tours avec lesquelles nous sommes en relation très étroite. Cela va de la salle de répétition au salon de coiffure ! Donc, pas nécessairement ciblé école de musique. Officieusement, une trentaine de structures nous ont déjà demandé une version d’ALGEM pour leur usage personnel.

C’est dans le cadre de Musiques Tangentes que vous avez développé ALGEM. Pouvez-vous nous en dire plus sur ce lieu, son histoire, les services proposés ?

Bruno : Musiques Tangentes est un centre « musiques actuelles » : apprentissage de loisir, centre de formation professionnelle, studio de répétition (collectif et individuel), studio d’enregistrement, accompagnement de projet et un peu de diffusion (amateur et professionnel). C’est aussi un lieu de création et d’accueil de résidence ou d’insertion professionnelle. C’est une structure pionnière, née dans le squat de la rue des Caves à Sèvres. Nous fêtons cette année nos 35 ans d’existence et Musiques Tangentes est ouverte à tous (à partir de 3 ans), débutant ou confirmé, amateur ou professionnel. Un tiers de notre activité s’effectue aussi hors les murs (intervention en temps scolaire, en périscolaire, en centre spécialisé type IME, en colonie de vacance, en crèche, en entreprise…), partout ou l’on peut faire de la musique… « PLUS DE BRUIT », la Mano Negra est passée par chez nous, c’est un lieu d’apprentissage, de rencontres et d’échanges. Bref, un berceau d’utopies où l’on peut encore rêver et jouer sans contraintes !

Il me semble que vous y proposez un studio d’enregistrement « full libre » ?

Jean-Marc : nous utilisons depuis longtemps des distributions Linux spécialisées dans l’audio-numérique, comme 64Studio, Ubuntu Studio, ou plus récemment Tango Studio. Ardour est installé dans notre rack informatique et nous permet de réaliser des enregistrements sous ces systèmes, grâce à la compatibilité matérielle de notre carte RME MADI 64 canaux. Bien que nous fournissions aussi des prestations sur Pro Tools, le logiciel de référence dans de nombreux studios, nous ne pouvons qu’encourager l’usage de solutions libres. Musiques Tangentes est pratiquement la seule structure à proposer de tels services dans un environnement résolument professionnel : console numérique SONY DMX-R100, station de travail Intel i7 64 bits en dual boot, enceintes A2T. La demande est encore infime mais il n’est pas interdit de penser que l’utilisation d’un logiciel comme Ardour soit à l’avenir de plus en plus pertinente, face à une concurrence peu réactive et très coûteuse.

Est-ce que vous en profitez pour sensibiliser vos membres mélomanes aux licences libres ? Y en a-t-il qui ont fait le choix des licences Creative Commons pour leurs créations ?

Jean-Marc : j’ai moi-même édité l’album « Déserts » de Transbohêm sous licence Creative Commons. D’autres adhérents et membres de l’équipe administrative ont aussi choisi cette licence pour leurs réalisations. Pour un indépendant désireux aujourd’hui d’éditer sa musique, les licences libres présentent une belle alternative face aux fourches caudines de la SACEM.

Bruno : Musiques Tangentes est membre de « Libre Accès » et à ce titre nous avons vivement encouragé nos adhérents à utiliser des licences libres. Vous trouverez de nombreux articles à ce sujet sur notre blog. De plus, des ateliers découverte sont organisés régulièrement autour de ce thème.

Et pour finir, un appel à bonne volonté pour ALGEM ?

Jean-Marc : tout le monde est bienvenu : relecteurs de code, testeurs, spécialistes Java. Nous invitons d’autre part toutes les structures utilisant le logiciel à nous donner leur avis ou nous suggérer des améliorations possibles. Nos propositions de journées de formation restent d’ailleurs toujours d’actualité et nous encourageons tous les utilisateurs à les suivre afin de participer aux avancées d’ALGEM et de pérenniser son développement dans les années futures.

Bruno : nous en sommes encore à l’aube de l’engagement communautaire autour de ce projet et nous espérons que de nombreux utilisateurs et programmeurs nous rejoindrons prochainement . Une première rencontre entre tous les acteurs concernés sera d’ailleurs proposée très bientôt.

-> ALGEM – Pour tout contact : info@algem.net

L’équipe d’OpenHatch organise régulièrement des rencontres, ateliers, événements, sprints, hackathons, etc. invitant de nouveaux contributeurs à participer au développement de logiciels libres. Elle nous livre ici le fruit de son expérience.

L’enthousiasme et la motivation sont indispensables mais ne peuvent faire l’économie d’une solide organisation et réflexion en amont. Happy Hacking 🙂

Note : On remarquera que les deux livres cités en référence pour aller plus loin font partie de nos traduction Framabook : Libres conseils et Produire du logiciel libre.

 

 

Le guide de l’événement libre in situ

The In-Person Event Handbook

L’équipe OpenHatch – février 2014
(Traduction : Omegax, zak, François, Ju, MrTino, Wan, Asta, François, goofy, amha)

Faire en sorte que votre projet soit prêt pour de nouveaux contributeurs

Il semble que chaque jour apparaisse un nouvel atelier, hackaton ou autre sprint, où des projets open source sont invités à travailler avec de nouveaux contributeurs. À OpenHatch, nous avons nous-mêmes souvent organisé ce genre d’événements ! Nous avons découvert que pour en tirer un profit maximal, il est important de planifier les choses en amont. Expliquer vos objectifs, identifier les tâches appropriées, et tester l’organisation de votre projet sont autant de points indispensables pour aboutir à de belles réalisations et passer un bon moment. Ce travail a grandement amélioré nos expériences, et nous pensons qu’il mérite l’effort significatif qu’il mplique.

Nous avons créé ce guide pour aider les projets open source à se préparer pour ces événements. Nous avons utilisé notre propre projet, l’application web OpenHatch.org, comme un exemple dans ce qui suit. Au bas de la page, vous trouverez des aide-mémoires. Elles contiennent en condensé les conseils dispensés dans ce guide, et peuvent vous aider à monitorer vos progrès durant la phase de préparation de votre projet.

Les sources de ce guide sont libres. Un tas de merci à nos contributeurs. (Vous pouvez contribuer, vous aussi !)

Définir des objectifs

Vous devez être capable de présenter clairement vos objectifs pour l’événement, car cela donne à votre groupe une ambition générale à atteindre. Vous pouvez donc commencer par vous demander :

Quel est l’objectif global de votre projet ?

Il vous faut une réponse courte (un paragraphe ou moins) à cette question que vous pourrez utiliser pour attirer les contributeurs potentiels vers votre projet. Les détails, c’est bien joli, mais vous ne devriez pas avoir besoin d’être trop technique à ce moment là. À de nombreux événements, comme les sprints PyCon, on vous demandera un court résumé à exposer devant tout le monde. Pourquoi ne pas vous y préparer ?

Exemple :

L’objectif de OpenHatch est de rendre les communautés de logiciels libres plus accueillantes pour les nouveaux venus. Pour ce faire, nous fournissons documents et support logistique pour animer des ateliers « Introduction à l’open source », un site web avec des ressources libres, des « missions d’entraînement », un découvreur de talents parmi les bénévoles, et plusieurs autres projets en cours de réalisation.

Que voulez-vous accomplir à cet événement ?

Réfléchissez à ce que vous souhaitez voir spécifiquement réalisé lors de cet événement. Vous pouvez catégoriser ces objectifs selon les différentes parties du projet, si vous en avez plusieurs. Il devrait être spécifié clairement de quelle manière ces actions contribueront au progrès général du projet. Toutefois, il ne s’agit pas de « tâches » — il devrait être toujours nécessaire de diviser ces objectifs pour mieux les atteindre.

Il est utile de les lister en termes d’objectifs « principaux » et « étendus ». Avoir des objectifs principaux réalistes et bien définis vous donne quelque chose à célébrer à la fin de l’événement, tandis que les objectifs étendus ou secondaires vous permettent de prévoir le cas excitant où vous vous retrouviez avec une équipe nombreuse et efficace, capable d’accomplir une tonne de travail.

En général, il vaut mieux avoir trop d’objectifs que pas assez, mais priorisez-les. Lorsque vous arriverez à l’étape du découpage en tâches, prenez le temps de traiter en détail chaque objectif avant de passer au suivant.

Exemple :

• Faire une nouvelle mission d’entraînement
  • Objectif principal : Choisir une compétence sur laquelle baser une nouvelle mission d’entraînement, et concevoir cette mission. En créer une maquette.
  • Objectif étendu : Implémenter la maquette et la faire tester par des volontaires de l’événement.
• Faire le ménage dans le suivi de tickets
  • Objectif principal : Passer en revue l’outil de suivi, et étiqueter les tickets selon le « ménage » à y faire. Un bug doit-il être vérifié ? Un patch doit-il être testé ? Une demande de fonctionnalité doit-elle être être rattachée à un jalon ?
  • Objectif étendu : Utiliser ces étiquettes comme guide pour « faire le ménage » . Vérifier les bugs, tester les patches, etc.

Installation du projet

Dans notre expérience, la phase d’installation du projet est l’obstacle majeur à la participation. Nous avons vu (et conduit !) des événements où les participants passaient le plus clair de leur temps à seulement mettre en place leur environnement de développement et faire connaissance avec le projet. Si notre objectif est de permettre à de nouveaux venus de contribuer, tâchez d’estimer le temps qu’il faut pour installer votre projet. Puis trouvez un ami qui n’est pas familier avec votre projet pour voir combien de temps il faut vraiment. Vous pouvez aussi trouver quelqu’un pour vous aider à faire cela dans #openhatch.

Documenter et améliorer le processus à l’avance peut faire économiser du temps et de l’énergie à tout le monde. Si vous savez qu’une partie de votre projet sera inévitablement dévoreuse de temps, assurez-vous que tous les participants savent exactement à quoi s’en tenir.

Toutes les informations ci-dessous devraient être documentées dans un fichier LISEZ-MOI placé à la racine de votre dépôt. Vous pouvez également placer cette information dans une section « Vous voulez participer ? » sur le site web de votre projet, et/ou vous pouvez inclure un lien vers le LISEZ-MOI dans la signature de votre liste de diffusion ou dans la barre de statut de votre canal IRC.

Comment trouver une communauté et des mainteneurs pour le projet

Les informations des contacts devraient être explicitement affichées, étant donné que vous pourriez avoir des contributeurs éloignés ou des contributeurs qui voudraient démarrer en amont de l’événement. Les types d’informations de contacts peuvent inclure :

• Un lien vers votre mailing-list ;
• Votre nom de canal et de serveur IRC (avec le lien vers le guide pour installer IRC et le lien vers sa version webchat) ;
• Les comptes de réseaux sociaux tels que Identi.ca, Twitter ou Facebook si votre projet en possède ;
• Le contact des mainteneurs du projet, si vous vous sentez à l’aise pour le mentionner.

Si vous avez une préférence pour le type de prise de contact, précisez-le.

Exemple:

OpenHatch laisse en deux endroits des informations de contact que nous essayons le plus possible de garder à jour et en cohérence l’un avec l’autre. Il y a nos informations de contacts dans la documentation, référencées principalement depuis notre répertoire où sont déposés les codes sources, et nos informations de contacts dans le wiki, référencées à partir de la page d’accueil du site web.

La structure du projet

Décrivez la structure de base de votre projet. Quels sont les plus gros composants et où sont-ils situés ? Comment ces composants interagissent-ils ? Puis décomposez chaque partie. Vous n’avez pas à parler de chaque fichier ou sous-dossier de votre projet, mais prenez soin de ne pas prendre pour acquis que chaque nouveau venu comprendra le sens de tel script, ou la manière dont interagissent tels fichiers, ou dans quel langage est programmée telle partie du projet.

Selon la taille et la complexité de votre projet, cela peut être une tâche particulièrement imposante. Chez OpenHatch, nous travaillons toujours à documenter la structure complète du projet. Nous recommandons de commencer par une explication « en vue d’ensemble » de la structure projet – juste assez de détails pour remplir d’une demi-page à une page. Quand vous aurez plus de temps, vous pourrez rentrer dans le détail, en commençant par les parties du projet sur lesquelles les gens travaillent le plus souvent (ou qui sont plus susceptibles de faire l’objet de sprints ou de hackatons). Si vous utilisez d’autres frameworks ou librairies, vous pouvez gagner du temps en mettant des liens vers leur documentation et leurs tutoriels.

Exemple :

Une description d’ensemble de la structure du projet OpenHatch peut être trouvée dans « Project Overview ». Une description de la structure de OH-Mainline (le dépôt derrière notre site web) y est présente.

Comment mettre en place un environnement (« de développement ») local

Pour contribuer à votre projet, les gens ont généralement besoin d’une version locale du projet où ils peuvent faire des modifications et les évaluer. Plus votre guide d’installation/développement est détaillé et clair, mieux c’est.

Voici quelques éléments pour la mise en place d’un environnement de développement à mettre dans votre guide :

• Préparer leur ordinateur
  • Assurez vous qu’ils connaissent bien les outils de leurs systèmes d’exploitation, comme le terminal / la ligne de commande. Vous pouvez le faire en donnant un lien vers un didacticiel et en demandant aux utilisateurs s’ils le comprennent bien. Souvent, de très bons didacticiels existent déjà, celui d’OpenHatch sur la ligne de commande est disponible ici.
  • Si les contributeurs doivent mettre en place un environnement virtualisé, accéder à une machine virtuelle ou installer un kit de développement en particulier, expliquez-leur comment faire.
  • Donnez la liste de toutes les dépendances nécessaires pour faire tourner le projet, et une explication pour les installer. Fournissez un lien vers de bons guides d’installation, s’il en existe.
• Téléchargement du code source
  • Donnez des instructions détaillées sur comment télécharger le code source du projet, dont les obstacles et problèmes fréquemment rencontrés.
  • S’il existe plusieurs versions du projet, dites clairement quelle version ils doivent télécharger.
• Comment voir / tester les changements
  • Expliquer aux contributeurs comment voir et tester les changements qu’ils ont effectués. Ceci peut varier selon ce qu’ils ont changé, mais faites votre possible pour couvrir les changements les plus fréquents. Cela peut être, tout simplement, afficher un document html dans un navigateur, mais ce peut aussi être plus compliqué.

L’installation pourra différer pour chaque contributeur en fonction de leur système d’exploitation. Vous aurez probablement besoin de créer des instructions séparées pour les utilisateurs de Windows, Mac et Linux, dans différentes parties de votre guide. Si vous entendez ne supporter le développement que pour un seul système d’exploitation, assurez-vous que cela soit dit clairement pour les utilisateurs,

Exemple:

Vous pouvez voir comment OpenHatch annonce cela dans son guide d’installation. Les instructions pour tester des changements peuvent être trouvées là. Des tâches plus spécifiques peuvent avoir leur documentation additionnelle (par exemple la documentation concernant les différents changements du code).

Contributions et retours

Comment les contributeurs doivent-ils procéder pour amener leurs modifications au projet ? Est-ce qu’ils soumettent une pull request sur Github ? Doivent-ils générer un patch et l’attacher à un ticket sur le système de tickets ? Assurez-vous que cette information est explicitement fournie.

Example :

Le guide d’OpenHatch pour soumettre des changements peut être trouvé ici.

Il est aussi utile d’indiquer aux gens comment ils peuvent faire des retours/signaler des bugs sur le projet. Si votre projet n’a pas de système de suivi de tickets, envisagez d’en créer un. Sur Github, tous les dépôts disposent du système de tickets (bien que vous ayez à l’activer en allant dans Settings puis Features). Il y a beaucoup d’autres systèmes de suivi de tickets.

Si votre projet est de petite taille, vous pouvez ne pas avoir besoin ou ne pas vouloir de systèmes de suivi de tickets. Aucun problème. Le principal est que les contributeurs sachent comment vous remonter des informations.

Example :

Les problèmes avec le projet « Open Source Comes to Campus » peuvent être signalés ici. La plupart des autres problèmes liés à OpenHatch peuvent être signalés là.

Les outils tels que le suivi de tickets sont très utiles pour communiquer de manière asynchrone. Ce n’est peut-être pas la solution la plus appropriée lors d’un événement physique. Si vous voulez changer les choses pour l’occasion – comme demander aux participants de vous notifier par IRC les liens vers les nouveaux tickets, pour éviter qu’ils ne passent entre les mailles du filet – assurez-vous de leur en parler !

Vérifiez votre documentation

Vérifiez que cette documentation est complète et effective en la testant auprès de personnes qui n’ont pas participé à votre projet auparavant. Pour chaque sytème d’esploitation, trouvez au moins une personne pour lire votre documentation, tenter d’installer, faire et tester des modifications et participer aux différentes modifications du projet (au choix de votre testeur, ces modifications peuvent être des faux changements ou des vraies tâches). Vérifiez que vos testeurs ont des compétences et/ou une expérience similaire à celle des nouveaux arrivants à votre évènement.

Si vous rencontrez des difficultés pour trouver des personnes pour vous aider, essayez la chaine #openhatch sur IRC.

Assurez-vous que tous les problèmes qui surviennent lors de ce processus de vérification soient intégrés à la documentation. Une fois que la documentation a été vérifiée, ajoutez une ligne au début de votre guide pour annoncer ce qui a été vérifié et quand.

Par exemple :

Instructions de l’environnement de développement testées avec succès sur Ubuntu 12.04 (le 03/10/2013), Mac OS X 10.8 (le 01/10/2013) et Windows XP (en janv. 2005). Vous pouvez consulter cette démarche à OpenHatch ici.

Idéalement, vous devriez vérifer que tout fonctionne : installer, faire des modifications, les tester et les intégrer. Si vous n’avez le temps que pour une seule de ces tâches, nous vous recommandons de vérifier l’intallation. Notre expérience nous a appris que c’est sur ce point qu’émergent la plupart des problèmes.

Définir les tâches des participants

Retournons aux objectifs de l’événement dont nous avons parlé dans la première section. Chaque objectif devrait être décomposé en étapes distinctes qui permettront de l’atteindre. Ces étapes sont les tâches à confier aux participants.

Ces tâches devraient inclure un résumé en anglais simple aussi bien que les informations sur la localisation des modifications (par exemple, quels fichiers ou fonctions sont altérés). Nous recommendons d’inclure une liste des compétences nécessaires (par exemple : compétences en design, Python basique) et des outils (par exemple: Développement sur environnement Mac). Il est aussi utile d’inclure le nombre estimé d’heures que la tâche va prendre, d’étiqueter certaines tâches comme plus ou moins importantes, et de marquer où quelle tâche est dépendante d’une autre.

Cela semble représenter beaucoup de travail mais cela devrait aider vos participants à trouver rapidement et facilement les tâches appropriées pour eux. Etant donné que l’un des objectifs principaux d’un événement en personne est de donner une expérience positive aux participants, nous pensons que cela en vaut la peine.

Créer un système pour suivre les tâches

Nous recommandons l’utilisation d’un wiki ou un document de planification similaire pour garder une trace des tâches. OpenHatch dispose d’un navigateur pour suivre les tâches que nous utilisons pour nos événements. Vous pouvez, si vous le souhaitez, faire un fork et l’adapter à votre projet ou événement ; cependant, nous vous recommandons d’attendre un peu, car nous allons bientôt faire de grosses améliorations. Quelque chose de très simple, comme un etherpad (NdT : ou Framapad), peut également faire l’affaire (ici, un cadre et un service exemple que vous pouvez utiliser).

Préparer les tâches

Pour vous rendre compte du nombre de tâches à préparer, nous vous recommandons de vous baser sur la durée de l’événement et le nombre de participants attendus pour prédire la charge en temps/homme de votre projet. Vous pouvez utiliser les estimations de temps que vous avez faites pour évaluer chaque tâche. Nous suggérons que vous prévoyiez 30% de plus que ce dont vous pensez que vous aurez besoin : il vaut mieux avoir trop que pas assez.

Exemple :

• Objectif de base : parcourir l’interface et étiqueter les tickets selon le type de résolution nécessaire. Est-ce qu’un bug doit être vérifié ? Est-ce qu’un patch doit être testé ? Une fonctionnalité doit-elle être rattachée à un jalon ?
  • Tâche 1 : étiqueter les problèmes
    • Compétences et outils nécessaires : compétences de base en anglais, connaissance des concepts de vérification, tests, jalons…
    • Temps estimé : ~20 minutes par problème
    • Pour démarrer : prenez connaissance du suiveur de tickets, et comment il affiche les informations. (Voyez cette documentation.) Demandez un accès Administrateur pour pouvoir ajouter des étiquettes au suiveur.
    • Pour chaque problème : lisez la discussion relative à chaque problème, et identifiez où la communauté intervient dans le signalement de ce problème. Si c’est un bug non vérifié, ajoutez le label non vérifié. Si c’est un patch non testé, ajoutez l’étiquette patch non testé, etc. Si c’est une fonctionnalité qui n’est rattaché à aucun jalon, ajoutez l’étiquette jalon nécessaire.
• Objectif étendu : utilisez les étiquettes comme un guide pour résoudre chaque ticket. Vérifiez les bugs, testez les patch, etc.
  • Tâche 1 : Vérifier les bugs
    • Compétences et outils nécessaires : compétences de base en anglais, et dans l’idéal connaître les machines virtuelles pour effectuer des tests sur plusieurs OS.
    • Temps estimé : 20 minutes par bug (variance élevée).
    • Pour démarrer : téléchargez l’environnement de développement et assurez vous que vous pouvez lancer le projet. Assurez vous que vous avez un compte sur Le suiveur de tickets et que vous savez ajouter des commentaires ou changer les étiquettes.
    • Pour chaque bug : essayez de reproduire le bug. Enregistrez les résultats dans un commentaire, avec des informations concernant le type de l’OS et sa version. Si possible, effectuez le test sur plusieurs navigateurs. S’il y a plusieurs commentaires récents sur les trois OS majoritaires, ajoutez l’étiquette prêt pour test par le mainteneur (NdT : ready_for_maintainer_review).

Quoi qu’il en soit, les participants doivent être rattachés à une tâche correspondant à leurs compétences et à leurs intérêts. Effectuer ce travail préparatoire fera démarrer les participants immédiatement plutôt que de les faire attendre que vous leur suggériez une tâche adéquate. Dans l’idéal, les organisateurs d’événements auront collecté des informations sur les compétences et intérêts des participants bien en amont, donc vous pourrez adapter la liste à votre groupe de contributeurs.

Rendre explicites les étapes de chaque tâche facilite l’entraide entre les participants. En identifiant clairement les compétences et concepts nécessaires, il devient plus facile pour les gens de dire : « Oh, je comprends comment faire ça ! Attends, je vais te montrer ».

Suite

Il est possible que les contributeurs ne puissent pas finir les tâches sur lesquelles ils travaillent pendant l’événement, ou qu’ils veuillent continuer à participer au projet en travaillant sur d’autres tâches. Penser en amont de l’événement à comment vous allez organiser sa suite rend plus facile l’échange d’informations avec les participants et la planification de la direction de votre projet.

Nous recommandons de demander à chaque participant de répondre aux questions suivantes à propos des tâches sur lesquelles ils ont travaillé. Donnez leur cette liste au début de l’événement : cela les aidera à documenter ce qu’ils font. Vous pouvez imprimer cette liste, l’envoyer par mail aux participants, faire un formulaire web, comme vous préférez.

Par exemple :

• Pour chaque tâche sur laquelle vous avez travaillé, veuillez répondre aux questions suivantes :
  • Sur quelle tâche avez-vous travaillé ?
  • Veuillez documenter brièvement votre workflow. Quelles étapes, dans quel ordre, pourquoi ?
  • Où puis-je trouver le travail que vous avez réalisé pendant l’événement ? Ceci inclut le code, la documentation, les maquettes, et autres choses.
  • Si vous avez créé des comptes pour le projet, veuillez lister les sites et les noms des comptes. Enregistrez le mot de passe dans votre gestionnaire de mot de passes préféré, ou assurez vous que moi ou un autre mainteneur y aie accès.
  • Quels obstacles avez-vous rencontré en travaillant sur cette tâche ? Avez-vous des retours à me faire pour améliorer le processus pour les futurs contributeurs ?
  • Voudriez-vous rester impliqué dans ce projet ? Si oui, dans quelle mesure ?

S’il y a suffisamment d’enthousiasme pour continuer le travail, assurez-vous de rester en contact ! Nous suggérons que vous rassembliez les emails des participants intéressés et que vous les contactiez dans les 48 heures suivant l’événement. Dans votre email, remerciez-les pour leur aide et fournissez des informations sur comment rester dans la communauté par, par exemple, IRC ou des listes de diffusion.

Nous recommendons aussi de prévoir un rendez-vous suite à l’événement. Si vous êtes tous originaires de la même région, essayez de fixer une date après l’événement pour vous et votre équipe au café du coin, à l’espace de coworking, ou à une soirée-projet. Si vous êtes éloignés géographiquement, fixez une date pour vous rencontrer sur IRC ou sur Google Hangout. 2-3 semaines après l’événement est un bon créneau, toutefois cela dépend si vous et vous nouveaux contributeurs êtes très occupés.

Checklists

Merci de votre attention ! Pour vous aider à garder un oeil sur chaque étape, nous avons créé deux checklists pour vous. La version détaillée inclut tous les conseils ci-dessus. La checklist la plus courte inclut les conseils que nous pensons les plus importants. Nous vous recommandons de démarrer avec la cheklist la plus courte. Une fois que vous avez accompli correctement cette checklist, vous pouvez revenir et faire les étapes supplémentaires si vous avez le temps et l’énergie.

Pour voir et/ou imprimer les checklists, se rendre ici.

Remerciements

Merci à tous ceux qui ont contribué ou aidé au projet.

Contributeurs

• Shauna Gordon-McKeon : maintenance, contenu
• Ni Mu : design
• Sheila Miguez : testeuse
• Asheesh Laroia : testeuse

Pour aller plus loin

• Open Advice (NdT : entièrement traduit par nos soins)
• Producing Open Source Software (NdT : entièrement traduit par nos soins)