- Download:
- Podcasts Underscore57 MB
Actu
GoogHell, un site pour recenser les bourdes de Google
Il existait déjà un site pour Facebook : Days since the last Facebook scandal.
Facebook et Microsoft Edge changent de logo
L’entreprise « Facebook » qui détient « Facebook » mais aussi Instagram et WhatsApp veut donc marquer la différence.
Quand à Edge, il veut se distancer du logo actuel bien trop proche de celui d’Internet Explorer. Mais du coup maintenant il ressemble au nouveau logo de Firefox avec des couleurs différentes…
Microsoft veut contribuer à Java
Et devient membre d’OpenJDK.
AV1 est utilisable !
AV1 est un nouveau codec aux performances rivalisant avec h265, poussé par Mozilla et Videolan. Il a l’avantage de pouvoir être utilisé sur le web dans un conteneur webm et est déjà supporté par la majorité des navigateurs.
Selon OVH, « les ministères français ignorent que leurs données sont hébergées sur des serveurs américains »
Oh, c’est étonnant…
Janayugom, le premier quotidien à n’utiliser que du logiciel libre
Ce journal papier du sud de l’Inde ayant 100000 lecteurs, vient de passer à Scribus, Ubuntu et KDE. Voulant se débarrasser de l’antique Adobe PageMaker qu’ils utilisaient jusqu’ici et qui ne supportait même pas Unicode, ils ont réalisé que son remplaçant, InDesign, n’était disponible qu’avec des licences en location. Ils ont au passage créé trois polices de caractères libres avec les caractères nécessaires au Malayalam.
Le créateur de Python prend sa retraite
Guido Van Rossum à 63 ans a décidé de prendre sa retraite. « ça a été une aventure incroyable ».
La DINSIC devient la DINUM… et perd certaines missions au passage
La DINSIC, direction interministérielle des systèmes d’information et de communication, change denom et devient la Direction interministérielle du numérique (DINUM). Mais visiblement il n’y a pas que le nom qui change, les organisations syndicales ont dénoncé le manque de concertation et l’abandon de certaines missions historiques.
Musique : Lis ce putain de manuel (ACDC Highway to Hell Ukulele cover)
Par Clément Oudot, reprise de ACDC au Ukulele en clôture de la conférence « Le guide du connard du Logiciel Libre » à Paris Open Source Summit 2017.
Sujet : Comment contribuer ?
Je souhaitais aborder ce sujet depuis un moment, et l’arrivée des contribateliers à Grenoble m’a décidé.
Et si ça intéresse des gens qu’on en fasse à Valence, dites-le nous, on fera suivre !
Et, oh, coïncidence, demain est aussi le début du Google Code-In.
Java donc parler de contribution. Enfin, si c’est à Java que vous voulez contribuer, c’est à OpenJDK qu’il faut parler !
Pourquoi contribuer ?
Ben, parce que si quand c’est gratuit, c’est toi le produit, si c’est libre faut le faire vivre.
Une des façons est de donner des sous ou payer les développeurs directement.
Mais on a pas forcément les moyens nous-même, par contre on peut trouver un peu de temps pour aider un projet différemment.
Il y a mille et une façons de contribuer, suivant le projet, ses propres compétences, son temps disponible…
Même si vous ne savez pas coder vous pouvez donner votre aide.
Par exemple, en relisant la documentation, en essayant d’installer et d’utiliser le logiciel pour trouver des bugs ou même juste une situation où la documentation n’est pas claire sur ce qu’il convient de faire ou bien comment faire quelque chose.
Ces temps-ci pas mal de projets s’intéresse au design, qui souvent est carrément oublié dans le libre il faut le dire, car les codeurs font en premier le logiciel pour eux-même, et donc en fonction de leur propre besoin.
Disons aussi que les designers n’ont pas non plus vraiment la culture du libre, ou quand ils veulent contribuer sont parfois juste ignorés.
Heureusement ça change, et c’est bien car l’ergonomie et la facilité d’utilisation d’un outil prime pour de nombreuses personnes sur son utilité réelle et encore plus sur son éthique
Autrement on utiliserait tous Haik, euh, GNU/Linux, Searx, GnuPG…
On va ici surtout parler de contribution aux logiciels, mais certaines choses s’appliquent aussi à Wikipédia ou OpenStreetMap…
Comment qu’on fait alors ?
RTFM.
Hein, quoi ?
RTFM (Read the f*****/fine manual) : Lis ce gentil manuel !
Ah, oui, bon, on a dit qu’on arrêtait avec les RTFM justement…
C’est vrai qu’à une époque on reprochait aux développeurs de logiciel libre une certaine arrogance lorsqu’à une question déjà posée 10 fois ils répondaient RTFM.
Ceci dit, il faut parfois vraiment de la patience pour expliquer une dixième fois la même chose. Mais ce n’est à ce prix qu’on évite de faire fuire les gens.
Donc, comme on a dit, on lit la doc, enfin au moins on essaye de trouver la documentation du projet, s’il y a des informations sur comment contribuer…
Certains projets ont même un « Guide du contributeur ».
Malheureusement ce n’est pas toujours le cas.
Surtout pour les projets récents et assez petits, on se contente souvent de déposer le code sur une forge logicielle, typiquement GitHub, qui si elle a permis une certaine standardisation et facilitation du processus de contribution, fait aussi parfois croire que c’est toujours aussi simple que trois clics.
Ensuite, il peut être intéressant de trouver le canal de communication privilégié des développeurs.
Cela peut-être IRC (si si, c’est encore souvent le cas), ou des trucs plus exotiques. Certains préfèrent le mail encore. Même certains projets sur GitHub préfèrent ne pas utiliser les « pull-requests ».
En effet, chacun a sa propre méthode pour valider les contributions.
Parfois il y a plusieurs étages avant d’arriver en amont (vous entendrez souvent parler d’upstream). Ainsi pour arriver jusqu’à la branche principale de Linus on passe par les mainteneurs de la partie du noyau Linux qui vont d’abord vérifier eux-même vos différents patches (ça veut dire rustine).
Bien sûr, on vous redirigera toujours vers un canal plus approprié, mais c’est considéré comme une politesse de se documenter avant de poser une question qui semblera évidente au développeur, ou d’envoyer un patch directement à l’auteur alors que le site indique explicitement qu’il faut l’envoyer à la liste de diffusion pour que les autres les voient également, ou alors au mainteneur de la partie concernée.
Certains projets vous demanderont avant toute chose et même pour un changement de deux lignes de signer un papier, un accord de contribution, qui en général autorise l’auteur principal à faire ce qu’il veut avec vos patches, y compris changer la licence.
C’est souvent le cas pour des projets gérés par des entreprises (par exemple VirtualBox et d’autres projets de Sun rachetés avec par Oracle).
T’as un ticket ?
Pour suivre l’évolution d’un problème on utilise en général un système de suivi de bugs, où chaque cas est décrit dans un « ticket », dont l’état peut changer en fonction de l’avancement de la correction. Typiquement le ticket est assigné à un développeur qui le prend en charge, puis demande que l’on teste le correctif qu’il a implémenté, et enfin on « ferme » le ticket, avec une « résolution » qui peut varier de « fixed » à « wontfix » si on estime que bof c’est pas grave en fait.
Parfois un bug revient alors qu’on pensait l’avoir éradiqué. Il s’agit d’une régression. Plutôt que d’ouvrir un nouveau ticket, si on est sûr qu’il s’agit du même bug (même conditions, même erreur…), on préfère rouvrir le ticket précédent.
On peut aussi utiliser un ticket pour proposer une fonctionnalité qu’on a déjà écrite, en joignant un ou plusieurs patches.
Les tickets ne servent pas que pour les bugs, ils permettent aussi de proposer des « features » supplémentaires, même si ceux-ci n’ont pas la même priorité, ça permet de savoir si beaucoup de monde en a besoin, et si quelqu’un a déjà prévu de travailler dessus.
Traduction
Si vous parlez un peu anglais, traduire un logiciel qui n’est qu’en anglais est très utile.
Comme pour le code, chaque projet a ses outils et méthodes, en général expliqués quelque part dans la doc (souvent en anglais donc…).
Le principe général est de traduire des morceaux de phrases en respectant certaines règles pour pouvoir remplacer certains marqueurs par des nombres ou d’autres bouts de texte. Parfois il faut respecter l’ordre de ses marqueurs, suivant la façon dont le code fonctionne, et donc refaire la phrase.
Certains projets organisent des évènements de traduction, avec des personnes du monde entier qui contribuent en même temps, comme le WordPress Translation Day.
Il y a un groupe local d’utilisateurs de WordPress en Drôme-Ardèche.
Le code, le code !
Non mais on a dit qu’il n’y avait pas que le code justement…
Bon, ok, vous voulez coder.
Ben encore une fois il faut voir les outils utilisés par le projet.
En général (sauf si l’auteur se contente de publier des fichiers ZIP (hein, ça existe encore ?)), on utilise un système de gestion de version.
Le plus à la mode est Git, qui a de nombreux avantages malgré quelques inconvénients.
Un avantage est d’avoir tout l’historique, par contre la syntaxe est parfois cryptique et il faut chercher pour savoir comment faire certaines choses. Mais il est très puissant et permet par exemple de rejouer tous ses patches par dessus les nouvelles modifications officielles, de les mélanger pour en faire un seul, de les séparer pour nettoyer l’historique une fois qu’on a réussi à tout faire fonctionner…
On peut même utiliser Git pour des projets qui utilisent Subversion ou même CVS.
Le flux de travail est alors habituellement :
On clone le projet sur son disque dur.
Quand on commence à avoir un code qui fonctionne, il faut faire un commit, éventuellement sur une branche autre que celle par défaut.
Et puis quand on est content du code, on extrait des patches qu’on attache à un ticket, ou alors on pousse ses modifications sur un « fork » (une copie du projet qu’on peut modifier) puis on fait un « pull-request » (d’autres forges parlent de « merge-request » qui est plus correct).
Mais il faudra parler de ça une autre fois en détails.
Les programmes pour publics spécifiques
Certaines structures proposent des programmes pour aider certaines catégories de personnes à contribuer au logiciel libre.
Chez Google il y a GSoC (Google Summer of Code) permettant aux étudiants de passer un été à ajouter une fonctionnalité à un logiciel, et d’être payé un peu en échange.
Ils ont depuis une dizaine d’années aussi GCI, Google Code-In, qui lui s’intéresse aux élèves de 13 à 17 ans, pour leur donner une première approche de la contribution, avec un système de tâches à accomplir, comme rédiger une documentation, tester et trouver des bugs, réaliser une petite vidéo expliquant le projet, ou même faire du code en corriger certains bugs facile.
Et comme je l’ai dit ça commence demain, mais vous pouvez vous inscrire plus tard également. Cette année, 29 organisation proposent des tâches à résoudre.
Le projet Haiku participe depuis le début à GCI, et régulièrement à GSoC mais pas tous les ans, car c’est aussi du temps passé par les développeurs du projet à suivre les étudiants qui n’est pas passé à écrire du code directement.
Pour GCI, il faut préparer les tâches en triant les bugs existants, rédigeant des descriptions… puis échanger avec les participants pour vérifier qu’ils ont compris, qu’ils avancent… et puis vérifier qu’ils ont réussi.
Il existe aussi depuis cette année un Season of Docs, de septembre à novembre, qui permet à des adultes cette fois-ci de contribuer à la documentation des projets, qui est souvent délaissé par les codeurs, parce que ce qui les intéresse, bien sûr, c’est le code.
Même si on aime détester Google par ici, avec GCI et GSoC ils redonnent un peu (vraiment un tout petit peu) de ce que le logiciel libre leur apporte. Bien sûr pour Google c’est un moyen aussi de faire de la communication, et probablement au passage de détecter de futurs employés… Mais ça permet tout de même aux projets participants d’obtenir des contributions, et même parfois des contributeurs réguliers qui reviennent car ils aiment ce projet.
Le programme Outreachy du Software Freedom Conservancy propose des sortes de stages de trois mois relativement bien payés, en favorisant les minorités qui sont souvent sous-représentées dans les développeurs du libre, peut-être même plus que dans l’informatique en général.
Les Contribateliers
Dans le cadre de la campagne Contributopia de Framasoft, les contribateliers sont nés d’une volonté de faire rencontrer les gens physiquement.
Lors de ces évènements, on vous guide pour trouver des activités suivant vos compétences.
Cela va de la rédaction de documents de communication, tutoriels et autres, à la traduction, au design, et bien sûr au code. Sans parler des tests. Ah, si, on a dit qu’il faut en parler parce que justement on en parle jamais ? Ah ben si on en a parlé.
Même si, et justement si, vous n’avez pas de compétence technique, c’est l’occasion de trouver des intermédiaires pour vous aider à aider le libre.
Si vous utilisez un logiciel libre, mais qu’il vous manque une fonctionnalité, venez en discuter, et comprendre comment créer un ticket pour expliquer votre besoin aux développeurs.
Ça peut aussi être l’occasion de découvrir des associations locales (CHATONS, GULLs, hackerspaces) qui utilisent aussi du libre, et les rejoindre.
Chiptune: Kalax – DREAM
Agenda
Rappelons que l’agenda est celui de la semaine passée lors des rediffusions le samedi.
Premier Contribatelier Grenoblois
Fini la consommation, passons à la contribution ! Que vous soyez familier du code ou novice du numérique, cet atelier vous propose de découvrir comment contribuer aux logiciels et à la culture libre, dans la convivialité d’un apéro partagé.
Atelier organisé par Framasoft.
Sur inscription (sur le framaforms) ;
Le lundi 2 décembre, de 18h30 à 21h ;
La Turbine.Coop, 5 esplanade Andry Farcy, Grenoble, 38000 France.
Café Outils #Hors-Série : Openagenda
Comprendre les principes d’un agenda collaboratif ligne éditoriale, charte de contribution, implication des contributeurs.Contribuer de manière autonome à un agenda collaboratif via le service Open agenda.Diffuser et faire connaître un agenda.
Sur inscription;
Mardi 3 décembre, 9h30 – 13h30;
Loriol.
Astrologeek
- doctorante : « Arcep, fibre et paquet… des mots qui font rêver… » (spéciale dédicace à quota)
- technophile : il faut cesser l’essai des CMS !
- nerd : C’est le quel mon meilleur profil LinkedIn, le gauche ou le droite ? – T’en as deux ? – Bien sûr, pas toi ?
- codeur : vim sous le Sun en italique, ce n’est pas problématique, vient bien programmer , j’ai le coeur tout chose
- atariste : On va se quitter en bon Pterm()
- musicien : Je suis pas trop Shure du micro…
Comments are closed