diff --git a/attic/guide-contribution-open-source.md b/attic/guide-contribution-open-source.md new file mode 100644 index 0000000..dcf5c66 --- /dev/null +++ b/attic/guide-contribution-open-source.md @@ -0,0 +1,236 @@ +# Introduction + +Ce guide a pour objectif d’expliciter et de détailler les bonnes pratiques de contribution en Open Source. +Celles-ci sont à destination de tout collaborateur voulant contribuer à des projets externes reversés en Open Source. + +Vous souhaitez faire valider votre demande de contribution en Open Source à titre professionnel ? +Vous faites face à de nouvelles clauses (DCO, CLA...) encadrant la contribution à un projet ? +Vous vous demandez quelles sont les directives encadrant la contribution ? +Vous souhaitez améliorer ou valoriser vos contributions ? +Ou tout simplement, vous souhaitez en apprendre plus sur le cadre de la contribution à des projets Open Source ? +**Vous êtes au bon endroit !** + +--- + +## Pour contribuer à titre professionnel, veuillez respecter les directives suivantes: + +- Ne pas utiliser d’adresses électroniques génériques ou anonymes. + L'utilisation de votre adresse mail professionnelle est possible tout comme de votre adresse mail personnelle tant que votre adresse mail primaire est sécurisée. +- Votre contribution doit être alignée avec les valeurs de votre entreprise. +- Les commit ne doivent pas être faits depuis votre compte personnel. + +--- + +# I - Cadrer sa contribution + +### PRÉREQUIS : validation interne du choix de contribuer + +1. Présentez à votre responsable produit (ou Tech Lead ou PM) les caractéristiques de votre contribution. +2. Validation/invalidation par le responsable de la contribution ainsi que de son périmètre. + +Une fois ces 4 étapes passées, il sera temps de préparer votre contribution. + +--- + +### Critères de validation + +Les critères à prendre en compte par le responsable de l'équipe produit (ou Tech Lead ou PM) sont : + +- La pull request doit alimenter une fonctionnalité assez importante ou répondre à un besoin utilisateur pour justifier d’investir du temps dessus lors des heures de travail. +- La pull request doit faire rayonner votre entreprise ou a minima avoir un impact positif sur celle-ci. +- Éviter une dette technique trop importante entre le projet principal et le fork réalisé. +- Chaque pull request ne doit solutionner qu'un problème à la fois (1 pull request = 1 problème). +- Vérifier que le besoin n'a pas déjà été répondu dans la section Issues. + +--- + +### Quelles sont les caractéristiques principales à présenter ? + +- Type de contribution +- Intérêt potentiel pour l'entreprise +- Problématique à résoudre +- Niveau d’exigence et temps demandé +- Risques liés (mainteneur non-réactif, charge, sécurité…) +- Licence (la licence doit bien être Open Source — vous pouvez vérifier ses caractéristiques dans la liste officielle SPDX[](https://spdx.org/licenses)) + +--- + +### Vérifiez l'opportunité + +- Ouvrez une issue pour discuter avec la communauté et orienter la contribution (code, bug bounty, amélioration de fonctionnalités…). +- Vérifiez si le besoin a déjà été exprimé dans la section Issues de la communauté. +- Évaluez la plus-value pour votre entreprise (gain de temps, besoin usagers, rayonnement, diminution de la dette technique…). +- Ne prévoyez pas plusieurs modifications au sein d'une même contribution. 1 problème = 1 Pull Request ! + +--- + +### Vérifiez la pertinence du projet auquel vous souhaitez contribuer + +- Le projet doit représenter une plus-value pour votre activité (gain de temps, besoin usagers, rayonnement, diminution de la dette technique…). +- Le coût estimé de la contribution doit être limité, ou a minima en accord avec le gain estimé. +- La contribution doit être faite à un projet qui a une équipe active / une bonne réactivité. + Pour cela, testez l'activité du projet en envoyant un message à l'équipe projet ou en vérifiant si le projet a des commits récents ! +- Le projet doit avoir été comparé à d’autres projets Open Source et représenter une meilleure option à laquelle contribuer. + +--- + +# II - Préparer sa contribution + +- Vérifiez le `CONTRIBUTING.md` +- Dupliquez le projet : créez un fork du projet sur votre compte et clonez ce fork sur votre machine locale. +- Selon le `CONTRIBUTING.md` ou les pratiques existantes : + - Créez une nouvelle branche pour votre contribution (ex: `feature/nouvelle-fonctionnalité`). + - Ou forkez le projet. +- Faites les modifications nécessaires et testez-les localement. +- Vérifiez la sécurité de votre produit (avec une attention particulière aux points détaillés dans la partie « Sécurité et traçabilité » de ce guide). + +--- + +### Vérifiez la conformité + +- Vérifiez la licence du produit auquel vous voulez contribuer. + Votre contribution doit être faite sous la même licence ou une licence compatible a minima. +- Lisez la documentation projet et suivez la procédure de contribution communiquée par l’équipe projet. +- Assurez-vous que votre contribution passe tous les tests demandés par le mainteneur et indiqués dans le fichier `Contrib.MD`. + +--- + +### Vérifiez la qualité + +- Faites plusieurs audits de code par vos pairs pour s’assurer que le code est conforme aux standards de qualité établis, qu’il ne contient rien d’inapproprié ou de sensible. +- Optionnel : s'il vous est demandé de signer un CLA (Contributor Licence Agreement) suivez les indications ci-dessous. + +--- + +Il est rappelé que la contribution en Open Source expose à un niveau de sécurité. +Dans ce cadre, il est impératif de relire vos lignes de code avant de faire un pull request. +Si la criticité du projet le suggère, il vous est demandé de compléter cette étape par des vérifications plus approfondies ; ceci afin de garantir une absence de faille de sécurité. + +--- + +### Processus de signature d'un CLA + +Un CLA est un accord légal entre un contributeur et un projet Open Source qui définit les conditions de contribution au projet. +En signant un CLA, le développeur transfère au projet des droits qui vont au-delà du cadre prévu par la licence Open Source du projet. +Cette démarche nécessite donc une procédure d'approbation particulière. + +**Processus de signature d'un CLA — À signer une fois par projet et par contributeur :** + +1. Information à transmettre à l'OSPO +2. Avis des équipes juridiques (pour lever les risques liés au CLA) +3. Accord du responsable opérationnel + +Ce n’est qu’une fois l’ensemble de ces validations obtenues que vous pouvez signer le CLA. + +--- + +### Compatibilité des licences + +- De préférence, la licence de votre contribution doit être la même que celle du projet. +- Si ce n'est pas possible, les licences permissives sont généralement faciles à intégrer. +- À noter que le projet peut avoir des directives spécifiques sur la licence à utiliser dans votre contribution. + +--- + +# Sécuriser sa contribution + +### Bonnes pratiques de développement + +- Éliminer tous les messages de debug et toute information inutile pour le projet dans les messages d’erreur lors du pull request. +- Éliminer tout le code mort car il pourrait prêter à confusion et/ou laisser penser qu’il est toujours fonctionnel et testé ; ce code, non maintenu, pourrait être réintégré à tort par un développeur. +- Aucun élément sensible (tel qu’un mot de passe ou une clé cryptographique) ne doit être stocké dans le code ou dans les commentaires ; avoir recours à des fichiers de configuration qui ne sont pas versionnés. + +--- + +### Sécurisation des métadonnées lors d'un commit + +Lors d’un commit, il est important de spécifier clairement votre `user.name` et `user.email` dans votre git config globale. + +Si vous ne respectez pas cette étape, les informations du poste par défaut seront mises automatiquement dans les métadonnées du commit ; +et cela même si vous renseignez votre username et token d’authentification lié à votre projet lors du commit. Cela constitue un risque de sécurité important. + +Toute métadonnée d'un commit est difficilement modifiable dans l'historique par la suite, une fois poussée sur GitHub, et impossible à modifier pour des PRs qui sont fermées. + +--- + +# III - Soumettre la contribution + +1. Faites un commit avec un message clair et concis expliquant les changements apportés ainsi que le point de blocage auxquels ceux-ci répondent. +2. Poussez votre branche modifiée vers votre fork. +3. Créez une Pull Request (PR) vers le dépôt d'origine. +4. Suivez l'état de votre PR. Soyez prêts à recevoir des commentaires et à apporter des modifications si nécessaire. + +--- + +### Anticipez la charge + +Le dépôt de votre PR peut prendre plus de temps que prévu : + +- Potentiel besoin de tester sur un worker GitHub (hors environnement habituel de tests) +- Potentiels aller-retours avec la communauté pour peaufiner la PR + +--- + +### Et si ma contribution n'est pas acceptée ? + +- Vérifiez les commentaires : consultez les retours que vous avez reçus sur votre PR. +- Apportez des modifications si nécessaire. +- Demandez des clarifications si les commentaires ne sont pas clairs. +- Recherchez des projets similaires : si votre contribution n'est pas acceptée et que vous ne parvenez pas à obtenir de retour, envisagez de soumettre votre travail à un autre projet open source. + +--- + +# Annexe : les différents types de contribution + +### Échéance + +Bien que la plupart des contributions se fassent en une fois, de nombreux projets cherchent des partenaires à moyen terme capables de dédier un ETP au projet et de participer à la gouvernance et la roadmap. +Bien que ce type de contribution soit chronophage, il peut être intéressant à envisager pour avoir plus de marge de manœuvre sur un projet. + +--- + +### Types de contribution + +- **Documentation projet** : ajouter de la documentation au projet en lui-même +- **Tests sans code** : tester le logiciel, signaler des bugs, fournir des retours d'expérience sur l'utilisation du produit +- **Contribution au design** : création d’interfaces utilisateur attrayantes et intuitives, création de logos et visuels +- **Traduction** : de la documentation ou de l'interface utilisateur pour élargir l'audience du projet +- **Marketing et promotion** : écriture d’articles de blog, réseaux sociaux… +- **Partage de bonnes pratiques** : valoriser les compétences de l'organisation, potentiellement à l'international +- **Gestion de la communauté** : modération de forums, organisation de discussions ou réponse aux questions utilisateurs +- **Financement** : financement participatif, recherche de sponsors… + +--- + +# Focus sur les mécanismes de financement + +**Qui achète ?** + +- Un ministère +- Un opérateur +- Une collectivité + +**Quoi ?** + +- Des services (support, formation, adaptation) +- Des corrections de bug +- Des développements de fonctionnalités + +**À qui ?** + +- À un éditeur open source +- À un intégrateur qui reverse ou non +- À un fournisseur de services cloud qui reverse ou non +- À la DINUM + +**Comment ?** + +- Via un don (GitHub Sponsor, Open Collective, don direct, etc.) +- Via un décret de transfert (d'un ministère à la DINUM) +- Via le marché beta.gouv.fr (pour le business development et le financement de développeurs travaillant sur un projet) +- Via les marchés de support interministériels +- Via un marché innovant +- Via un marché dédié +- Via une commande hors marché avec ou sans mise en concurrence +- Via un _fiscal sponsor_ (parrain fiscal) : une organisation à but non lucratif qui accepte de soutenir financièrement un projet Open Source en lui fournissant un statut fiscal. Cela permet au projet de recevoir des dons déductibles d'impôt. +- Via une association de loi 1901 qui permet de rentrer les contributions financières dans la comptabilité d'un établissement public. À noter que, de par les démarches administratives, une telle association prendrait surtout sens pour un regroupement de projets Open Source et non un projet unique.