Suivant sa logique, la faculté de théologie n’est pas mentionnée dans les partenaires du centre. Il est évident que ni cognition, ni langage, ni société ne l’intéressent. Normal, cela n’a rien à voir avec la théologie pratique définie ainsi dans son guide des études:

La Théologie pratique intègre des séminaires expérimentaux offrant des expériences de terrain. Les enseignements bénéficient des recherches sur les modes de communication de la foi chrétienne dans la société contemporaine et promeuvent l’élaboration personnelle d’une théorie de l’action pastorale.

Après la non participation à la MAPS et son programme Religion et ethnicité, la faculté de théologie poursuit sa marche vers l’insignifiance en ne participant pas au Centre de sciences cognitives et ses travaux sur les croyances.

Mais, comme on le sait désormais, tout va très bien. Pour la rentrée, les responsables de la faculté de théologie entonnent certainement leur hymne composé par Ray Ventura. Bonne année!

Il y avait encore pas mal de sujets à traiter, par exemple:

• les langages de balisage léger
• les systèmes de documentation
• DocBook et DITA
• et différents principes techniques intéressants

Je ne vais pas perdre mon temps à essayer de convaincre les convaincus. Et je laisse les utilisateurs de Word patauger dans la gadoue qu’ils semblent aimer

Joyeux Noël!

Tu m’as bien suivi et lu attentivement mes billets sur les licences, todo et changelog et les forks.

Tu es évidemment convaincu qu’il faut partager ce que l’on produit et en fixer les modalités simplement, tu es conscient que tu aideras tes prochains utilisateurs en leur disant ce que tu as fait et ce qui te reste à faire. Enfin, tu as compris qu’un dissidence n’est pas toujours une hérésie. Bien!

Je te propose de faire un pas de plus et d’utiliser un système de gestion de version, si possible décentralisé, comme Mercurial.

Voici ce que cet outil te permet de faire:

• de faire d’un répertoire une « zone suivie » par le système de gestion
• d’ajouter, modifier ou supprimer des fichiers
• lorsque tu modifies des fichiers, de commenter tes modifications
• d’envoyer tout cela sur un serveur

Ce qui signifie:

• que tu possèdes tout le changelog de ton projet
• que tu peux revenir à une version quelconque d’un fichier donné ou de tout le projet
• que tu peux mettre tout cela (=les fichiers et leur histoire) à disposition, pour suivre le projet ou faire un fork

Mais en plus, tu as quelques bonus (dont tu n’avais même pas rêvé) à disposition:

• tu peux créer des versions: dire qu’à un temps donné, l’ensemble des fichiers constitue une entité cohérente, par exemple tout ta documentation au début de ton année de catéchisme
• tu peux créer des branches: faire diverger une partie du projet, par exemple par une branche de maintenance (où tu corrigeras simplement les coquilles orthographiques) et une branche de développement (une sorte de mini-fork interne)
• tu peux travailler de manière décentralisée: tu reprends tout un projet du serveur, un collègue fait de même, et tout est renvoyé sur le serveur. Si vous avez travaillé sur des parties différentes, le projet hérite de toutes vos améliorations; si vous avez travaillé sur une même partie, il y a des outils pour résoudre les conflits

D’autres ont aussi présenté Mercurial:

Au même titre que Git et Subversion, Mercurial est un logiciel permettant de gérer l’évolution de fichiers, en les stockant sur un serveur tout en conservant un historique chronologique des différentes modifications. Ces outils sont notamment utilisés dans les projets informatiques qui nécessitent une certaine organisation et facilitent le travail collaboratif. Par exemple, si deux développeurs sont sur le même projet, la modification de l’un n’écrasera pas celle de l’autre : les deux versions seront conservées et le système permettra de revenir à une révision antérieure, de connaître les différences entre plusieurs versions, de fusionner des versions pour mettre à jour un fichier qui a été modifié entre temps, etc.

Penaud, tu te demandes pourquoi tu n’utilises pas encore un outil aussi puissant. Moi aussi! Pour t’y mettre, sache qu’il faut travailler avec des fichiers texte, ce que tout le monde devrait faire, et prendre le temps de comprendre l’outil. Une fois que ce sera fait, tu ne pourras plus t’en passer!

N’hésite pas, fidèle lecteur, à me contacter si tu souhaites utiliser un tel système pour un projet « littéraire ».

Wikipédia, entrée Fork, nous dit:

Un fork, ou embranchement, est un nouveau logiciel créé à partir du code source d’un logiciel existant. Cela suppose que les droits accordés par les auteurs le permettent : ils doivent autoriser l’utilisation, la modification et la redistribution du code source. C’est pour cette raison que les forks se produisent facilement dans le domaine des logiciels libres.

Si vous avez lu mes précédents billets sur le choix d’une licence et changelog et todo, vous comprenez déjà où je veux en venir. À condition de créer des conditions valables – offrir des droits (la licence) et permettre de comprendre ce que l’on a fait (le changelog) et ce qu’il reste à faire (le todo) –, il devient possible de faire des forks de projets autres que des programmes informatiques.

Reste donc à savoir pourquoi et comment on forke. Il y a en gros deux types de séparations: celle qui est amicale et celle qui ne l’est franchement pas. Quelques exemples:

• le fork amical: créer une version spécifique d’un produit, par exemple pour un public particulier, avec des spécificité qui ne méritent pas d’entrer dans le projet général.
•  et le fork technique, en général amical: le projet évolue et une ancienne version doit être abandonnée. Une équipe décide de reprendre cette ancienne version et de la maintenir à jour. Ou un équipe décide de faire avancer une branche du projet très rapidement, comme laboratoire pratique.
• vs le fork inamical: pour des raisons d’humeur, de désaccord technique majeur, de pouvoir, etc., des membres décident de créer un nouveau projet concurrent. C’est un schisme!

Il ne faut pas 5 minutes pour imaginer 10 projets (dans le monde ecclésial dont je parle souvent ici) qui mériteraient d’être maintenus selon une branche mère et des déclinaisons géographiques, pédagogiques, etc. Je vous laisse y réfléchir.

Pour rendre ce genre de choix possible, il faut un peu plus qu’une licence qui le permette et deux fichiers de documentation. Il faut, au minimum, pouvoir reprendre le matériau de base (code, textes, illustrations, etc.). Ce qui implique d’utiliser des formats acceptables, certainement ouverts, et si possible un système de gestion de version. Par un hasard heureux, c’est justement le sujet d’un prochain billet…

Le changelog, c’est le journal de bord des modifications effectuées, la liste de tous les travaux terminés. Le niveau de détail varie selon le projet: parfois on se réfère à un numéro qui donnera plus d’infos, parfois on commente beaucoup, parfois on liste simplement.

La todo list, c’est la liste de ce qui reste à faire. C’est elle qui donne la direction que prendra le projet. Elle sera à la fois d’aide-mémoire pour les auteurs du projet et d’indicateur pour ses utilisateurs.

C’est assez banal, au fond. On dit ce que l’on a fait et, en général, pourquoi. On dit ce que l’on souhaite faire. Banal mais rare!

Dès que l’on sort du développement informatique, par exemple pour passer dans le monde du texte, les projets bien documentés sont difficiles à trouver. C’est peut-être une attitude, on ne souhaite pas forcément partager, pas forcément collaborer. Mais, surtout, on refuse de donner à son travail une histoire et un avenir.

Ce qui est particulièrement intéressant, c’est que ces fichiers, ces listes, ne sont pas des annexes, mais font partie intégrante du projet. On attend encore un livre qui intégrerait un vrai changelog pour sa seconde édition.

Vous aurez remarqué, si vous avez suivi les liens ci-dessus, que des systèmes complets (et parfois complexes) existent pour suivre la vie d’un projet. Ce sera le cas d’un prochain billet…

Au milieu des années 80 est né le logiciel libre, puis la licence GPL et ses 4 principes: utiliser, étudier, redistribuer, modifier. En résumé, des programmeurs ont décidé de fixer des droits et des devoirs a priori sur leurs logiciels. En découvrant leur production, vous savez ce qu’ils vous permettent d’en faire, ce que cela implique pour vous, ce qui est interdit, etc.

Dans un cadre plus général, l’initiative Creative Commons a été lancée. Elle rend possible le choix de plusieurs licences, en fonction de briques que l’on assemble:

• l’auteur est toujours cité (by)
• l’œuvre peut être modifiable ou non (nc = pas d’utilisation commerciale)
• il est permis ou non de faire une utilisation commerciale de l’œuvre (nd = pas d’œuvres modifiées)
• quelle licence doit être appliquée aux produits dérivés (sa = conditions identiques)

En associant ces différents éléments, on peut donc obtenir 6 licences.

Et alors, quels sont les avantages de ce procédé, me demanderez-vous? Et pourquoi l’adopter dans un cadre plus large que les logiciels? J’y vois quelques raisons:

1. Le cadre juridique de réalisation est fixé a priori. Ce qui signifie que, dès que l’on découvre l’œuvre, on sait ce que l’on peut en faire (ou pas faire).
2. En conséquence, je n’ai pas à demander quoi que ce soit à son auteur, que je n’ai même pas à connaître, tant que je reste dans les règles fixées.
3. Mieux, cette licence m’incite à réutiliser, modifier (si permis), commercialiser (si permis), etc. un produit qui resterait peut-être méconnu. À l’adapter à mon contexte, à l’améliorer, à le compléter, à le tenir à jour, etc.
4. Cette licence permet de me protéger: en fixant un cadre clairement défini, et de mieux en mieux reconnu, j’informe précisément l’utilisateur de ses droits. Il n’est pas possible de feindre l’ignorance avec un énoncé si clair.

Dans les milieux ecclésiaux et para-ecclésiaux que je fréquente régulièrement, je constate que personne ou presque n’utilise ce genre de licence. Personne n’incite ses collègues à réutiliser ce qu’il a fait, à le modifier, à le retravailler. Pourtant, c’est bien ainsi que s’est construite la théologie, depuis la nuit des temps…

Au lieu de crier au plagiat et au pillage, on ferait mieux de fixer des règles, permissives mais claires! Notez que ce blog est sous licence CC by-sa depuis bien longtemps

Je vais toutefois essayer de trouver assez de temps pour rédiger une série de petits papiers sur une thématique qui m’intéresse particulièrement: des principes informatique qui s’appliquent dans d’autres domaines. J’avais esquissé quelques pistes dans un vieil article consacré à un colloque lausannois.

L’intervention de Xavier Contesse aux Assises du web protestant 2011 (#AWP11) a relancé cette idée. Je ne résumerai pas son propos aujourd’hui car une vidéo sera publiée sur www.webprotestant.ch. J’en reparlerai en temps voulu.

La vidéo est désormais disponible: Calvin aurait adoré Internet.

On causera donc de quelques idées qu’il vaut la peine de transposer:

• utiliser une licence pour son travail
• proposer un changelog
• DRY
• KISS
• documenter ce que l’on fait
• et d’autres idées qui surgiront ça et là.

Et on en profitera peut-être pour faire un petit point théologique de fin d’année…

En gros, on nous a balancé la rhétorique officielle: C’est bien parce que ça plaît aux Américains. Pourquoi pas, mais il faudrait parfois réfléchir à ce que l’on fait. Et, quand on est journaliste, à ce que l’on relaie… Quelques éléments:

• Selon toute logique, lorsque l’on s’adresse à des Américains, on choisit comme nom de domaine www.religionslandschaft.ch. C’est particulièrement limpide aux oreilles du surfeur californien comme à celles du mormon de l’Utah.
• Comme on est cohérent, on choisit par défaut la version en allemand.
• Bien entendu, on communique sur le sujet avant d’avoir réalisé une version francophone. Au lieu d’attendre deux mois et un site complet.
• Comme on est très informé, on lit la page relative aux langues par nombre de Wikipédia et on fait passer l’allemand avant le français. C’est logique, il y a 2 fois moins de germanophones dans le monde.
• Pour plaire à nos amis américains, on choisit un code typographique très suisse. J’aime beaucoup Frutiger ou l’Helvetica, mais ça n’a rien à voir avec ce à quoi les internautes américains sont habitués!
• Comme si cela ne suffisait pas, on choisit des images franchement pourries, en noir/blanc de mauvaise qualité. Visiblement, le n/b n’est pas un choix esthétique, mais une numérisation de vieilles plaquettes paroissiales… Si Ansel Adams a visité les parcs nationaux US, il n’a malheureusement pas sillonné le patrimoine religieux de Suisse.

En bref, on annonce avec une belle campagne de presse un site web lamentable. J’aimerais bien savoir comment on peut valider un tel brouillon du côté de Suisse Tourisme, le FEPS, la CES, etc. Pardon, on s’adresse aux Américains, on ne parle pas de brouillon, on les attire avec un work in progress…

Le matin, c’est Xavier Contesse, président du think tank Avenir Suisse, qui brossera une fresque large sur les enjeux du web. Il y parlera notamment des mutations pour les institutions traditionnelles. C’est ouvert à tous (sur inscription). Je ne veux pousser la main à personne, mais si j’avais une responsabilité politique ou communicationnelle dans une institution, ecclésiale ou non, j’y foncerais.

L’après-midi, il y aura trois ateliers:

• un sur les blogs avec Blaise Menu et Armin Kressmann
• un sur les applications smartphone avec M. Communication de l’EERV, Paolo Mariani
• un troisième, assez technique, avec votre serviteur.

Encore une fois, on ne pousse personne, mais vous risquez de regretter d’avoir raté cela!

Ce truc à l’air diabolique, tant en efficacité que par la crainte qu’il peut susciter. L’open graph dans toute sa splendeur