Présentation

Il existe divers conseils pour apprendre à faire évoluer son projet informatique. L’un des éléments les plus connus est Open Advice , un recueil d’expérience de 42 contributeurs du Libre au travers de 42 articles.

À l’occasion de la traduction de ce livre par Framabook , je me suis permis d’en faire une synthèse personnelle : un article, une phrase de synthèse.

Articles de Framasoft

Voici la liste des articles que j’ai synthétisés :

Synthèse

Et voilà leur synthèse :

1. « Libres conseils », une, première ! : 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é.
1. Du code avant toute chose : Une idée c’est bien. Avoir du code pour appuyer son idée, c’est mieux !
1. 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.
1. 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.
1. 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.
1. 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.
1. 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.
1. 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.
1. Ê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.
1. 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.
1. Comment s’attaquer aux problèmes : Pour résoudre un problème il faut :
2. formuler la bonne question pour poser le problème en bonne et due forme,
3. décomposer le problème afin de localiser les lieux où survient le problème,
4. vérifier que les conditions préalables à l’arrivée d’un cas précis soient réunies,
5. utiliser les bons outils pour les bons usages
1. 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 !
1. 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
1. 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.
1. 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.
1. 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 :
2. É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 ;
3. Bidouillez le code ;
4. Exécutez le test. S’il marche, passez au point 4, sinon retournez au point 2 ;
5. C’est fini ! Dansez le sirtaki.
1. 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 !
1. Restons courtois ! : Ne considérez pas les questions posées comme des questions idiotes. Soyez moins arrogant, soyez polis avec vos utilisateurs/contributeurs/interlocuteurs !
1. 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.
1. Apprendre à déléguer : Le sentiment de faire partie intégrante d’un projet est une source puissante de motivation. Voilà pourquoi déléguer de petites tâches à des débutants pour qu’ils puissent se faire la main est une riche idée. Soyez disponibles ensuite pour répondre à leur question. Puis revoyez leur travail avec eux en les corrigeant et en en discutant avec eux.
1. Grandir avec son projet : Élaborer un modèle de travail personnel est essentiel car cela permet de se construire un environnement où il est agréable de travailler. Cependant, avoir conscience de la structure qui est affectée par le travail inculque la discipline nécessaire pour pouvoir tenir bon face aux caprices.
1. Apprenez de vos utilisateurs : Observer les utilisateurs de l’application, de manière silencieuse d’abord, puis en posant quelques questions, permet d’améliorer grandement la qualité du modèle utilisateur de l’application et d’augmenter l’expérience utilisateur faite par l’utilisation de votre application. Tentez également de rencontrer un maximum d’utilisateurs différents pour comprendre les différents modes d’utilisation de votre application. Ainsi :
2. Vous serez tenté de modeler l’apparence et le comportement de votre interface sur la façon dont le logiciel fonctionne en coulisses. Vos utilisateurs peuvent vous aider à éviter ce piège.
3. Les utilisateurs sont des oiseaux capricieux. Ils vont casser, maltraiter et optimiser votre application à un point que vous ne pouvez même pas imaginer.
4. Apprenez de vos utilisateurs. Améliorez votre application en fonction de ce que vous avez appris. Vous avez tout à y gagner.
1. La quête du logiciel de qualité :
2. Design Patterns dresse une liste de problèmes fréquents et propose de bonnes solutions qui n’imposent pas de contraintes inutiles dans notre implémentation
3. Il faut parvenir à la Qualité Sans Nom, c’est à dire ce point où l’application est conviviale, a évolué dans le temps selon sa logique propre, ne recèle pas de contradiction interne, n’essaie pas d’attirer l’attention et réunit toutes les qualités archétypales – comme s’il avait suivi tout naturellement la voie optimale pour aboutir à sa conception.