Gouvernance¶
Cette page décrit comment la bibliothèque est animée : qui décide, comment une idée devient une fonctionnalité, et comment les contributions sont reprises et publiées.
Version de travail
Cette page est une proposition soumise à discussion. Les valeurs marquées (à valider) sont des suggestions, pas des engagements. Les remarques sont les bienvenues sur le Discord du Club Utilisateurs GEO ou dans une issue.
Principes¶
- Ouvert : le code est sous GPL-3.0-or-later, la documentation sous CC-BY-4.0, et chacun peut proposer des changements.
- Utile avant tout : un module doit résoudre un besoin réel et fonctionner dans un GEO réel. Une idée se juge à son usage.
- Transparent : les décisions sont écrites là où tout le monde peut les lire, avec leur raison, y compris quand la réponse est « non ».
- Simple : peu de règles, des modèles et des listes de contrôle plutôt que des procédures.
Un projet bénévole¶
Cette bibliothèque est animée bénévolement, sur le temps que chacun peut y consacrer. Ce qui est écrit sur cette page relève de l'intention, pas de l'obligation :
- les règles décrites ici sont des repères que nous nous donnons pour travailler ensemble et rester cohérents ; elles ne sont pas prescriptives, et un cas particulier peut justifier d'y déroger ;
- les délais annoncés (réponse, publication) servent à garder le projet vivant et à ne laisser aucune demande sans nouvelles. Aucun contrat ne nous oblige à les tenir : ils peuvent être dépassés, sans préavis, selon nos disponibilités ;
- il n'y a ni support, ni garantie de service, ni engagement de corriger un bogue ou de retenir une fonctionnalité. Les modules sont fournis sous licence libre, sans garantie, comme le précisent les licences GPL-3.0 et CC-BY-4.0 ;
- une demande qui reste sans réponse n'est pas un refus : un rappel poli, dans l'issue ou sur le Discord, est toujours le bienvenu.
L'esprit est celui d'un coup de main entre collègues de collectivités : chacun donne ce qu'il peut, et une contribution, même petite, vaut mieux que de bonnes intentions.
Rôles¶
| Rôle | Qui | Ce que le rôle permet |
|---|---|---|
| Mainteneur | Le service SIG et Foncier de Vienne Condrieu Agglomération | Décide de l'intégration, fusionne, publie les versions |
| Co-mainteneur | Un contributeur actif invité par les mainteneurs, pour un ou plusieurs modules (à valider) | Relit et fusionne des contributions sur ses modules |
| Contributeur | Toute personne qui signale un problème, propose une idée ou une modification | Ouvre des issues et des demandes de fusion |
| Utilisateur | Toute personne qui installe un module | Signale les problèmes, partage ses retours |
Un contributeur régulier peut être invité comme co-mainteneur ; la décision se prend entre mainteneurs, avec son accord.
De l'idée à la fonctionnalité¶
- Échanger (facultatif) : une idée peut d'abord se discuter sur le Discord pour mesurer l'intérêt.
- Proposer : ouvrir une issue sur le dépôt du module, avec le modèle « Proposer une fonctionnalité » : le besoin, l'usage concret, la version de GEO concernée. Le Discord ne remplace pas l'issue : seule l'issue garde la trace de la décision.
- Discuter : les mainteneurs et la communauté commentent. Les mainteneurs précisent si la proposition entre dans le périmètre du module.
- Décider : les mainteneurs tranchent après un délai de discussion (à valider : environ deux semaines) et l'indiquent dans l'issue par un
label :
acceptée: la fonctionnalité est retenue, avec son porteur (qui la développe) ;reportée: intéressante, mais pas maintenant ; la raison est donnée ;refusée: hors périmètre, trop coûteuse à maintenir, ou incompatible ; la raison est donnée.
- Réaliser : le porteur ouvre une demande de fusion, qui suit la liste de contrôle ci-dessous.
- Publier : la fonctionnalité sort avec la version suivante du module.
Une correction simple (faute, lien, bogue évident) n'a pas besoin d'issue préalable : une demande de fusion directe suffit.
Proposer un nouveau module¶
Les propositions de nouveaux modules sont bienvenues, et elles reçoivent toujours une réponse écrite. Le parcours est le même que pour une fonctionnalité :
- Ouvrir une issue sur geo-modules-community avec le modèle « Proposer un module » : le besoin, ce que le module fait et ne fait pas, la version de GEO visée, qui le développerait et qui l'entretiendrait ensuite.
- Discuter avec les mainteneurs et la communauté (le Discord peut servir à tâter le terrain).
- Décider : les mainteneurs répondent dans l'issue par
acceptée,reportéeourefusée, avec la raison. - Réaliser : le porteur développe le module, puis le propose pour relecture. Il est publié dans la bibliothèque dès qu'il remplit les critères ci-dessous.
Un module est bienvenu s'il :
- répond à un besoin partagé par plusieurs utilisateurs de GEO, pas seulement à un cas local ;
- a un périmètre clair : il fait une chose, bien ;
- est publié sous GPL-3.0-or-later pour le code et CC-BY-4.0 pour la documentation, ou sous des licences compatibles ;
- indique la version minimale de GEO et a été essayé dans un vrai GEO ;
- a quelqu'un pour l'entretenir, au moins pour répondre aux retours. Un module qui n'a plus de mainteneur peut être signalé comme tel dans le catalogue, plutôt que retiré ;
- inclut un README, un journal des nouveautés et ses mentions de licence, comme les modules existants.
Critères d'intégration¶
Une proposition est retenue si elle :
- reste dans le périmètre du module (un module fait une chose, bien) ;
- est désactivée par défaut quand elle change un comportement existant, ou compatible avec les configurations déjà enregistrées ;
- a été essayée dans un vrai GEO, avec la version de GEO précisée ; ce qui n'a pas été validé est signalé dans la description ;
- met à jour le journal des nouveautés (
CHANGELOG.md, pour les utilisateurs), la version et, si besoin, le README ; - respecte les conventions du module (messages de commit, langue, nommage) décrites dans son
CONTRIBUTING.md; - peut être maintenue par une autre personne que son auteur : code lisible, pas de dépendance fragile ou propriétaire ;
- ne contient ni secret, ni donnée personnelle, et respecte les licences des dépendances (compatibles GPL-3.0).
Une fonctionnalité qui ajoute une dépendance, un service externe ou un appel réseau est examinée plus attentivement : elle doit préciser ce qui est envoyé, à qui, et ce qui se passe si le service est indisponible.
Fusion, reprise et publication¶
Les dépôts GitHub des modules sont alimentés depuis le dépôt source de la collectivité. Cela a une conséquence pratique, que nous préférons écrire plutôt que laisser deviner :
- les mainteneurs fusionnent la demande de fusion sur GitHub après relecture ;
- le contenu est repris dans le dépôt source, avec les auteurs d'origine conservés ;
- il est publié avec la version suivante du module, dans un commit de synthèse qui mentionne les contributeurs (
Co-authored-by).
Les commits d'origine restent visibles sur GitHub, mais n'ont pas le même identifiant dans le dépôt source : seul le contenu fait référence.
Les contributions sont citées dans le README.md du module concerné.
Délais indicatifs (à valider ; voir Un projet bénévole) : première réponse à une issue ou une demande de fusion sous une semaine ; publication de la version suivante dans le mois qui suit la fusion.
Versions¶
Les modules suivent le versionnement sémantique : une correction incrémente le dernier chiffre, une fonctionnalité le deuxième, un changement
incompatible (réglage renommé ou supprimé, par exemple) le premier. Le numéro de version est fixé par les mainteneurs au moment de la publication
et reporté à l'identique dans package.json, src/plugin.geoext.json et CHANGELOG.md.
Suivi des travaux¶
Une feuille de route publique est prévue sous la forme d'un tableau de projet GitHub d'organisation, alimenté par les issues des dépôts de modules (à mettre en place). Statuts envisagés : Idée, À faire, En cours, À rapatrier, À publier, Publié. Il permet à chacun de voir ce qui est prévu, ce qui avance et ce qui attend une relecture.
Où discuter de quoi¶
| Besoin | Où |
|---|---|
| Une question, une astuce, un retour d'expérience | Discord du Club Utilisateurs GEO |
| Un bogue, une idée, une proposition | Issue du dépôt du module concerné |
| Une modification de code ou de documentation | Demande de fusion sur le dépôt du module |
| Le site, la gouvernance, un sujet transversal | Issue de geo-modules-community |
Licences et origine des contributions¶
En contribuant, vous acceptez que votre contribution soit publiée sous les licences du projet. Chaque commit porte une ligne Signed-off-by
(Developer Certificate of Origin) : elle atteste que vous avez le droit de proposer ce que vous envoyez.
Voir Contribuer.
Questions ouvertes¶
Points à trancher ensemble :
- Les délais de réponse et de publication ci-dessus sont-ils tenables et utiles ?
- Quel mode d'invitation des co-mainteneurs, et sur quels modules ?
- Les droits d'écriture : demandes de fusion relues pour tout le monde, ou accès direct pour des co-mainteneurs de confiance ?
- Où vit le code d'un module proposé par quelqu'un d'autre : dans un dépôt de l'organisation (comme les modules actuels), ou dans le dépôt de son auteur, simplement référencé dans le catalogue du site ?
- Faut-il un code de conduite pour le Discord et les dépôts ?