From a07a709b6cd1d852051f0836a86deaa94751ba36 Mon Sep 17 00:00:00 2001 From: Yannis Mesbah Date: Wed, 15 Oct 2025 11:39:02 +0200 Subject: [PATCH 1/3] docs: ajout du guide de bonnes pratiques de contribution open source Signed-off-by: Yannis Mesbah --- attic/guide-contribution-open-source.md | 236 ++++++++++++++++++++++++ 1 file changed, 236 insertions(+) create mode 100644 attic/guide-contribution-open-source.md 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. From d981abe03c45a5452dc32add54a58eac00683db4 Mon Sep 17 00:00:00 2001 From: Yannis Mesbah Date: Thu, 27 Nov 2025 17:20:40 +0100 Subject: [PATCH 2/3] docs: correction du guide de contribution open source suite aux retours Signed-off-by: Yannis Mesbah --- attic/guide-contribution-open-source.md | 190 ++++++++---------------- 1 file changed, 64 insertions(+), 126 deletions(-) diff --git a/attic/guide-contribution-open-source.md b/attic/guide-contribution-open-source.md index dcf5c66..4c72236 100644 --- a/attic/guide-contribution-open-source.md +++ b/attic/guide-contribution-open-source.md @@ -1,76 +1,66 @@ +# Guide de contribution OpenSource + # 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. +Ce guide a pour objectif d'expliciter et de détailler les bonnes pratiques pour la contribution en Open Source. Celle-ci peut être de différentes natures : -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 !** +- **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… ---- +Vous souhaitez faire valider votre demande de contribution en Open Source à titre professionnel ? -## Pour contribuer à titre professionnel, veuillez respecter les directives suivantes: +Vous faites face à de nouvelles clauses (DCO, CLA...) encadrant la contribution à un projet ? -- 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. +Vous vous demandez quelles sont les directives encadrant la contribution ? ---- +Vous souhaitez améliorer ou valoriser vos contributions ? -# I - Cadrer sa contribution +Ou tout simplement, vous souhaitez en apprendre plus sur le cadre de la contribution à des projets Open Source ? + +**Vous êtes au bon endroit !** -### 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. +## Pour contribuer à titre professionnel, nous vous recommandons les bonnes pratiques suivantes: -Une fois ces 4 étapes passées, il sera temps de préparer votre contribution. +- Ne pas utiliser d'adresses mails électroniques génériques ou anonymes. +- Si vous contribuez dans le cadre de votre activité professionnelle, nous recommandons que les commits ne soient pas fais depuis votre compte personnel. Dans ce cas votre contribution devra être alignée avec les valeurs de votre administration. +- Vérifiez la pertinence du projet auquel vous souhaitez contribuer --- -### Critères de validation - -Les critères à prendre en compte par le responsable de l'équipe produit (ou Tech Lead ou PM) sont : +# I - Cadrer sa contribution -- 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. +### Validation interne du choix de contribuer ---- +Nous vous recommandons d'établir un processus de validation interne pour la contribution. Celui-ci peut inclure l'évaluation de critères tels que : -### Quelles sont les caractéristiques principales à présenter ? +- La pull request alimente une fonctionnalité assez importante ou répond à un besoin utilisateur, permettant de justifier du temps investi lors des heures de travail. +- La pull request fait rayonner votre entreprise ou a minima avoir un impact positif sur celle-ci. +- Elle permet d'éviter une dette technique trop importante entre le projet principal et le fork réalisé. -- 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)) +À noter que chaque pull request ne doit solutionner qu'un problème à la fois (1 pull request = 1 problème). --- -### Vérifiez l'opportunité +### Vérification de la pertinence du projet -- 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 ! +Nous vous recommandons de vérifier les points suivants : ---- +- Le projet représente une plus-value pour votre activité (gain de temps, besoin usagers, rayonnement, diminution de la dette technique…). +- Le coût estimé de la contribution est limité, ou a minima en accord avec le gain estimé. +- La contribution est faite à un projet qui a une équipe active / une bonne réactivité. -### Vérifiez la pertinence du projet auquel vous souhaitez contribuer +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 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. +- L'issue identifiée n'a pas déjà été discutée (vérifier les forums, l'espace issue de GitHub) +- Le projet a été comparé à d'autres projets Open Source et représente une meilleure option à laquelle contribuer. --- @@ -82,45 +72,43 @@ Les critères à prendre en compte par le responsable de l'équipe produit (ou T - 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 sécurité de votre produit (avec une attention particulière aux points détaillés dans la partie « III- Sécuriser sa contribution » 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 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 du projet et suivez la procédure de contribution communiquée par l'équipe projet (`README.md` et `CONTRIBUTING.md`). +- Assurez-vous que votre contribution passe tous les tests demandés par le mainteneur. --- ### 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. +- 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. -### Processus de signature d'un CLA +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. -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 :** +**Si nécessaire, 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. +Ce n'est qu'une fois l'ensemble de ces validations obtenues que vous pouvez signer le CLA. + +Pour plus de détails, veuillez consulter : [https://code.gouv.fr/documentation/#contribuer-a-un-logiciel-libre](https://code.gouv.fr/documentation/#contribuer-a-un-logiciel-libre) --- @@ -132,28 +120,33 @@ Ce n’est qu’une fois l’ensemble de ces validations obtenues que vous pouve --- -# Sécuriser sa contribution +# III - Sécuriser sa contribution + +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 une 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é. ### 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. +- É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. +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. +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 +# IV - 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. @@ -179,58 +172,3 @@ Le dépôt de votre PR peut prendre plus de temps que prévu : - 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. From 281b36a373aac6785321e6680b2a8b912031b979 Mon Sep 17 00:00:00 2001 From: Yannis Mesbah Date: Thu, 27 Nov 2025 21:27:37 +0100 Subject: [PATCH 3/3] =?UTF-8?q?docs:=20am=C3=A9liorer=20les=20recommandati?= =?UTF-8?q?ons=20sur=20l'identification=20des=20contributeurs=20profession?= =?UTF-8?q?nels?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- attic/guide-contribution-open-source.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/attic/guide-contribution-open-source.md b/attic/guide-contribution-open-source.md index 4c72236..95dce41 100644 --- a/attic/guide-contribution-open-source.md +++ b/attic/guide-contribution-open-source.md @@ -29,9 +29,14 @@ Ou tout simplement, vous souhaitez en apprendre plus sur le cadre de la contribu ## Pour contribuer à titre professionnel, nous vous recommandons les bonnes pratiques suivantes: -- Ne pas utiliser d'adresses mails électroniques génériques ou anonymes. -- Si vous contribuez dans le cadre de votre activité professionnelle, nous recommandons que les commits ne soient pas fais depuis votre compte personnel. Dans ce cas votre contribution devra être alignée avec les valeurs de votre administration. -- Vérifiez la pertinence du projet auquel vous souhaitez contribuer +- **Ne pas utiliser d'adresses mails électroniques génériques ou anonymes.** + L'utilisation d'une adresse professionnelle nominative permet d'assurer la traçabilité des contributions, de faciliter les échanges avec les mainteneurs du projet, et de valoriser l'engagement de votre organisation. Les adresses génériques (ex: `noreply@`, `admin@`, `contact@`) ou anonymes nuisent à la transparence et peuvent poser des problèmes juridiques en cas de litige sur les droits d'auteur ou les licences. + +- **Si vous contribuez dans le cadre de votre activité professionnelle, nous recommandons que les commits ne soient pas faits depuis votre compte personnel.** + Dans ce cas, votre contribution devra être alignée avec les valeurs de votre administration. Utiliser un compte et une adresse email professionnels permet de clarifier que la contribution est effectuée au nom de l'organisation, ce qui sécurise les aspects juridiques (droits d'auteur, propriété intellectuelle) et renforce la légitimité institutionnelle de la démarche. + +- **Vérifiez la pertinence du projet auquel vous souhaitez contribuer.** + Assurez-vous que le projet correspond aux besoins métiers, aux valeurs et à la stratégie open source de votre organisation. Une contribution pertinente maximise l'impact de votre investissement en temps et renforce la crédibilité de votre structure au sein de l'écosystème open source. ---