- Contribuer au projet
En participant, vous devez respecter le code de conduite du projet.
Beaucoup de choses, l’écriture de code n’étant pas l’unique manière de contribuer au projet !
Il parait que chaque bug relevé sauve un chaton. En tout cas, la technique du ZBSD (Zero-Bug Software Development) semble porter ses fruits, comme le rapporte Andrew Fulton. Donc, si à chaque bug rencontré quelqu’un ouvre une issue avec le label Bug 🐛, ce seront des familles entières de chats qui seront sauvées.
Dans ce cas, ouvrez une nouvelle issue de type Amélioration ❤️ en décrivant bien votre idée.
Si pendant votre participation au projet (que ce soit en l'utilisant ou en participant au code) vous n'avez pas réussit à faire quelque chose par manque de solution, signalez le en ouvrant une issue de type Documentation 📘 .
Et d'ailleurs n'hésitez pas à traiter cette issue en proposant un PR améliorant la documentation si vous avez trouvez une solution !
Quelle que soit votre type d’implication, ce peut-être une bonne chose que d’installer le projet sur votre machine pour pouvoir visualiser votre contribution avant de la proposer sur Github.
Ce n'est pas toujours ce qu'il y a de plus facile à faire sur un projet : écrire une documentation permettant d'utiliser le produit, mais aussi permettant de participer à son élaboration. Et tout aussi difficile, maintenir cette documentation à jours.
Pourtant, et ceci d'expérience, ce sont le plus souvent les projets les mieux documentés qui gagnent l'adhésion de la communauté ! Voici donc les quelques méthodes et règle qui nous avons mis en place aux Coding Caen.Camp.s
Nous utilisons les ADR.s (Architectural Decision Records) pour documenter les prises de décisions liées à l'architecture du projet.
Il existe par exemple un ADR sur la mise en place des ADR.s :)
Vous trouverez plus d'information sur les ADR sur le dépôt coding-caen-camp.
Github fourni un wiki pour chaque dépôt. Autant l'utiliser !
Nous suggérons donc d'utiliser le wiki pour y noter tous les tips, guides, remarques, astuces ... liées au projet.
Afin de faciliter l’intégration (le merge) de vos PR, surtout si elles ajoutent ou modifient du code, celles-ci devront contenir les tests couvrant vos propositions.
Les tests sont lancés sur la plateforme d’intégration continue de Github via les Github actions.
La bonne pratique, c’est de faire des PR, et puis c’est tout.
Si vous n’avez encore jamais fait de Pull Request (PR), la lecture du tutorial Github Understanding the GitHub Flow est sûrement un bon point de départ.
Si vous n’aviez pas encore de compte Github, en voici une bonne introduction.
Pour le projet, nous utilisons le workflow suivant :
- Le projet principal ne possède qu’une branche
main. - Chaque participant réalise un fork du dépôt principal puis ouvre une branche depuis son fork pour chaque nouvelle feature.
- Une PR est créée depuis la branche du fork vers la branche
maindu dépôt principal.
Si vous vous sentez un peu perdu.e, la lecture de Using the Fork-and-Branch Git Workflow devrait vous rendre plus serein.ne.
Vous trouverez aussi d'autres informations sur les PR sur le dépôt coding-caen-camp.
Mais voici quelques conseils qui peuvent les rendre encore meilleures :
- Faites des commits courts et bien commentés.
- Faites des PR courtes, toute une tache (une issue) n’a pas forcement besoin d’être adressée dans une seule PR.
- Faites référence à l’issue que la PR adresse.
- N’hésitez pas à joindre des captures d’écran, fixes ou animées.
- Ajouter une description et une todo list en ouvrant la PR.
- N’attendez pas que la PR soit terminée pour l’ouvrir : la communauté viendra plus facilement en aide en découvrant tôt la PR.
- Utilisez les labels
WIP(Work In Progress) etRFR(Ready For Review) pour indiquer l’avancement de la PR. - dernier point : tous les textes (titre, description, commentaires, etc.) sont fait en français. En effet, même si la norme en opensource c’est l’anglais, nous avons collectivement décidé d’utiliser le français pour le projet.
Vous trouverez d'autres bonnes pratiques sur le dépôt coding-caen-camp.
Le système d’issues du Github est très bien pensé et permet de facilement réagir, commenter, noter... Donc si une issue vous intéresse mais qu’elle ne vous semble pas claire, c’est directement dans l’issue que vous pouvez poser des questions.
Si vous avez commencé une PR, mais que vous êtes bloqué, vous pouvez écrire un commentaire dessus décrivant votre problème et ajouter le label Demande d'aide ❓.
Il existe un channel coding-caen-camps sur le slack Web@Caen. N’hésitez pas à demander une invitation puis à y poser vos questions.
Le wiki d’un projet est souvent difficile à maintenir. C’est portant une manière simple et efficace de noter des « astuces » et autres commentaires documentant la vie du projet. Vous pouvez aller y jeter un coup d’œil, quelquefois qu’une bonne âme se serait donné la peine d’y noter quelque chose.
Nous nous réunissons si possible une fois par mois pour passer quelques heures ensemble. Pour être tenu au courant des prochaines sessions, le plus simple est de s’inscrire sur la newsletter des CaenCamp et/ou de nous suivre sur Tweeter