le samedi, mars 25 2017, 20:14

Tutoriel : contribuer à un projet sur Github sans taper la moindre ligne de commande

Dans le billet précédent, j’ai essayé d’expliquer comment partager et modifier une œuvre sous licence libre Creative Commons. Ici, je voudrais aborder un autre point : comment contribuer à une œuvre libre existante pour proposes ses modifications à l’auteur ou l’autrice, avec l’exemple en particulier de Github.

Par exemple, les fichiers sources, au format Markdown, d’un certain nombre de mes textes sont disponibles sur Github, ce qui facilite la possibilité d’y apporter une contribution ou de proposer une version dérivée. Sauf que, si vous n’êtes pas développeu·r·se informatique, il y a des chances que vous ne trouviez pas cela très simple d’accès et que votre réaction soit quelque chose comme « oh la, c’est quoi encore ce truc de geek ?! ». Pourtant, il est possible d’utiliser Github pour apporter une contribution sans avoir à taper de commandes ésotériques.

Je prends ici l’exemple de mes textes, mais il est évident que ce sera peu ou prou la même chose si vous désirez apporter des modifications à d’autres textes libres hébergés sur Github, y compris s’il s’agit de la description ou de la documentation de votre logiciel libre préféré.

À des fins didactiques (et parce que ça m’amusait), ce billet contient un certain nombre de screenshots (moches). Ils ne sont pas forcément très lisibles tels qu’affichés dans le corps du texte, mais vous pouvez cliquer dessus pour les agrandir.

Étape préalable : vous créer un compte sur Github

Avant toute chose, si vous voulez contribuer à un projet hébergé sur Github, il vous faudra vous créer un compte. Bon, ce n’est pas très compliqué : ça demande juste de choisir un identifiant, de rentrer une adresse mail et de mettre un mot de passe. La procédure habituelle, certes rébarbative mais pas outrageusement ardue.

Github est axé pour les développeurs et développeuses informatique, et cela peut être intimidant si vous n’y connaissez rien. Cela dit, rassurez-vous : vous pouvez vous contenter d’ignorer les messages du type « Built for developpers », car il est aussi possible d’utiliser un certain nombre de fonctionnalités sans avoir à écrire la moindre ligne de code ni taper la moindre commande.

Signaler un souci, émettre une suggestion, etc.

La première possibilité est de faire remonter un souci (coquilles, mauvaise mise en page, répétitions à un endroit), etc. Pour cela, il est facile d’ajouter une issue sur Github :

issues.jpg

new_issue.jpg

Il suffit ensuite de décrire le problème, en donnant un titre et un commentaire. Bien sûr, plus c’est détaillé, mieux c’est :

Sujet : Fautes

Ouais y’a des fautes

n’est pas très utile, alors que

Sujet : Fautes dans Pas tout à fait des hommes

J’ai repéré quelques fautes dans Pas tout à fait des hommes :

- chapitre 3: “Il l’a mordu” -> “Il l’a mordue”

- chapitre 7: “Elle a attrapé son son épée” -> “son” en double

l’est beaucoup plus.

Bien sûr, il est possible de laisser des commentaires pour autre chose que des fautes, que ce soit pour faire remarquer qu’un passage n’est pas très compréhensible, signaler un problème de lecture sur telle liseuse, ou encore demander de nouvelles « fonctionnalités » (dans le cas d’un texte de fiction, le terme peut paraître étrange, mais on peut envisager des choses comme « je trouverais ça cool que les fichiers soient disponibles au format MOBI »).

Évidemment, pour tout ça, il n’est pas nécessaire en soi de passer par Github : dans mon cas, vous pouvez aussi m’envoyer un mail, par exemple (lizzie at crowdagger point fr). L’intérêt est surtout :

  • pour les projets (plutôt logiciels) qui ont beaucoup de rapports de bug à traiter ;
  • pour les projets un peu plus collaboratifs : ça permet aux contributeurs et contributrices de voir ce qu’il y a à faire, et de proposer des changements ;
  • à titre personnel, ça me sert plutôt de « TODO list », pour noter les choses qu’il faudrait que je fasse un jour.

Proposer des changements directement sur Github

Github propose également une interface en ligne pour modifier des fichiers. C’est d’autant plus facile avec des fichiers Markdown, car c’est ce qu’utilise Github pour sa documentation.

Le plus compliqué est sans doute de repérer à quel fichier Markdown correspond à le passage vous êtes en train de lire, et cela peut demander de fouiller un peu dans les répertoires. Notamment sur des dépôts comme le mien où tout n’est pas forcément toujours très bien rangé (et encore, vous n’avez pas vu mon appart’).

Par exemple, admettons que je veuille modifier Réagir sans violence pour changer la mise en page des dialogues. Le plus compliqué est sans doute de deviner qu’il s’agit du fichier hell_butches/sigkill.md (reagir_sans_violence.md serait sans doute plus logique, certes, mais voilà).

Une fois que je suis sur la bonne page, Github propose un bouton pour éditer le document :

edit.jpg

Une fois que j’ai cliqué dessus, il est possible d’éditer le texte, au format Markdown.

Une note sur le format Markdown

Le format Markdown est juste du texte, avec quelques éléments en plus pour dire qu’il s’agit d’un titre, d’un lien, ou pour mettre en italique. Concrètement, pour des romans, il y a essentiellement deux éléments pour la mise en page, les titres et les italiques :

  • ce *mot* est en italiques, ce *groupe de mots* aussi affichera « ce mot est en italiques, ce groupe de mots aussi ».
  • pour les titres, on « souligne » le titre de chapitre en mettant des ==== à la ligne suivante :
Titre de chapitre
=============

(Si vous voulez en savoir un peu plus, vous pouvez regarder le tutoriel Markdown in 60 seconds.)

Github utilise beaucoup Markdown, et il est donc possible de prévisualiser les modifications pour voir si le résultat correspond bien à vos attentes.

preview.jpg

Cette fonctionnalité montre également les changements que vous avez apportés au fichier :

modif.png

Soumettre les modifications

Une fois satisfaite des modifications, je peux les soumettre à l’autrice[1] en remplissant le mini-formulaire en bas de la page :

soumettre.png

Il ne me reste plus alors qu’à vérifier vite fait les modifications apportées, et je peux créer une pull request (en gros une proposition de modification toute automatisée, qui peut être acceptée d’un clic) qui sera envoyée à l’autrice.

pull_request.png

Encore une dernière étape pour valider le texte du commentaire, et voilà, la contribution est envoyée, et l’autrice n’a plus qu’à la valider ![2]

À quel moment devient-on co-auteur (co-autrice) ?

On a jusque là uniquement parlé de l’aspect technique de la contribution. Il me semble pourtant que les aspects juridiques sont importants, et méritent d’être abordés. Et notamment la question : à partir de quel moment avez-vous un statut de « co-auteur » sur le texte final (à supposer, évidemment, que la contribution soit acceptée) ?

Je ne suis pas juriste, mais si je comprends bien les choses, le critère est qu’il y ait un aspect « créatif » à la contribution. Par exemple, corriger des fautes d’orthographe ne rentre pas dans cette catégorie, pas plus que mon exemple précédent sur la mise en page des dialogue. En revanche, à partir du moment où il y a, par exemple, rédaction d’un paragraphe supplémentaire, il y a dans ce cas une contribution « créative », et vous devenez, dans ce cas, co-autrice ou co-auteur du texte final.

Même si ce n’est pas toujours formalisé explicitement, il est en général admis qu’à partir du moment ou vous envoyez une contribution à un projet libre, vous acceptez que votre contribution soit également distribuée sous les conditions de la (ou des) licences du projet (en l’occurrence pour mes textes libres, Creative Commons Attribution - Partage dans les Mêmes Conditions 4.0 International).

À partir de ce moment là, vous êtes donc sur un pied d’égalité avec l’autrice de l’œuvre original : vous pouvez, comme elle, distribuer l’œuvre de votre côté (y compris, selon les licences, de manière payante). S’il s’agit (comme c’est le cas ici) d’une licence dite copyleft, vous n’êtes pas libre, en revanche, de distribuer l’œuvre de manière privatrice, mais l’autrice de l’œuvre originale ne peut pas le faire non plus (à moins évidemment de retirer votre contribution et de revenir à une œuvre dont elle est l’unique autrice).

Par exemple, à l’heure actuelle, je peux aller voir un éditeur, lui montrer Pas tout à fait des hommes, lui proposer de faire ensemble quelques modifications à l’œuvre et de diffuser cette version avec un contrat d’exclusivité[3]. Si vous contribuez à ce livre en réécrivant des passages, en ajoutant des scènes, etc., je n’aurais plus le droit de le faire (du moins sans votre accord).

Ça peut paraître un peu du pinaillage juridique, mais je pense que c’est important, car c’est ce qui met un garde-fou important (même s’il reste relatif) à l’exploitation du travail gratuit des contributeurs et contributrices.

Parfois, certains projets demandent, avant d’envoyer une contribution, de signer par ailleurs une cession de droits envers l’auteur original (ou une entreprise ou une association), ce qui lui permet ainsi une plus grande flexibilité pour pouvoir changer de licence pour le projet. Je ne suis pas très fan de ce genre de procédé[4], qui casse l’égalité entre les contribut·eur·rice·s, et fait, je trouve un peu rentrer la contribution dans le domaine du travail gratuit plus que de la collaboration.

Quand contribuer, et quand créer une œuvre dérivée ?

Cette question n’est pas forcément spécifique aux textes, mais peut aussi s’appliquer aux programmes : à quel moment faut-il plutôt essayer de contribuer à l’œuvre originale, et à quel moment vaut-il mieux créer une œuvre dérivée (ou un fork dans le monde du logiciel) ?

Évidemment, ça dépend un peu de chaque personne, mais j’aurais tendance à dire :

  • Pour des modifications mineures, dont on sait clairement qu’il y a des chances qu’elles soient acceptées (correction de fautes d’orthographe, bugfixes), il paraît plus constructif de contribuer à l’œuvre originale ; à vrai dire, si quelqu’un publiait une version modifiée d’un de mes textes libres en disant « celle-là est mieux, j’ai corrigé plein de fautes » et en me laissant galérer à essayer de trouver ce qu’il a corrigé, je l’aurais un peu mauvaise (sauf bien sûr s’il m’a envoyé les modifications mais qu’il s’agit d’un vieux texte sur lequel je n’ai plus envie d’accorder la moindre énergie).
  • Pour des modifications d’importance, dont on n’est pas certain que l’autrice va vouloir les intégrer (réécriture d’une partie de l’histoire, ajouts de paragraphes, ajout ou modification de fonctionnalités pour un logiciel), on peut toujours les soumettre, mais tout en ayant en tête qu’elles seront peut-être rejetées parce qu’il est possible qu’elle soient incompatibles avec une certaine vision du projet.
  • Parfois, un effet, il y a en effet des visions divergentes d’une même œuvre ou d’un même logiciel. C’est l’intérêt du libre de pouvoir permettre qu’elles coexistent, plutôt que de donner tout le pouvoir à la personne qui détient les droits originaux. Dans ce cas, il est logique de créer une œuvre dérivée plutôt que d’essayer à tout prix de concilier deux visions inconciliables (pour reprendre mon exemple du début : histoire lesbienne ou histoire gay, ou encore : logiciel qui fait plein de chose ou logiciel qui se spécialise sur quelque chose de précis et ne cherche pas à gérer le reste).

Conclusion

J’espère aussi vous avoir un peu convaincu·e que contribuer à un projet libre n’est pas aussi compliqué que cela peut le sembler. J’ai personnellement mis longtemps avant d’oser envoyer des pull requests sur Github, mais avec l’interface Web, cela peut se faire de manière plutôt simple lorsqu’il s’agit de corriger des fautes, des liens cassés ou de reformuler une phrase pas très compréhensible, et cela ne requiert en fait aucune compétence en informatique.


Si vous aimez ce que j’écris, vous pouvez me soutenir sur Tipeee à partir d’1€ par mois, ce qui vous donnera accès à mes prochains textes de fiction en avant-première.

Pour avoir des informations sur mes parutions, vous pouvez vous inscrire à ma liste de diffusion (faible trafic, pas plus d’un mail par mois).


Notes

[1] Qui, dans ce cas précis, n’est autre que moi-même, certes.

[2] Ce qu’elle a d’ailleurs fait très rapidement, à croire qu’elle savait qu’elle allait recevoir une telle contribution.

[3] C’est d’ailleurs plus ou moins ce que je fais, sans le côté exclusivité : en effet, la couverture des versions de ce roman distribuées sur Amazon, Kobo, etc. n’est pas sous licence libre, et pour cette raison l’ebook distribué sur ces plate-formes n’est pas sous licence CC-BY-SA.

[4] Même si je nuancerais quand même un peu selon le destinataire : j’aurais moins de mal à signer cette clause pour la Free Software Foundation que pour Google.

24 mar.

À lire gratuitement : les deux premiers chapitres de "Les coups et les douleurs" (La chair & le sang #1)

episode_01.png Je m’appelle Jessica, je viens d’emménager dans une nouvelle ville, et je cherche juste à faire comme tout le monde : trouver un travail, rencontrer l’amour, et avoir une vie stable et satisfaisante. [...]
22 mar.

Tutoriel : partager et modifier une œuvre sous licence libre Creative Commons

Comme vous le savez peut-être, la plupart des textes qui sont publiés en auto-édition sur ce site sont diffusés sous licence libre Creative Commons Attribution-Partage sous les mêmes conditions, ce [...]
20 mar.

Petits changements de tarif : prix libre numérique, mais ça monte pour les fanzines

Pour faire bref, le cœur du message de ce billet de blog, c’est que les versions numériques des épisodes de La chair & le sang seront maintenant à prix libre, tandis que les versions fanzines [...]
15 mar.

Retour sur "Enfants de Mars et de Vénus" #1 : Alys et les clichés trans

enfants-mini.png J’ai décidé de faire quelques articles pour revenir un peu sur Enfants de Mars et de Vénus, maintenant qu’il est sorti, à la fois pour prendre le temps de regarder en arrière avec un peu de recul, et [...]
03 mar.

Ce que j'aimerais dans une association (syndicat?) d'auto-édité·e·s

Il y a quelques jours, Neil Jomunsi annonçait la création de l’Alliance des Auteurs Indépendants Francophones, puis, son désistement au profit d’une Fédération des Auteurs Indépendants. Il y a eu un [...]
09 fév.

Le 15 février à Violette and Co (Paris) : rencontre pour présenter Enfants de Mars et de Vénus

enfants_couv_png.png Je serai à Paris le 15 février à la librairie Violette and Co, à l’occasion du festival des Cultures LGBT, pour discuter autour d‘Enfants de Mars et de Vénus. En plus de présenter le livre, je [...]
06 fév.

Petit retour sur ''La chair & le sang'' : genèse du projet

episode_01.png Après la publication du premier épisode de La chair & le sang, j’avais envie me poser un peu pour revenir sur comment je me suis mise à écrire ce projet, et pourquoi, sur certains aspects, il est [...]
03 fév.

Pseudoconseils autoédition #3: le format EPUB

Articles précédents dans la série : L’auto-édition, pourquoi ? Typographie, composition et mise en page Aujourd’hui, je vais parler un peu du format EPUB, utilisé pour le livre numérique. J’essaierai [...]
30 janv.

Pseudoconseils autoédition #2 : Typographie, composition et mise en page

pere_blaise.jpg Article précédent dans la série : l’auto-édition, pourquoi ? Avertissement : cet article est long et chiant. Il y a sans doute déjà des tas d’articles existants, mais j’avais envie d’en faire un quand [...]
28 janv.

Pseudoconseils autoédition #1: l'auto-édition, pourquoi ?

Il semble être d'usage pour à peu près tout écrivain·e pratiquant l'auto-édition et ayant un blog de faire une série d'articles donnant des conseils sur l'auto-édition, et, malgré ma réticence à [...]
22 janv.

Enfants de Mars et de Vénus sortira le 23 février, présentation à Paris le 15

enfants_couv_png.png Je suis très heureuse de vous annoncer qu’Enfants de Mars et de Vénus sortira le 23 février, et de pouvoir enfin vous présenter la couverture : Enfants de Mars et de Vénus est un polar fantastique, où [...]
16 janv.

La chair & le sang #1 : Les coups et les douleurs maintenant disponible aux abonné·e·s

episode_01.png Ça y est, le premier épisode de La chair & le sang, série de fantasy urbaine lesbiano-vampirique est disponible pour les abonné·e·s Tipeee ! Il s'intitule Les coups et les douleurs, et l'on y [...]
02 janv.

Bilan auto-édition 2016

Vu que je l'avais fait l'an passé, revoilà un petit bilan pour mes livres auto-édités en 2016, qui, comme son nom l'indique, ne prend en compte que le versant auto-édition. Je suis un peu sceptique [...]
31 déc.

Crowbook, version 0.11.0

logo.png Oui, je viens encore vous embêter avec Crowbook, mais, promis, c'est la dernière fois de l'année ! Mais c'est quoi, déjà ? Pour rappel, Crowbook est un logiciel libre (licence LGPL) qui convertit des [...]
12 déc.

Réflexions sur les enjeux dans un roman

Ça fait quelques temps que j'avais cette idée d'article en tête : parler des enjeux dans un roman (ou une nouvelle), pas dans le sens de parler des enjeux d'écrire un roman mais des enjeux qui sont [...]
06 déc.

Des numéros de version pour de la fiction, quelle drôle d'idée !

Certaines personnes auront peut-être remarqué que depuis quelques temps, en tout cas pour les versions HTML, certains des textes disponibles sur ce site se voient affubler d'un numéro de version. Par [...]
04 déc.

Nouvelles papier DIY #2 : Tromperies sur la marchandise + Une mine de déterrés

PayPal, le réflexe sécurité pour payer en ligne Mise à jour : ça y est, les impressions ont été faites et empaquetées, il n'est donc plus possible de commander ce « pack ». En revanche, vous pouvez toujours commander les versions papiers des textes [...]
19 nov.

Crowbook, version 0.10.3

logo.png Comme ça fait quelques mois que je n'en avais pas parlé, je me suis dit qu'il pouvait être intéressant de faire un petit billet à l'occasion de la sortie de la version 0.10.3 de Crowbook. Rappel Pour [...]
15 nov.

Anti conseils d'écriture, #1 : écrire tous les jours

J'ai l'impression que les conseils pour les auteurs fleurissent, et c'est très bien : ça permet notamment de rendre accessible certaines notions à des gens qui n'ont pas fait d'études poussées de [...]

- page 1 de 5