Documentation

• Un fichier README est le strict minimum
• La documentation supplémentaire est placée dans un répertoire docs/
• Utiliser le service fantastique Read the Docs
• Mentionner la licence et le détenteur du copyright
• Expliquer pourquoi ce projet a été créé
• Mentionner les projets liés ou concurrents
• Comment installer et démarrer ?
• Questions fréquemment posées (FAQ, gain de temps énorme)
• Lien vers la liste des contributeurs
• Détails de conception ou d'architecture
• Donner des instructions aux développeurs pour contribuer (ex. lancer les tests)
• Mentionner ce qui est attendu des contributeurs (Definition-of-Done, checklist, conventions…)

Code source

• Utiliser l'Anglais partout
• Utiliser un logiciel de gestion de version décentralisé (Git, mercurial, …)
• Tester unitairement le code. Software without tests is broken by design
• Mettre en place l'intégration continue (avec TravisCI)
• Respecter les conventions du langage de programmation (PEP8, JSLint, …)
• Respecter les conventions du framework, et lister les éventuelles entraves dans la documentation
• Être un professionnel du code, en suivant les conseils d'Uncle Bob
• Utiliser un système de traduction, comme gettext, et garder l'Anglais comme langue par défaut
• Permettre la traduction collaborative de votre application, avec Transifex
• Fournir des commandes simplifiées pour installer ou lancer les tests (dans un Makefile par exemple)
• Tester les fonctionnalités de votre application (functional tests)
• S'assurer que les tests reflètent et décrivent les spécification fonctionnelles

Releases

• Utiliser le versionnage sémantique (SemVer : main version, features change, bug fixes)
• Garder une liste détaillée des changements par version (Changelog)
• Suivez un workflow pour votre changelog (l'inclure dans la doc, mise à jour dans le commit de merge des pull-requests,
• Créer un tag pour chaque version (vX.Y.Z)
• Créer une branche pour chaque version principale (voir les recommandations de Florent pour Git)
• Publier votre package (archive de sauvegarde) sur un dépôt (PyPi, NPM)
• Automatiser votre process de release (Makefile, Zest releaser, npm)
• Release often, release early
• Communiquer sur les nouvelles versions (tweet, OpenHub, Freecode, …)

Communauté

• S'assurer que les utilisateurs peuvent interagir entre eux quelquepart (UserVoice, Google groups, …)
• Mettre en place des alertes sur Stackoverflow pour intervenir et promouvoir votre projet
• Faire de votre mieux pour identifier au moins un contributeur motivé et lui donner les permissions sur le dépôt
• Être clair sur le périmètre fonctionnel du projet
• Rejeter toute ajout de fonctionnalité qui introduit de la complexité ou qui tordent les cas d'utilisations principaux
• Chercher un successeur aussitôt que la motivation diminue

Historique

• L'historique des commits a tout autant de valeur que les commentaires dans le code
• Mentionner le numéro de ticket dans les messages de commit (e.g. Update specs (ref #123))
• Respecter le format des messages de commit de votre communauté (ex. préfixes Drupal CHG, DOC…)

Github

• Utiliser Github
• Utiliser les tickets (issues) Github (pour absolument tout, autant que possible)
• Même seul, utiliser les issues Github comme un pense-bête, une TODO list
• Créer des labels standards (help-needed, easypick, docs, duplicate …)
• Utiliser le fonctionnalité fantastique checklists dans les descriptions des issues et des pull-requests 
• Utiliser les milestones, pour les versions suivantes, pour avoir une feuille de route (ex. Soon, Later, Final 1.0, …)
• Catégoriser les labels, en les renommant suivant une convention (ex. priority: low, priority: high, …)
• Copier les parties du changelog dans la page des releases du projet
• Utiliser la fonctionnalité contributing
• Utiliser les Github pages (gh-pages), pour présenter une démo du projet
• Configurer la branche principale dans les paramètres du projet

À vous !

Vous êtes désormais capables de juger de la qualité d'un projet Open Source. Vous pourrez constater, par exemple, que la plupart des points mentionnés ont été respectés pour le projet Geotrek. 

Pour conclure, il apparaît comme évident qu'il ne suffit pas de mettre une copie du code sur une forge en ligne pour qu'un projet Libre soit pérenne. Et ce n'est pas non plus parce qu'un projet respecte tous ces points qu'une communauté va naître et exister autour du projet… Un projet Libre demande beaucoup d'énergie!