Ajout du guide de bonnes pratiques de contribution open source #6
Conversation
Signed-off-by: Yannis Mesbah <yannis.mesbah@francetravail.fr>
|
Merci ! Je regarde ça au plus vite ! :D |
lgrd
left a comment
lgrd
left a comment
There was a problem hiding this comment.
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 !
|
|
||
| --- | ||
|
|
||
| # Focus sur les mécanismes de financement |
There was a problem hiding this comment.
Je vous propose que l'on mette cette partie dans un autre document. Qu'en pensez-vous ?
There was a problem hiding this comment.
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)
|
|
||
| --- | ||
|
|
||
| # Sécuriser sa contribution |
There was a problem hiding this comment.
Est-ce que ce ne serait pas un grand III ?
|
|
||
| --- | ||
|
|
||
| # III - Soumettre la contribution |
There was a problem hiding this comment.
Est-ce que ce ne serait pas un grand IV ?
|
|
||
| --- | ||
|
|
||
| ## Pour contribuer à titre professionnel, veuillez respecter les directives suivantes: |
There was a problem hiding this comment.
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 ? :)
|
|
||
| - 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. |
There was a problem hiding this comment.
Pourquoi ne pas parler d'administration ? :)
There was a problem hiding this comment.
+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.
There was a problem hiding this comment.
Aussi, c’est quoi une « adresse mail sécurisée » ?
|
|
||
| --- | ||
|
|
||
| ### Vérifiez la pertinence du projet auquel vous souhaitez contribuer |
There was a problem hiding this comment.
Encore un détail, je mettrais bien cette partie avant la précédente aussi. xD
| - 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). |
There was a problem hiding this comment.
Je l'ai raté ou elle n'est plus présente ?
There was a problem hiding this comment.
Je crois que je l'ai vu mais sans titre ^^ ou ce n'est pas ça... :/ cf. ligne 105
| - 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`. |
There was a problem hiding this comment.
Il est question du contributing ou d'un autre fichier ?
|
|
||
| **Processus de signature d'un CLA — À signer une fois par projet et par contributeur :** | ||
|
|
||
| 1. Information à transmettre à l'OSPO |
There was a problem hiding this comment.
On devrait peut-être préciser "si vous en avez un", non ? ^^
There was a problem hiding this comment.
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
|
|
||
| --- | ||
|
|
||
| ### Types de contribution |
There was a problem hiding this comment.
j'aurais bien mis cette partie au début pour donner du contexte aux contributions possibles. Un avis ?
|
|
||
| - 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. |
There was a problem hiding this comment.
+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.
|
|
||
| - 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. |
There was a problem hiding this comment.
Aussi, c’est quoi une « adresse mail sécurisée » ?
| - 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. |
There was a problem hiding this comment.
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.
|
|
||
| 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. |
There was a problem hiding this comment.
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.
| ### 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é. |
| --- | ||
|
|
||
| ### Vérifiez l'opportunité | ||
|
|
There was a problem hiding this comment.
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.
|
|
||
| **Processus de signature d'un CLA — À signer une fois par projet et par contributeur :** | ||
|
|
||
| 1. Information à transmettre à l'OSPO |
There was a problem hiding this comment.
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
|
|
||
| --- | ||
|
|
||
| # Focus sur les mécanismes de financement |
There was a problem hiding this comment.
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
left a comment
louis-vgn
left a comment
There was a problem hiding this comment.
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 guides1) 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.
Footnotes
-
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. ↩
3 participants
Ajout d’un nouveau guide de bonnes pratiques de contribution Open Source.
Contient les sections :
Ce document vise à aider les contributeurs à suivre les bonnes pratiques avant une PR.