Écrire

Publié le par /

Ce carnet

Le principal motif de l’ouverture de ce nouvel espace était d’essayer de me débarrasser de la difficulté croissante que j’ai à écrire sur mon carnet principal. Parce que j’y ai mis la barre trop haute, je cherche à publier des articles relativement complets. Or j’ai beaucoup de mal à terminer un article. Toujours le sentiment d’avoir oublié quelque chose, qu’en y réfléchissant quelques jours de plus je vais penser à un détail supplémentaire important. D’où un certain nombre de brouillons que je ne publie jamais. Savoir qu’écrire un article va me prendre plusieurs heures est aussi un bon frein pour ne pas commencer. J’essaie ici de m’enlever ces contraintes : je publie des brouillons que je veux pouvoir faire évoluer dans le temps. L’utilisation d’un gestionnaire de versions, comme pour le code, permettant de suivre ces évolutions1. J’ai écrit en gros que c’est une zone réservée aux ébauches, pour m’autoriser les billets courts, les simples notes, pour essayer de retrouver le plaisir d’écrire sous l’effet d’une impulsion. Le pari est loin d’être gagné, il faudrait entre autre encore que je me laisser aller à écrire sur d’autres sujets que Mozilla, mais l’expérience est intéressante à mener.

L’autre raison était d’adapter l’outil à mes pratiques. Depuis plus d’un an à présent, mon éditeur de texte est Vim. Je l’utilise pour coder, écrire mes mails (dans Mutt), écrire tout court. J’y ai mes automatismes, et du mal à utiliser d’autres éditeurs. Écrire dans Vim puis copier/coller dans l’interface Web de Dotclear où je reprenais alors le texte pour corriger les soucis de mise en page n’était pas un flux très satisfaisant, l’actuel, basé sur Vim et Jekyll me plait davantage, même si je ne suis qu’à moitié satisfait de Jekyll2. Publier une nouvelle note est aussi simple que créer un fichier, y ajouter deux lignes d’entête, écrire, écrire, écrire, avec un formatage minimal (markdown, HTML pour les besoins spécifiques), enregistrer, et voilà, la note est en ligne. Penser de temps en temps à publier dans le dépôt local et à pousser vers sa copie sur Github. Le tout sans lever une seule fois les mains du clavier, sans perdre de temps avec la souris. Cette chaîne de production me satisfait davantage que la précédente.

Enfin un motif beaucoup plus utopique est d’essayer de voir ce que les licences libres peuvent faire de textes si on s’inspire du fonctionnement du logiciel. Jusqu’à présent, lorsqu’il s’agit de « littérature » nous sommes très timides dans l’utilisation des libertés que nous garantissent les licences libres. J’ai l’impression que la principale utilisation de ces libertés est la reprise d’un article, parfois légèrement modifié, dans un autre média. Mais pas l’utilisation d’extraits dans d’autres textes, ou la publication d’une version réellement modifiée, augmentée par exemple, dans un autre carnet3. Je vois passer peu de réelles œuvres dérivées. Github a introduit une nouvelle culture dans le développement de logiciels libre. Hier, le fork était généralement un signe d’échec, un acte violent. On hésitait à s’approprier à code, à lui faire prendre d’autres routes. Depuis Github, le fork est devenu au contraire le point de départ de tout chemin. Reprendre un bout de code pour le modifier, l’adapter, le faire croitre à son idée, est simple comme un clic sur le bouton « Fork ». En plaçant mes textes sur Github, j’aimerais encourager cet esprit. Que quelqu’un réponde à un texte en le forkant et publiant sa propre version4.

Je trouve l’aventure de Karl Dubost, François Bon et Jean-François Gayrard porteuse d’espoir pour le développement de la culture libre. Karl écrit des textes. Sa démarche est que (…) tout texte est le début d’une écriture. Avec la licence CC-BY, il rend toute personne libre de pouvoir réutiliser les textes, les transformer, les poursuivre, etc.(…). François et Jean-François diffusent des textes. Ils sont partis de la matière trouvée dans la branche pour créer deux nouvelles œuvres. Lesquelles en inspireront je l’espère d’autres. Je n’ai bien sûr pas la prétention de me comparer au talent de Karl, ou de qualifier de littérature les notes gribouillées sur ce carnet. J’essaie juste de réfléchir à ma modeste échelle à ce que l’esprit du libre pourrait apporter en soufflant ailleurs ailleurs que dans les allées de nos bazars logiciels.

Un manque

Le principal inconvénient de la solution technique choisie pour ce carnet est l’absence de commentaires. De moyen simple pour quiconque passe par ici de corriger mes conneries, ou partager une réflexion pour faire avancer le similiblink. Pas forcément d’engager la discussion, je ne suis vraiment pas doué pour ça, mais d’avoir au moins quelques retours, quelques réactions.

Si je n’ai pas encore ajouté de moyen de commenter les notes, c’est que je cherche à continuer dans l’expérimentation. Les mécanismes classiques de commentaires en ligne ne me satisfont pas. Avant de trouver une solution technique pour permettre des interactions autour des notes, je voudrais réfléchir sur le statut des commentaires, trouver un moyen de les gérer respecteux et de leurs auteurs, et des éventuels lecteurs.

Si le texte est une forme de code, est-il envisageable de renvoyer à Github et à ses fonctions sociales pour commenter ? Considérer les commentaires comme des revues de code ? L’idée ne me séduit guère. Elle confie les commentaires à un site externe (qui actuellement n’héberge qu’une copie de mon dépôt et ne possède pas de données supplémentaires). Oblige qui veut commenter à s’inscrire sur ce site. Et ne permet, je crois, les commentaires, que sur les commit et non sur les fichiers eux-même. Ce n’est ni pratique, ni acceptable, exit cette option.

Je pourrais faire appel à un service externe, avec une interface en JavaScript par exemple. Mais cela me rendrait dépendant de ce service, et je ne sais quel degré de contrôle ces services offrent (possibilité d’exporter les commentaires, de les supprimer ?). L’idée ne me séduit guère.

Je pourrais créer un formulaire, associé à une base de données textuelle, et un petit script qui… stop ! Je ne vais pas ré-inventer un n-ième CMS, l’envie m’est heureusement passée depuis quelques années.

Je pourrais… mais en fait non.

Aucune de ces solutions ne répond à un problème majeur des commentaires tels qu’ils sont gérés actuellement. Celui de la dispersion des contenus. Il est des gens dont l’essentiel de la réflexion en ligne est dispersée dans des commentaires à des centaines d’endroits. Une fois le formulaire validé, ils n’ont plus de contrôle sur leur prose, peuvent difficilement la corriger ou la supprimer s’ils la regrettent. Tout aussi difficilement l’archiver. Et qui s’intéresse à leurs écrits n’a aucun moyen aisé de les suivre. La situation a sans doute quelques avantages, mais elle ne me satisfait pas. On devrait disposer d’un moyen simple de conserver cette part de notre mémoire que composent l’ensemble des commentaires que l’on sème sur la toile. Comme l’on conserve une copie des messages que l’on envoie.

Le courrier électronique, voici peut-être une solution. Il se prête bien mieux aux discussions. Permet de les archiver. Gère les réponses, les fils multiples. Peut-être pourrais-je créer une liste de discussion ouverte, y poster un message pour chaque note publiée ici, et lier la note à son fil dans les archives de la liste. À bien y réfléchir, il est un format qui se prêterait encore mieux à l’exercice. Ce bon vieil Usenet. Créer un groupe pour ce carnet, un fil pour chaque note… Correctement paramétré, c’est sans doute la solution qui offrirait aux auteurs de commentaire le plus de contrôle, leur permettant par exemple de supprimer leurs messages.

Je ne suis pas encore fixé. Et très curieux de vos avis. En attendant mieux, les réactions sont bienvenues sur mon mail.

  1. il serait d’ailleurs pratique que Github fournisse un flux RSS pour chaque fichier du dépôt, ce qui permettrait de s’abonner pour être informé des mises à jour d’un texte.

  2. j’ai choisi Jekyll pour son intégration à Github — que je n’arrive d’ailleurs pas à utiliser pour l’instant, à cause de soucis d’url de base du site, mais c’est un détail. Mais il a un gros défaut : il utilise des technologies que je ne connais pas et n’envisage pas d’apprendre prochainement, Ruby par exemple. Difficile donc de lire le code lorsque je m’interroge sur le fonctionnement de certaines options, et encore plus de le modifier pour l’adapter à mes besoins. Il va falloir que je trouve le temps de regarder ses équivalents dans d’autres langages que je pratique davantages, comme par exemple DocPad en node.js;

  3. du moins dans le monde des carnets de geeks, j’espère que dans celui des carnets littéraires les expérimentations vont plus loin;

  4. l’idéal serait de ne pouvoir forker qu’un seul fichier, et non l’ensemble du dépôt, il y a encore du travail à faire par là;

Pour réagir, n'hésitez-pas à m'écrire : clochix chez clochix.net ou à soumettre l'url de votre commentaire :
(Je traite les mentions à la main, elles peuvent mettre plusieurs jours avant d'apparaître)

Si vous avez un compte Github, vous pouvez me proposer des corrections en éditant ce billet

Fork me on GitHub