Ajout du guide de bonnes pratiques de contribution open source #6

YanMesb · 2025-10-15T10:03:36Z

Ajout d’un nouveau guide de bonnes pratiques de contribution Open Source.
Contient les sections :

Cadrer sa contribution
Préparer sa contribution
Sécuriser sa contribution
Soumettre sa contribution
Annexes et mécanismes de financement

Ce document vise à aider les contributeurs à suivre les bonnes pratiques avant une PR.

Signed-off-by: Yannis Mesbah <[email protected]>

lgrd · 2025-10-15T11:51:31Z

Merci ! Je regarde ça au plus vite ! :D

lgrd

J'ai fait quelques commentaires. Je vous laisse me faire un retour et n'hésitez pas à modifier directement la PR. :)

En tout cas, bravo pour ce travail et encore merci !

lgrd · 2025-10-23T09:23:04Z

attic/guide-contribution-open-source.md

+
+---
+
+# Focus sur les mécanismes de financement


Je vous propose que l'on mette cette partie dans un autre document. Qu'en pensez-vous ?

Hum oui. Je mettrais même la partie juste avant dans un autre document. Dans la doc principale à vrai dire. J’ai lu le document jusqu’à présent comme un guide de contribution au code (trad et doc comprises)

Vous nous conseillez de le mettre dans quel document ?

attic/guide-contribution-open-source.md

lgrd · 2025-10-23T09:27:00Z

attic/guide-contribution-open-source.md

+
+---
+
+## Pour contribuer à titre professionnel, veuillez respecter les directives suivantes:


Vu que nous parlons de bonnes pratiques, je pense qu'il serait intéressant que l'on modifie légèrement la formulation de ce titre. Qu'en pensez-vous ? :)

Bien vu effectivement, nous avons changé la tournure des phrases qui étaient un peu trop directives, que ça soit dans ce titre ou dans la suite du document

lgrd · 2025-10-23T09:27:58Z

attic/guide-contribution-open-source.md

+
+- 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.


Pourquoi ne pas parler d'administration ? :)

+1. Aussi, je serais tenté de justifier pourquoi ne pas utiliser d’adresse générique (pour la clarté), et de justifier ou de simplement supprimer la ligne 19. C’est étrange comme « directive ». Soit la personne ne souhaite pas contribuer dans le cadre de son travail et rien ne l’y oblige, dans ce cas tout va bien, soit la personne est missionnée pour travailler sur ce produit, et la question des valeurs vient bien avant (idéalement lors de l’embauche). Je ne comprends pas pourquoi cela est une directive.

Aussi, c’est quoi une « adresse mail sécurisée » ?

On est d'accord, ça veut tout et rien dire une adresse mail sécurisé aha.

Nous l'avons enlevé.

Concernant les justifications, je vous propose ça =>

"- 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."

lgrd · 2025-10-23T09:32:03Z

attic/guide-contribution-open-source.md

+
+---
+
+### Vérifiez la pertinence du projet auquel vous souhaitez contribuer


Encore un détail, je mettrais bien cette partie avant la précédente aussi. xD

lgrd · 2025-10-23T09:33:44Z

attic/guide-contribution-open-source.md

+  - 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).


Je l'ai raté ou elle n'est plus présente ?

Je crois que je l'ai vu mais sans titre ^^ ou ce n'est pas ça... :/ cf. ligne 105

Bien vu merci, c'était bien la ligne 105 ou il manquait un titre, finalement on a fusionné cette partie (cf 105) avec la grande section Sécurité

lgrd · 2025-10-23T09:35:45Z

attic/guide-contribution-open-source.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 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`.


Il est question du contributing ou d'un autre fichier ?

lgrd · 2025-10-23T09:38:09Z

attic/guide-contribution-open-source.md

+
+**Processus de signature d'un CLA — À signer une fois par projet et par contributeur :**
+
+1. Information à transmettre à l'OSPO


On devrait peut-être préciser "si vous en avez un", non ? ^^

Aussi, peut-être référencé cette partie de la documentation qui explique plus en détail : https://code.gouv.fr/documentation/#contribuer-a-un-logiciel-libre

Précision rajouté + mention de l'url

lgrd · 2025-10-23T09:39:29Z

attic/guide-contribution-open-source.md

+
+---
+
+### Types de contribution


j'aurais bien mis cette partie au début pour donner du contexte aux contributions possibles. Un avis ?

On a integré cette section dans l'intro

louis-vgn · 2025-11-12T21:48:38Z

attic/guide-contribution-open-source.md

+
+- 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.


+1. Aussi, je serais tenté de justifier pourquoi ne pas utiliser d’adresse générique (pour la clarté), et de justifier ou de simplement supprimer la ligne 19. C’est étrange comme « directive ». Soit la personne ne souhaite pas contribuer dans le cadre de son travail et rien ne l’y oblige, dans ce cas tout va bien, soit la personne est missionnée pour travailler sur ce produit, et la question des valeurs vient bien avant (idéalement lors de l’embauche). Je ne comprends pas pourquoi cela est une directive.

louis-vgn · 2025-11-12T21:49:58Z

attic/guide-contribution-open-source.md

+
+- 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.


Aussi, c’est quoi une « adresse mail sécurisée » ?

louis-vgn · 2025-11-12T21:55:10Z

attic/guide-contribution-open-source.md

+- 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.


On parle de quelle plateforme : Github / Gitlab ? Mim-libre ? Source Hut ? Et toutes celles que j’oublie :-) Ou on parle du « compte » git ?

Je ne pense pas que l’on parle du client git en tant que tel, mais bien de GitHub/Gitlab. Du coup, il faut se créer un compte professionnel si on en n’a pas ? Sur sourcehut, les contributions se font directement via des patchs par mail. Comme plus haut, il est dit que l’on peut utiliser notre adresse mail personnelle, cette phrase me paraît être contradictoire.

louis-vgn · 2025-11-12T22:01:05Z

attic/guide-contribution-open-source.md

+
+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.


Pour moi ces critères-là sont intéressants, mais n’entre pas dans le cadre de la documentation. Ce sont des critères stratégiques que chaque organisme doit fixer soit même avec une politique de contribution aux logiciels libres amonts.

Effectivement, c'était trop orienté sur notre politique interne, nous l'avons reécris de sorte à ce que ça soit + des suggestions/recommandations de critères d'évaluations

louis-vgn · 2025-11-12T22:02:25Z

attic/guide-contribution-open-source.md

+### 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é.


cf. plus haut

cf haut dessus

louis-vgn · 2025-11-12T22:10:31Z

attic/guide-contribution-open-source.md

+---
+
+### Vérifiez l'opportunité
+


J’ajouterais une ligne : en prérequis ne pas ouvrir d’issue, vérifier que ça n’a pas déjà était discuté dans les issues, mais aussi dans les espaces de forum du projet. Une issue = un bug ou une proposition de fonctionnalité détaillée. Il vaut mieux, avant, discuté avec la communauté voir si c’est quelque chose qui est souhaitable, qui peut se faire, qui va se faire, etc. S’il n’y a pas d’espace de forum, alors voir l’espace « discussion » de GitHub qui existe parfois. En dernier recours, faire une issue. Cela évite de noyer l’issue tracker avec des demandes de supports ou de fonctionnalités qui n’ont pas été réfléchies en amont.

Ok top merci, on a fusionné finalement "Vérification de la pertinence du projet" et "Vérifiez l'opportunité" + rajouté ta suggestion, comme ceci =>

"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é.

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 !

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."

louis-vgn · 2025-11-12T22:12:59Z

attic/guide-contribution-open-source.md

+
+**Processus de signature d'un CLA — À signer une fois par projet et par contributeur :**
+
+1. Information à transmettre à l'OSPO


Aussi, peut-être référencé cette partie de la documentation qui explique plus en détail : https://code.gouv.fr/documentation/#contribuer-a-un-logiciel-libre

louis-vgn · 2025-11-12T22:17:29Z

attic/guide-contribution-open-source.md

+
+---
+
+# Focus sur les mécanismes de financement


Hum oui. Je mettrais même la partie juste avant dans un autre document. Dans la doc principale à vrai dire. J’ai lu le document jusqu’à présent comme un guide de contribution au code (trad et doc comprises)

louis-vgn

Je me suis permis quelques commentaires aussi :-) merci pour ce travail. Je suis un peu surpris peut-être parce que le sujet de la doc a complétement changé, mais pour moi il s’agit d’une documentation (accompagnée éventuellement de guides¹) avec pour audience des agents publics dans le cadre de la loi pour une république numérique de 2016 : https://code.gouv.fr/documentation/#presentation

Du coup, tout ce qui attrait aux valeurs d’un projet ou à la stratégie logiciels libres devrait être plutôt à part, dans des politiques logiciels libres dédiées à l’organisme qui s’organise comme il souhaite. En gros, tenter d’avoir un point de vue très pragmatique et objectif.

Pourquoi le mettre dans le /attic/ d’ailleurs ? C’est dommage parce que il y a plein de bon truc à prendre là-dedans, potentiellement à mettre directement dans la documentation principale. ↩

Signed-off-by: Yannis Mesbah <[email protected]>

YanMesb · 2025-11-27T18:50:57Z

Hello, merci beaucoup pour vos retours, nous avons avec Charlotte reprit chacun de vos points. N'hésitez pas à nous dire ce qu'on pourrait améliorer.

Nous avons encore deux questions en suspens, on peut soit en parler ici ou bien convenir d'un point d'échange si ça vous convient.

Ou mettre la section "Focus sur les mécanismes de financement" si ce n'est pas dans ce document ?
Ou mettre précisément ce document "Guide de contribution" si ce n'est pas dans /attic/ ?

…teurs professionnels

docs: ajout du guide de bonnes pratiques de contribution open source

a07a709

Signed-off-by: Yannis Mesbah <[email protected]>

lgrd self-requested a review October 15, 2025 11:50

lgrd self-assigned this Oct 15, 2025

lgrd removed their request for review October 15, 2025 11:50

lgrd reviewed Oct 23, 2025

View reviewed changes

lgrd assigned YanMesb Oct 23, 2025

louis-vgn reviewed Nov 12, 2025

View reviewed changes

docs: correction du guide de contribution open source suite aux retours

d981abe

Signed-off-by: Yannis Mesbah <[email protected]>

docs: améliorer les recommandations sur l'identification des contribu…

281b36a

…teurs professionnels


		---

		## Pour contribuer à titre professionnel, veuillez respecter les directives suivantes:


		---

		### Vérifiez la pertinence du projet auquel vous souhaitez contribuer


		Processus de signature d'un CLA — À signer une fois par projet et par contributeur :

		1. Information à transmettre à l'OSPO


		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.

Ajout du guide de bonnes pratiques de contribution open source #6

Are you sure you want to change the base?

Ajout du guide de bonnes pratiques de contribution open source #6

Uh oh!

Conversation

YanMesb commented Oct 15, 2025

Uh oh!

lgrd commented Oct 15, 2025

Uh oh!

lgrd left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

louis-vgn left a comment

Choose a reason for hiding this comment

Footnotes

Uh oh!

YanMesb commented Nov 27, 2025

Uh oh!