Février 04, 2013 - Archives
04/02/2013 08:50:57
Synthèse de Libres Conseils du Framablog
Introduction
Il y a quelques années de cela, un groupe de personnes ayant travaillé dans différentes communautés du Libre ont décidé de sortir un livre nommé Open Advices - littéralement Libres Conseils.
Ce sont des conseils de personnes avisées et expérimentées qui soulignent les éléments majeurs de la réussite d'un projet au sein d'une communauté Libre.
Libres Conseils chez Framablog
Récemment le Framablog s'est décidé à publier une version francophone du célèbre livre Open Advice. À cet effet, chaque semaine un nouvel article sort jusqu'à ce que nous arrivions à la période des RMLL qui devraient se dérouler à Bruxelles cette année.
Pour me remémmorer les conseils rapides donnés dans chaque article, j'ai fait un texte explicatif de chaque section du livre.
Synthèse des chapitres/sections
Voici donc la synthèse des articles du Famablog :
« Libres conseils », une, première ! (Introduction) : C'est un recueil de 42 auteurs qui devrait permettre à n'importe qui de mettre toutes les chances de son côté pour qu'un projet libre aboutisse vraiment, gagne en notoriété, entre dans une logique commerciale, et procure amour, gloire et beauté.
- Du code avant toute chose : Une idée c'est bien. Avoir du code pour appuyer son idée, c'est mieux !
- Tous les autres pourraient avoir tort, mais c'est peu probable : Si le logiciel n’est que pour vous-même, vous pouvez garder le code source et les infrastructures qui l’entourent comme terrain de jeu personnel. Mais si vous voulez que votre logiciel soit utilisé, qu’il compte pour les autres personnes, qu’il change (peut-être) le monde, alors vous allez devoir construire une saine et solide communauté d’utilisateurs, de contributeurs principaux, d’administrateurs et de développeurs de modules. Les utilisateurs ont besoin d’avoir l’impression de posséder le logiciel, de la même façon que vous.
- Les projets open source s'épanouissent à l'air libre : Il convient de créer une communauté autour du projet pour que celui-ci s'épanouisse. Pour cela il faut disposer d'une bonne méthode de communication (blog, journaux, etc.) et d'outils permettant l'échange comme un wiki, un bugtracker, un site web officiel, etc.
- *Prévoir l'avenir d'un projet open source * : Du fait de nombreux arrivées/départs de contributeurs dans un projet, il vaut mieux prévoir un standard de codage, des bonnes pratiques, documenter le code, développer les principales lignes directrices de son projet, vérifier le code orphelin pour qu'il ne le reste pas, laisser des astuces en tout genre et des commentaires sur ce qu'on a fait.
- Du bon usage des mentors : Avis aux nouveaux arrivants d'un projet : n'attendez pas trop longtemps avant de demander de l'aide ; si demande d'aide il y a, donnez vos réflexions et la procédure suivie ; dès qu'un problème est résolu, prenez en note et mettez à jour la documentation officielle du projet afin que les nouveaux arrivants puissent s'y retrouver.
- Pour que le Libre aille vers l'Université : Les étudiants sont des sujets vifs, curieux, plein d'énergie. Il est intéressant de créer un partenariat avec une université afin de créer un échange avec ces derniers. Ces étudiants apporteront du sang neuf dans votre communauté, des idées et un peu de temps libre dédié à votre projet. Par ailleurs le projet gagne en renommée.
- Inviter à l'audace : Invitez fréquemment l'une ou l'autre personne du projet à participer à quelque chose. Ceci de manière positive, conviviale et ouverte. Vous impliquerez davantage les personnes dans cette grande aventure qu'est un projet libre.
- Être administrateur systèmes : ne pas s'enfermer dans une spécialité ? : Multiplier ses compétences au sein d'un projet permet à celui-ci de toujours avoir une personne disponible en cas de problème, notamment en terme d'administration système. Avoir plusieurs administrateurs systèmes est plus que conseillé, même s'ils n'ont pas de compétences approfondies dans la matière. Il faut laisser chacun découvrir de nouveaux horizons.
- Sauvegardes et garde-fous : On ne le dira jamais assez : faites des sauvegardes ! Une fois validées (vérifier qu'elles fonctionnent), ne plus avoir peur de mettre à jour le système fréquemment pour pallier aux trous de sécurité. Pensez aussi à avoir des sauvegardes dans plusieurs lieux et chez plusieurs personnes.
- Comment s'attaquer aux problèmes : Pour résoudre un problème il
faut :
- formuler la bonne question pour poser le problème en bonne et due forme,
- décomposer le problème afin de localiser les lieux où survient le problème,
- vérifier que les conditions préalables à l'arrivée d'un cas précis soient réunies,
- utiliser les bons outils pour les bons usages
- D'un projet à l'autre, franchissez les frontières : Ne vous cantonez pas à votre propre projet. D'autres projets existent avec des idées différentes mais parfois avec des besoins communs aux votres ! Franchissez le pas et aller vers eux. Les échanges inter-projets sont bénéfiques !
- Cent fois sur le métier remettez vos correctifs… : Pour écrire des
correctifs :
- suivez les normes de style de codage du projet à corriger
- utilisez un outil de contrôle de version décentralisé (DVCS)
- faites des diffs unifiées
- faites de petits correctifs qui font UNE et UNE seule chose à la fois
- faites un suivi de votre correctif pour en avoir le retour, les modifications éventuelles et finalement l'impact qu'il a sur le projet
- *Tests contre Bogues : une guerre sans fin * : Fournissez à vos testeurs de quoi se mettre sous la dent ! Les tests ne se résument pas à de simples essais manuels façon maison, ce sont des choses plus complexes qui peuvent être faites de manière plus élaborées. Par exemple donner aux testeurs les endroits qui n'ont pas encore été testés, ou la liste des tests en cours, les résultats des tests précédents, etc. Plus le testeur a du retour sur ce qui a été fait, plus il mettra en œuvre ses compétences pour mettre à l'épreuve votre logiciel sur des points sensibles ou encore non-testés.
- Remue-ménage dans le triage : Un suivi régulier des tickets de bugs est un bon moyen de réduire leur nombre et de stabiliser votre projet par la même. C'est aussi un lieu atypique pour participer et diminuer considérablement la tâche des développeurs qui ont - probablement - déjà assez à faire.
- Faire un test à la fois vous met sur la bonne voie : Faites des
tests unitaires et des tests d'intégration. Pour chacun d'eux, suivez la
procédure décrite ici :
- Écrivez un test qui fait échouer votre code, mais qui, selon vous, sera passé quand la fonctionnalité sera implémentée ou que le bogue sera corrigé. Mode expert : pendant l’écriture du test, pensez à l’exécuter de temps en temps, même s’il n’est pas encore fini, et tentez de deviner le message d’erreur effectif que le test renverra. À force d’écrire des tests et de les faire tourner, cela devient plus facile ;
- Bidouillez le code ;
- Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
- C’est fini ! Dansez le sirtaki.
- RTFM ? - mais où est-il, votre manuel ? : Les débutants et futurs contributeurs ont besoin de documentation pour accéder facilement à votre projet et potentiellement y participer. Prenez soin d'eux, prenez donc soin de la documentation !
- Restons courtois ! : Ne considérez pas les questions posées comme des questions idiotes. Soyez moins arrogant, soyez polis avec vos utilisateurs/contributeurs/interlocuteurs !
- Documenter c'est s'enrichir : La documentation permet à tout à chacun de s'enrichir d'un point de vue personnel comme social ou tout simplement sur un projet. Faire de la documentation peut se faire via l'idée de sprint (de brusques dépenses d’énergie avec un public ciblé et un but précis). Il est intéressant d'avoir une liste des documentations existantes et des contributeurs (ou non) du projet pour se situer dans un projet.
Note: RTFM = Read The Fine Manual
Conclusion
S'il y a bien un conseil à donner, c'est celui de lire ce recueil et d'appliquer les avis de ces 42 auteurs !
Vous mesurerez vous-même les répercutions que cela aura eu sur votre projet, mais je suis sûr que s'aura été bénéfique pour votre projet, votre communauté et au final pour vous.
Liens
Image sous Licence Creative Commons CC-BY-NC-ND 2.0 trouvée sur une galerie photo de umop_episdn.
