YunoHost/doc
1
0
Fork 0
mirror of https://github.com/YunoHost/doc.git synced 2024-09-03 20:06:26 +02:00
Code Issues Projects Releases Packages Wiki Activity

Merge pull request #1975 from YunoHost/project-organization-

Browse source 
Update from  project-organization
This commit is contained in:
yalh76 2022-05-03 20:43:17 +02:00 committed by GitHub
commit 132fe9919b
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
2 changed files with 216 additions and 498 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

329
pages/03.community/05.project_organization/yunohost_project_organization.fr.md
View file

@ -9,303 +9,176 @@ routes:
- '/project_organization'
---
! This page is outdated and should be reworked
## Objectif du document
# Objectif du document
Ce document a pour objectif de permettre aux contributeurs de se sentir légitimes d’effectuer une contribution dans le projet YunoHost avec un avis collectif. Il vise également à renforcer le projet en le structurant autour de groupes de travail autonomes pouvant résister au départ ou à l'absence de certains contributeurs.
Le projet étant communautaire, les décisions prises hâtivement et discrètement par un groupe restreint de contributeurs peuvent entraîner des frustrations postérieures.
Pour pallier ce problème, la solution proposée ici est de faire en sorte que les décisions soient prises collectivement, qu’elles soient suffisamment réfléchies, et qu'elles soient documentées ou rendues publiques.
Un conseil oriente l’évolution du projet YunoHost, et des groupes d’intérêts permettent de contribuer plus efficacement en fonction des domaines de prédilection de chacun.
Ce document a pour objectif de décrire la structure et le fonctionnement du collectif qui assure le développement et la maintenance du projet YunoHost.
## Définition de YunoHost
En particulier, en accord avec les valeurs portées par le projet, il est important de :
- maintenir une transparence sur le fonctionnement du collectif et les valeurs du projet
- d'expliciter le caractère ouvert du projet, pour que les personnes extérieures se sentent légitimes à contribuer au projet, en rejoignant ou non le collectif
- permettre aux membres du collectif de se sentir légitimes à discuter, contribuer et acter des décisions
- assurer la pérennité du projet en partageant les connaissances et responsabilités, et en limitant le "*bus factor*"
- limiter les asymétries de pouvoir
- avoir un mécanisme de prise de décision formel, par exemple pour résoudre un conflit, ou pour faire évoluer le collectif ou le projet.
### Objectifs
Le but de YunoHost est de rendre accessibles au plus grand nombre l’installation et l’administration d’un serveur, sans délaisser la qualité et la fiabilité du logiciel.
### Valeurs
# Intention du projet YunoHost
#### Un logiciel libre et communautaire
Dans un contexte où l'évolution des outils technologiques posent des enjeux sociétaux majeurs, YunoHost défend un Internet décentralisé et où les personnes restent au contrôle de leurs données et de leurs outils numériques. L'une des pierres angulaires de la construction d'un tel Internet est de drastiquement simplifier, rendre accessible et démocratiser la gestion des serveurs, là où cette pratique est traditionellement réservée à une élite technicienne.
YunoHost est un logiciel sous licence libre, entièrement communautaire, et reposant sur des applications elles-mêmes communautaires et souvent libres (Roundcube, Baïkal, etc.).
Ainsi, l'objectif du projet YunoHost est de construire un système d'exploitation et l'ensemble des outils nécessaires pour installer et gérer, en autonomie et sans trop de compétences techniques, un serveur et des services numériques dans un contexte privé (famille, groupe d'ami, ...) ou collectif (association, entreprise, école, ...).
Le collectif YunoHost est proche d'autres collectifs aux objectifs connexes tels que la FFDN, Framasoft, CHATONS, ou La Quadrature du Net. Le collectif est également sensible aux enjeux d'écologie et d'inclusivité.
#### Que chacun peut s'approprier
## Esprit et valeurs du projet
Historiquement, le projet est très proche des initiatives visant à la création d'un internet neutre et décentralisé. Cette proximité, notamment avec la [FFDN](https://www.ffdn.org/), a amené une partie des contributeurs de YunoHost à créer la Brique Internet dont la mission est de faciliter l'auto-hébergement en fournissant une solution complète incluant service (via un VPN) et matériel. Cet aspect militant n'entrave pas des initiatives commerciales du logiciel pour lequel des entreprises pourraient proposer du support ou de l'hébergement.
0. **Commun numérique** : Tous les éléments logiciels conçus par le projet YunoHost sont sous licence libre et le resteront. YunoHost est développé et maintenu essentiellement par le bénévolat d'une communauté ouverte, horizontale, et qui fait de son mieux en fonction du temps, des moyens et de l'énergie dont elle dispose.
1. **Accessible** : La conception de YunoHost s'articule en priorité autour des personnes ayant peu de connaissances techniques, avec des procédures, des interfaces et des documentations simples et pédagogiques.
## Organisation de YunoHost
2. **Sécurité** : YunoHost doit fournir un système raisonnablement maintenu à jour et raisonnablement sécurisé par défaut, et à guider les utilisateurices sur comment renforcer la sécurité de leur système.
### Une structure ouverte, organisée par thèmes
L'objectif de l'organisation de YunoHost est de permettre au plus grand nombre de contribuer à l'amélioration du logiciel, que ce soit d'un point de vue technique (développement, packaging d'application) ou non (communication, assistance aux utilisateurs, documentation, etc.). Inspiré par différents projets passés en revue lors de l'événement (Kodi, Debian, Django, Fedora, Wikipédia, etc.) et des idées de contributeur de YunoHost (Jérôme, Bram, opi, scith, ju), il a été décidé d'une organisation en groupes spécialisés, fédérés par un conseil de contributeurs clés.
3. **Bidouillabilité** : YunoHost doit permettre aux utilisateurices de s'approprier et modifier leur installation pour l'adapter à des besoins ou cas d'usages spécifiques ou qui ne sont pas encore bien gérés, ou pour personnaliser l'apparence.
Schéma d’organisation du projet YunoHost :
# Organisation de YunoHost
<img src="https://raw.githubusercontent.com/YunoHost/yunohost-project-organization/master/organization_schema.png" height="600px" />
YunoHost est développé et maintenu par une communauté bénévole, ouverte, horizontale.
Cette communauté est composée de :
#### Définition et constitution des groupes
La constitution de groupes part du constat que YunoHost compte beaucoup de sous-projets (treize au total), mais que l'on ne sait pas toujours qui en est en charge ou qui y est compétent. Il est donc proposé une simplification de l'organisation des sous-projets en groupes thématiques :
- les utilisateurices du projet
- les contributeurices occasionels
- les contributeurices réguliers
- ##### Groupe Core Dev
- Core YunoHost
- Moulinette
- Admin web
- SSOwat
- Dynette
- YNH-Dev
La communauté organise à intervalle régulier des réunions de coordination en ligne, qui sont publiquement annoncées et à laquelle n'importe quelle personne peut se joindre. <small>(Plus précisément, à l'heure de l'écriture de ce document, ces réunions ont lieu les 1er et 3ème mardi de chaque mois sur Mumble, et sont annoncées sur le forum.)</small> Le compte rendu de ces réunions est également rendu public.
- ##### Groupe Distribution
- Création et maintenance des images d'installation sur diverses architectures
- Distribution des images
- Gestion de la distribution des paquets Debian.
## Les utilisateurices
- ##### Groupe Infra/Adminsys
- Infrastructure
- Site web (wiki, forum, salon de discussion, Redmine, Mumble)
- Démo
- Services
- [ip.yunohost.org](https://ip.yunohost.org/) et ip6.yunohost.org
- [yunoports](http://ports.yunohost.org/)
- nohost.me et noho.st
- [yunodash](https://dash.yunohost.org/)
- [yunopaste](http://paste.yunohost.org/)
Il s'agit des personnes qui utilisent YunoHost dans leur vie quotidienne, demandent de l'aide, rapportent des bugs et font des retours d'expérience.
- ##### Groupe Apps
- Apps Officielles
- Apps Communautaires
- outils de développements d'app (package_checker, package linter)
La communauté est consciente de l'importance de demander et de prendre en compte les retours d'expérience et les cas d'utilisation des utilisateurices dans l'évolution du projet.
- ##### Groupe Communication
- Documentation
- Communication (annonce évolutions du projet sur le forum, réseaux sociaux)
- Traduction
- Entraide (support)
## Les contributeurices occasionels (OC)
Les groupes sont ouverts à tous les contributeurs souhaitant participer au développement de YunoHost. Chacun peut s'inscrire aux canaux de communication associés aux groupes auxquels il souhaite prendre part. Chaque inscrit est libre d'échanger avec le reste du groupe et de proposer une prise de décision à la suite d'une étape d'échange et d'amélioration de la proposition. Il est recommandé aux contributeurs de documenter au maximum leurs décisions et leurs contributions. Ceci permet de renforcer l'autonomie des groupes en cas de départs ou d'absences de certains de leurs membres.
Afin de faciliter sa gestion, chaque groupe nomme donc un coordinateur (et un remplaçant) dont le rôle est :
Il s'agit des personnes qui contribuent ponctuellement au projet. Toute personne le souhaitant est, sans accord prélable, bienvenue et légitime à contribuer au projet (sous couvert de ne pas aller à l'encontre des valeurs portées par le projet).
- d'accueillir et de fédérer les nouveaux contributeurs réguliers de son groupe
- de tenir informé le Conseil des décisions prises au sein du groupe (cf. point suivant)
La communauté met à disposition autant que possible de la documentation et des outils pour guider les nouvelles contributeurices dans leurs premières contributions dans un esprit de bienveillance.
Le choix d'un outil de communication est laissé à chaque groupe en fonction de sa pertinence (forum, chat, ML, etc.).
Les contributions se concrétisent souvent la forme de *Pull Request* (PR) (par exemple, sur le *core*, sur les apps, sur la doc, ...) mais peuvent aussi constituer des traductions, des éléments graphiques, des audits de sécurité, etc...
#### Définition et constitution du Conseil
Sauf exception, les contributeurices occasionels peuvent aider aux revues, mais n'actent pas elleux-même l'intégration de leurs travaux dans le projet. Iels n'ont également pas non plus de droit de vote lors des prises de décisions formelles. Iels sont cependant les bienvenues pour exprimer leur avis si iels le souhaitent.
YunoHost grandissant, il est important de maintenir une cohérence entre tous les groupes, néanmoins il est impossible d'imposer à chacun des membres des groupes de s'intéresser ou de s'impliquer sur tous les aspects du projet (pour des raisons de temps et de compétences). Pour pallier à cela, il est proposé de créer un méta-groupe, où chaque groupe sera représenté par au moins un de ses membres : le Conseil.
Le Conseil est indépendant des groupes et réunit les contributeurs souhaitant s'impliquer le plus dans le projet, son rôle est de :
## Les contributeurices réguliers (RC)
- prendre les décisions importantes sur YunoHost qui ne dépendent pas d'un seul groupe (par exemple changer le moteur du wiki)
- faire des points réguliers sur l'ensemble du projet pour assurer sa cohésion. (réunion Mumble)
- solliciter l'ensemble de la communauté des contributeurs (ou même des utilisateurs) quand une décision divise les groupes et/ou le Conseil
Il s'agit des personnes qui contribuent régulièrement au projet sous la forme de travaux, assurent la revue et actent l'intégration des travaux d'autres contributeurices, ainsi que la maintenance à court et long terme du projet dans son ensemble.
Le choix d'un outil de communication est laissé au Conseil, ses décisions doivent néanmoins être consultables par l'ensemble de la communauté de contributeurs.
Pour participer aux votes du Conseil, il faut avoir contribué au projet et avoir obtenu un droit de vote (ou d'entrée) au sein du Conseil. Ce droit est délivré par le Conseil (éventuellement sur demande). Le Conseil est libre à tout moment de modifier le processus de décision.
Être membre du Conseil n'implique pas forcément d'avoir l'ensemble des accès (infrastructure, dépôt etc.).
Les contributeurices réguliers sont organisés en groupes de travail :
### Processus de validation des pull requests
- **Groupe Core**: travaille sur la partie "système central" du projet (principalement les dépôts YunoHost, YunoHost-Admin, Moulinette, SSOwat), ainsi que des outils de distribution (paquets .deb, images préinstallées), de développement (ynh-dev).
- **Groupe Apps**: se concentre sur le packaging de nouvelles applications et assurent collectivement la maintenance de l'écosystème d'applications existants, ainsi que l'indexation dans le catalogue, la définition des bonnes pratiques de packaging, et des outils et métriques de contrôle qualité.
- **Groupe Infra**: déploie, administre, maintient et sauvegarde les différents services dont a besoin le projet (documentation, forum, chatrooms, demo, paste, stack mail, CI, diagnostique, dynette, dashboard, ...)
- **Groupe support / doc / comm**: anime l'entraide sur le forum et les salons de support, assure la maintenance et mise à jour de la doc, communique sur les évolutions du projet sur le forum, les réseaux sociaux, ou en conférence.
Cette section détaille le processus de validation des pull requests dans les différents dépôts du projet. L'objectif de ce processus est de dégager un « consensus mou ». Il est important de préciser que ce processus est *recommandé* mais ne représente pas un impératif. En particulier, il ne couvre pas toutes les situations qui peuvent se présenter. Il est donc légitime de l'adapter (avec l'accord du groupe concerné) lorsqu'il n'est pas adapté au contexte.
Les connexions étant multiples entre ces différentes thématiques, il n'est pas rare qu'une personne soit membre de plusieurs de ces groupes. Néanmoins il est nécessaire et suffisant d'être membre d'un de ces groupe pour obtenir la qualité de contributeurice régulier.
Si un consensus ne peut être trouvé au sein d'un groupe en suivant le processus décrit, il est invité à se tourner vers le Conseil pour en débattre. Si aucun consensus n'est trouvé, la proposition sera soumise au vote de tous les contributeurs.
N'importe quelle personne ayant déjà contribué au moins une fois au projet peut demander le statut de contributeurices régulier. Cette demande est ensuite sujette à un vote d'acceptation par l'ensemble des autres contributeurices réguliers.
#### 1. Proposition
Le fait d'être membre d'un groupe ouvre le droit à certains droits d'administration détaillés dans l'annexe A, typiquement le droit de valider et d'intégrer ses propres travaux ou les travaux d'autres contributeurices. Il convient de faire un bon usage de ces droits tels que décrit dans la section suivante. Être contributeurices réguliers permet également de proposer un vote lorsqu'il est nécessaire d'acter formellement une décision pour le projet.
N'importe quel contributeur peut proposer une pull request (abrégée PR dans la suite) dans les divers dépôts liés au projet YunoHost (core, apps, infra...).
Il est attendu des contributeurices réguliers de se coordonner régulièrement avec le reste de l'équipe, par exemple en participant aux réunions ou bien via le chat et le forum.
L'auteur est vivement encouragé à décrire sa proposition en donnant le maximum des informations
pertinentes. Le groupe peut, à cette fin, proposer un modèle des informations à
inclure, comme par exemple :
- status actuel de la PR (ex. : non terminé, en attente de revues, choix techniques à faire...)
- problème auquel réponds la PR (et références liées, par ex. : ticket sur le bugtracker, post sur le forum...)
- solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR
- comment tester la PR
La perte de la qualité de membre d'un groupe s'opère par départ volontaire de la personne, ou suite à un vote de radiation pour inactivité, non-respect des chartes ou des valeurs du projet, ou abus des droits d'administration.
L'auteur est vivement encouragé à respecter les bonnes pratiques suivantes :
- une PR doit concerner exclusivement un sujet précis. Par exemple, elle ne doit pas à la fois résoudre un bug et ajouter une fonctionnalité (à moins que l'un implique l'autre) ;
- avant de débuter l'implémentation d'une fonctionnalité qui fait intervenir des choix de conception (nom et format de commande ou d'option, nouvelle API, interface utilisateur...), discuter en amont de manière informelle avec le groupe pour s'assurer que l'implémentation imaginée convienne au plus grand nombre et reste dans l'esprit du projet ;
- nommer sa PR avec un titre explicite, et la branche associée avec un nom explicite ;
- donner les références vers d'autres éléments liés à la PR (rapport de bug sur le bugtracker, message sur le forum...)
Une PR peut être créée même si son auteur juge qu'elle n'est pas encore terminée. Dans ce cas, il doit déclarer explicitement dans le fil de discussion de la PR lorsqu'il juge la PR prête. Cela n'empêche pas les autres contributeurs d'émettre des avis sur la PR pendant ce temps.
# Validation et d'intégration des PR
Il appartient aussi à l'auteur de la PR de juger de son importance. (Ce jugement pourra cependant être contesté par les autres membres du groupe concerné par la PR.) Les niveaux d'importance utilisés sont les suivants :
- **micro** : concerne uniquement un détail de forme et/ou qui ne nécessite pas d'être débattue et testée. Elle doit être facilement réversible.
- **mineure** : impacte de manière légère le projet (e.g. refactoring d'une petite partie de code, réparation d'un bug...)
- **moyenne** : impacte de manière significative l'architecture d'une partie du code (e.g. refactoring de tout un aspect ou de tout un fichier, ajout d'une fonctionnalité importante, sortie d'une version testing...)
- **majeure** : impacte lourdement l'ensemble du projet (e.g. migration d'une dépendance critique, changement de version de Debian, sortie d'une version stable...)
De par la nature du projet, les contributions se concrétisent principalement sous la forme de "demandes d'intégration" (en anglais *Pull Request* (PR) ou *Merge Request* (MR)). La réalisation, la revue, et la validation collective des PR sont des enjeux importants, puisqu'ils s'agit précisément de ce qui rend le projet vivant d'un point de vue purement technique.
Derrière chaque demande d'intégration peut se cacher des problématiques humaines et techniques variées parmis lesquelles la stabilité (ne pas tout casser à cause d'une ramification imprévue), la sécurité (ne pas introduire de faille ou de code malveillant), la pérennité (limiter le *bus factor* et la dette technique), le pragmatisme ("good enough"), l'accord avec l'esprit du projet (UX, ..), l'évolution sur le court et long terme. Le processus de revue et de validation d'une PR est lui en aussi un exercice compliqué dans la mesure où il est couteux en temps, et peut être source de tension ou de frustration. L'un des freins à la validation d'une PR est aussi souvent lié à un sentiment de manque de légitimité à acter l'intégration d'une PR, ou à l'impact psychologique d'être la personne qui a acté l'intégration d'une PR.
#### 2. Revue et validation collective
Un enjeu crucial de l'organisation du projet est donc de trouver un ensemble de règles et de bonne pratiques qui permettent un fonctionnement fluide, équilibré, avec une validation autant que possible par consensus, et qui répartisse la responsabilité sur le collectif plutôt que les individus.
(Cette section ne s'applique pas aux PR "micro" qui peuvent être validées directement par leur auteur.)
## Bonnes pratiques et recommendations
Une fois la PR déclarée comme terminée, les contributeurs sont invités à donner leurs avis, relire et tester les changements proposés pour les valider. Lorsque des bugs ou des implémentations mauvaises ou incomplètes sont trouvées, les relecteurs rapportent cordialement le problème à l'auteur de la PR sur le fil de discussion. Si le problème trouvé est simple à corriger (e.g. typo ou détail de forme), le relecteur est encouragé à amender la PR pour corriger le problème lui-même. Sinon, l'auteur fait de son mieux pour corriger les problèmes soulevés.
- Lorsque un travail a des implications importantes (ou, pour les contributeurs occasionels), il est fortement encouragé de discuter en amont avec le reste de l'équipe pour s'assurer que l'implémentation imaginée convienne avec l'esprit du projet et avec les autres travaux de l'équipe.
- Décrire correctement sa PR et le problème auquel elle répond (et le cas échéant, les détails techniques nécessaires pour tester)
- Veiller à corriger les problèmes remontés par les outils de tests automatique (CI)
Les relecteurs rapportent également le degré de relecture et de tests effectués (c.f. liste ci-dessous). Selon l'importance de la PR (mineure, moyenne ou majeure), différents quotas de tests et approbations sont à remplir pour que celle-ci soit validée. Les relecteurs peuvent valider une fois chaque type de relecture/test nécessaire (par exemple, un relecteur peut donner un point d'accord sur le principe, un autre point de relecture en diagonale, et un autre point de test dans des cas simples.). L'auteur de la PR ne compte pas dans ces quotas de validation. La proposition doit aussi passer les tests automatiques disponibles dans le groupe (CI, tests unitaires/fonctionnels, linter...).
## Processus de validation
| | **Mineure** | **Moyenne** | **Majeure** |
|-----------------------------------|-------------|--------------|-------------|
| **Accord sur le principe** | 2 | 3 | 4 |
| **Relecture en diagonale** | 1 | 2 | 3 |
| **Testé dans les cas simples** | 1 | 2 | 3 |
| **Relecture attentive** | 0 | 1 | 2 |
| **Testé dans des cas compliqués** | 0 | 1 | 2 |
Cette section détaille le processus de validation des PR dans les différents dépôts du projet. L'objectif de ce processus est d'obtenir un « consensus mou ».
Si l'auteur ne fait pas parti du groupe concerné par la PR, tous ces quotas sont augmentés de 1. Dans tous les cas, ces quotas doivent être remplis au moins à 50% par des relecteurs membres du groupe concerné par la PR. (Ainsi, par exemple, un non-membre peut donner son accord sur le principe pour une PR mineure. Mais deux avis de non-membres pour une PR moyenne comptent uniquement pour un seul avis).
Les contributeurices ont la responsabilité individuelle et collective de jauger de l'importance d'une PR pour définir à quel point elle doit faire l'objet d'une validation légère ou approfondie par d'autres membres du groupe.
- Les PR "micro": il s'agit d'une correction typographique, d'un correctif pour un bug évident... Ces PR peuvent être intégrées par son auteur sans validation explicite par un autre membre du groupe.
- Les PR "moyennes": il s'agit d'opération de maintenance (par ex. mise à jour d'une application, nettoyage/refactoring mineur, ajout d'une petite fonctionnalité, ...). Il est généralement mieux d'obtenir une validation d'un autre membre du groupe.
- Les PR "gros chantier" : il s'agit de nouvelles fonctionnalités ou de refactorings importants, ayant des conséquences majeures pour le futur du projet ou de l'app. Il est alors fortement conseillé d'obtenir une validation approfondie par au moins un autre membre du groupe, et un accord de principe des autres membres.
#### 3. Merge d'une pull request
Les autres contributeurices peuvent librement prendre part à la revue d'une PR. L'auteur d'une PR peut également solliciter ou rappeler aux autres contributeurices que sa PR est en attente d'une revue. Au bout d'un certain délai, s'il s'avère qu'aucune contributeurice n'a de temps ou d'énergie disponible pour participer à la revue d'une PR, alors elle peut tout de même être mergée par son auteur.
Une fois les quotas de relecture remplis, et si aucun refus n'a été prononcé et qu'aucune demande de changement n'est en attente, n'importe quel membre du groupe peut alors déclarer et marquer la PR comme "prête à être mergée".
Si un désaccord émerge pendant ou après la validation d'une PR, une discussion cordiale doit être privilégiée avec le reste de l'équipe dans le but de dégager un consensus sur la marche à suivre. Si aucun consensus n'est trouvé, un vote est organisé pour prendre une décision, auquel peuvent prendre part toutes les contributeurices régulier du projet.
Pendant une durée de 3 jours suivant cette déclaration, les membres du groupe peuvent encore relire, demander des changements ou émettre un refus vis-à-vis de la PR. Dans ce cas, le merge est interrompu et le processus retourne à la partie 2. Pour les PRs moyennes et majeures, la durée est augmentée jusqu'à ce qu'il se soit écoulé au moins une semaine par rapport au moment où la PR a été déclarée comme prête par son auteur.
# Prises de décision collective
À l'issue de cette durée, n'importe quel membre du groupe peut merger la PR. Lorsque celle-ci comporte plusieurs commits, il est recommandé d'utiliser la fonction "squash and merge" pour garder l'historique de commit propre.
Lorsque les contributeurices régulier ont besoin de prendre une décision formelle relative au projet ("résolution"), ou pour résoudre un conflit après qu'une recherche de consensus ait échoué, n'importe quel contributeurices régulier peut déclencher un processus de vote formel. Toutes les contributeurices régulier peuvent prendre part à ce vote.
#### Cas particuliers
# Annexe A. Droits d’administration afférents aux groupes
Plusieurs cas particuliers peuvent se présenter et dont la résolution est décrite ci-après.
Cette partie liste les droits d’administration pour les différents groupes du projet YunoHost.
##### Refus d'une PR
N.B. il ne s’agit pas des droits de prises de décisions, mais des droits d'accès et de modification sur les différentes plateformes utilisées par le projet.
Une PR peut être refusée et clôturée par n'importe quel membre du groupe concerné si :
- la PR a été créée au moins depuis deux semaines
- au moins deux membres du groupe ont manifesté un désaccord avec le principe de la PR
- aucun autre membre du groupe n'a manifesté son accord avec le principe de la PR
Les membres de ces groupes s'engagent à respecter [la charte d'administration système du projet](adminsys_charter.md).
##### Co-création
### Core
Une PR peut être développée par plusieurs personnes. Chacun est invité à y faire des commits en se concertant avec l'auteur initial ou le nouveau gestionnaire de PR si l'auteur est indisponible, manque de temps ou souhaite se consacrer à d'autres travaux.
Si ces commits sont conséquents, dans ce cas on peut prendre **partiellement** en compte l'avis des auteurs dans les quotas de relectures et de tests.
Exemple : si une PR est écrite par A et B (50/50), A et B pourront relire le code de l'autre. Dans ce cas, on pourra par exemple compter une relecture pour ces 2 relectures partielles.
##### Validation "allégé" en cas de manque de relecteurs
En cas de manque de relecteurs, l'auteur d'une PR peut déclencher une procédure de validation alternative si :
- l'auteur est membre du groupe concerné par la PR
- il s'agit d'une PR mineure ou moyenne
- la PR a été déclarée comme prête
- il n'y a pas de demande de changement en attente
- les quotas de relecture "standards" n'ont pas été remplis
- une semaine s'est écoulée depuis le dernier commentaire ou commit
Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite engager cette prodécure ainsi que sur la liste de diffusion (ou lors d'une réunion du mardi). À partir de ce moment, les quotas d'accord, relecture et tests pour valider cette PR sont diminués de 1. Au minimum une semaine devra s'écouler avant que cette PR ne soit effectivement mergée. Un autre membre du groupe peut à tout moment mettre fin à cette procédure si il juge la PR trop critique pour être mergée de la sorte.
## Composition des groupes
- Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore.
- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi
- Apps : Bram, cyp, frju365, JimboJoe, Josue-T, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki
- Infra : Bram, Ju, Maniack C, Moul, opi
- Communication
- Com : Bram, Moul, korbak, ljf, opi, frju365
- Doc : Moul, Theodore
- Trad : Jean-Baptiste
- Distribution : Heyyounow
## Droits d’administration afférents aux groupes
Cette partie liste les kits de droits d’administration pour les différents groupes du projet YunoHost :
(Attention, il ne s’agit pas des droits de prises de décisions dans ce cas).
### Conseil
- Aucun droits d’administration. Les droits sont complétés avec le fait d’être présents dans les autres groupes,
- Forum : membre du [groupe `Conseil`](https://forum.yunohost.org/groups/Conseil).
### Dev
- GitHub : membre de l’[équipe `Devs` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/devs),
- Redmine : membre des projets [`YunoHost`](https://dev.yunohost.org/projects/yunohost) et [`Moulinette`](https://dev.yunohost.org/projects/moulinette),
- Intégration continue : droits sur les outils d’intégrations continue CI-core,
- XMPP : modérateur du salon [`dev`](xmpp:dev@conference.yunohost.org?join),
- GitHub : membre de l’[équipe `Devs` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/devs)
- permission de créer des branches, merger des PR (en respectant les règles énoncées plus haut)
- Intégration continue : droits d'accès au Gitlab pour interagir avec la CI core ?
- Forum : membre du [groupe `Dev`](https://forum.yunohost.org/groups/Dev).
### Infra
- Serveurs : accès SSH par clé sur certains (selon les besoins) ou sur la totalité des serveurs,
- GitHub : membre de l’[équipe `Infra` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/infra),
- Redmine: membre du [projet `Infra`](https://dev.yunohost.org/projects/y-u-no-infra/),
- Forum, Weblate, Redmine, XMPP, CI: administrateur,
- Forum : membre du [groupe `Infra`](https://forum.yunohost.org/groups/Infra).
- Chatrooms: admin sur la chatroom Dev
### Apps
- GitHub : propriétaire (Owner) [de l’organisation YunoHost-Apps](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner),
- Redmine : membre du [projet `Apps`](https://dev.yunohost.org/projects/apps),
- GitHub : membre de l’[équipe `Apps` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/apps),
- Intégration continue : accès à [CI-Apps](https://ci-apps.yunohost.org),
- XMPP : modérateur sur le [salon `Apps`](xmpp:apps@conference.yunohost.org?join),
- GitHub : propriétaire (Owner) [de l’organisation YunoHost-Apps](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner)
- permission de créer des branches et de merger des PR sur tous les dépôts d'app (en respectant les règles énoncées plus haut)
- Github : membre de l’[équipe `Apps` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/apps)
- permission de créer des branches et de merger des PR sur le dépôt du catalog (apps), example_ynh, package_linter, package_check, ... (en respectant les règles énoncées plus haut)
- Forum : membre du [groupe `Apps`](https://forum.yunohost.org/groups/Apps).
- Chatrooms: admin sur la chatroom Apps
### Communication
- Forum : membre du [groupe `Com`](https://forum.yunohost.org/groups/Communication).
### Infra
- Serveurs : accès SSH par clé sur certains (selon les besoins) ou sur la totalité des serveurs,
- GitHub : membre de l’[équipe `Infra` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/infra),
- Forum, Weblate, XMPP, CI: administrateur,
- Forum : membre du [groupe `Infra`](https://forum.yunohost.org/groups/Infra).
- Chatrooms: admin sur la chatroom Dev et Infra
### Support, Doc, Communication, Traduction
#### Doc
- GitHub : membre de l’[équipe `Doc` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/doc).
#### Communication
- permission de créer des branches et de merger des PR sur le dépôt "doc" (en respectant les règles énoncées plus haut)
- Forum : statut de modérateur, membre du [groupe `Support & Doc`](https://forum.yunohost.org/groups/Support_Doc), possibilité d'avoir le badge du groupe visible à côté de l'avatar.
- Diaspora* : accès au compte [YunoHost](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
- Twitter : accès au compte [YunoHost](https://twitter.com/yunohost),
- Forum : accès au compte [`YunoHost`](https://forum.yunohost.org/users/yunohost/activity).
#### Traduction
- Weblate : administrateur sur l’[outil de traduction](https://translate.yunohost.org/projects/yunohost/).
- Chatrooms: admin sur la chatroom Doc
#### Entraide
- Forum : statut de modérateur,
- XMPP : statut de modérateur sur le salon [`support`](xmpp:support@conference.yunohost.org?join).
# Annexe B. Composition des différents groupes
### Distribution
- GitHub : membre de l’[équipe `Distrib` de l’organisation `YunoHost`](https://github.com/orgs/YunoHost/teams/distribution),
- Information : la diffusion des images (ISO…) doit se faire en collaboration avec le groupe `Infra` (et `Doc`),
- Publication : un accès SFTP peut être mis en place,
- Forum : membre du [groupe `Distribution`](https://forum.yunohost.org/groups/Distribution).
Dernière mise à jour le 2022-03-15
## Décisions à venir pour les groupes
### Conseil
- Faut-il élire les membres du Conseil plutôt que de les coopter ? Risque de se transformer en "campagne politique" !
- Faut-il limiter l'ouverture des groupes d'intérêts par cooptation comme pour le Conseil ?
- Proposition de changer Conseil en Collégiale
- Migrer le serveur d’infrastructure du projet sous YunoHost. (avec apps déjà packagées pad, Gogs, Mumble?)
- Nouveau système pour la documentation
- Amélioration de la documentation
- Migration du serveur XMPP
- Hébergement de notre forge Git
- Revoir système de build : stable <— testing <— branches
- Gel de nohost.me et question de l'abandon des services
- **Core** : Aleks, Bram, Kayou, ljf, Tagadda, axolotle, tituspijean
- **Apps** : Ericg, Josue, Kayou, tituspijean, yalh76, frju365, Tagadda
- **Infra** : Aleks, Bram, Kayou, ljf, yalh76, tituspijean
- **Support/doc/comm/trad/bureaucracy** : Aleks, Ericg, ljf, tituspijean, Tagadda, JimboJoe, wbk
### Groupe Dev
- Comment gérer les pull request ?
- Chaque ticket fait l'objet d'une branche et d'un ticket, tu fais une pull/merge request, la communauté vérifie que ça fonctionne, une décision est prise d'intégrer.
# Annexe C. Résolutions
### Groupe Apps
- Pour les apps communautaires, les issues sont bien sur GitHub, les discussions sur le forum
### Groupe Communication
- Rapport de bug à partir du forum
- Faire en sorte de nettoyer le forum pour éviter le bruit
- Proposition de supprimer le salon de support
- Comment rendre le forum plus actif et central
- Comment s'organiser pour les privilèges sur le forum (si les groupes veulent voter sur le forum)
### Autres
- Demande sur le forum avec notification des membres du Conseil et des représentants des groupes d’intérêts concernés.
- Vote sur deux semaines par un post sur le forum
- Créer quatre canaux pour le Dev, les Apps, la Communication et l'Infrastructure
- La release devrait être validée par l'ensemble des 4 (ou 5) groupes d’intérêts
- Communication en français et en anglais
- Annuaire ou contact des groupes pour les nouveaux arrivants. Voir peut-être annuaire tout court pour savoir qui fait quoi. https://yunohost.org/#/contribs_fr à compléter. Et à mettre en avant.
- Proposition de laisser les membres YunoHost s'auto déterminer -> Comment gérer les accès ?
## Moyens de communication actuels
- Rencontres à des évènements.
- Réunions hebdomadaires Mumble.
- [Forum](https://forum.yunohost.org).
- [Bugtracker Redmine](https://dev.yunohost.org).
- Forge Git pour la review de code : [YunoHost](https://github.com/YunoHost) [YunoHost-Apps](https://github.com/YunoHost-Apps).
- [Salons de discussions XMPP](https://yunohost.org/#/chat_rooms_fr)
- Sur le fait que la vente commerciale de services liés à YunoHost, tels que la distribution, le support, ou l'infogérance, est autorisée.
- Sur les bonnes pratiques de packaging d'app, en particulier de respecter la pratique commune définie dans example_ynh plutôt que de factoriser
- Dates des réunions
- Sur les critères d'intégration des apps dans le catalogue

385
pages/03.community/05.project_organization/yunohost_project_organization.md
View file

@ -9,326 +9,171 @@ routes:
- '/project_organization'
---
! This page is outdated and should be reworked
## Document objective
# Goal of this document
This document aims at allowing contributors to feel legitimate in contributing to the YunoHost project together with collective feedback.
The project is community-based and hasty decisions made by a restricted group of contributors can generate frustrations at a later stage.
To address this issue, the proposed solution here is to ensure that decisions are taken collectively and that they are sufficiently thought out.
An advisory council provides orientations for the evolution of the YunoHost project and special interest groups allow more efficient contribution in relation to each specific topic.
This document aims at describing the structure and the way the collective works to make development and maintenance of YunoHost possible.
More specifically, in line with the values of the project, it is important to:
## Definition of YunoHost
- maintain transparency on the functioning of the collective and the values of the project
- explain the open nature of the project, so that outsiders feel entitled to contribute to the project, by joining or not joining the collective
- enable the members of the collective to feel legitimate to discuss, contribute and act on decisions
- make the project sustainable, by sharing knowledge and responsibilities, by limiting the “bus factor”
- limit power asymmetries
- have a formal decision-making mechanism, e.g. to resolve a conflict, or to develop the collective or the project
###Objectives
# Goal of the YunoHost project
The goal of YunoHost is to make accessible to the largest number of people, the installation and administration of a server, without prejudice to the quality and reliability of the software.
In a context where the evolution of technological tools lead to major societal challenges, YunoHost advocates an Internet that is decentralised and that allows people to remain in control of their data and their digital tools. One of the tenets of such an Internet is to drastically simplify, make accessible and to democratise server administration, when this is traditionnaly reserved to a technical elite.
### Values
As such, the goal of the YunoHost project is to build an operating system and all the necessary tools to install and administer, autonomously and without too many technical skills, a server and digital services in a private context (family, group of friends…) or collective (non profit, company, school…).
#### A free and community-based software
The YunoHost collective is close to other like-minded collectives, such as FFDN, Framasoft, CHATONS, or La Quadrature du Net. The collective is also sensitive to ecological issues and inclusivity.
YunoHost is a software under free licence, fully community-based and based on applications which are themselves community-based and often free (Roundcube, baïkal, etc.)
## Spirit and values of the project
#### That everyone can appropriate
0. 1. **Digital commons**: all software produced by the YunoHost project is published as Free Software and will remain Free. YunoHost is developed and maintained mostly by volunteers in an open, horizontal community, that does their best with the time, means and energy they have.
Historically, the project has been very close to initiatives which aim at creating a neutral and decentralised Internet. This proximity especially with the [FFDN](https://www.ffdn.org/), has materialised by having some contributors to create the InternetCu.be whose mission is to facilitate self-hosting by providing a complete solution including a service (via a VPN) and a device. This militant aspect does not inhibit commercial software initiatives hereby companies could propose support or hosting.
1. 2. **Accessibility**: the design of YunoHost is centered on people with little technical knowledge. Its processes, interfaces and documentation should be simple and educational.
## YunoHost organisation
2. 3. **Security**: YunoHost must provide a fairly up to date system, with reasonable security by default, and guide the users on ways to harden their system.
### A theme-based, open structure
3. 4. **Hackability**: YunoHost must allow its users to take ownership of and modify their installation, to adjust it to their needs, or specific use cases, or uses that are not yet covered, or to tweak the look and feel.
The objective of the YunoHost organisation is to allow the largest number of people to contribute to software improvement, whether from a technical point of view (development, application packaging) or otherwise (communication, end-user assistance, documentation, etc.). Inspired by the projects which were reviewed at a recent event (Kodi, Debian, Django, Fedora, Wikipedia, etc.) and by ideas stemming from YunoHost contributors (Jérôme, Bram, opi, scith, ju), a decision was made to organise work by special interest groups, federated thanks to a council to key contributors.
# Yunohost organization's
Yunohost is developed and maintained by community of volunteers. The community has an open and horizontal structure.
YunoHost project organisation schema
Members of Yunohost are part of :
- regular users
- occasional contributors
- regular contributors
<img src="https://raw.githubusercontent.com/YunoHost/yunohost-project-organization/master/organization_schema.png" height="600px" />
The community organizes regulary meetings who are open to everyone. You can find the date on the forum of project. <small>(Actually these meetings are planned the 1st and 3rd tuesday every month on Mumble.)</small> The notes of these meetings are public as well.
#### Definition and structure of groups
## Users
Groups are structured as a result of the fact that YunoHost counts many sub-projects (a total of 13), but without always knowing who is in charge or who is competent. It has therefore been decided to simplify the organisation into sub-projects according to theme-based groups:
This refers to the people who use YunoHost in their daily life, who ask for help, speak about bugs and make contributions.
- ##### Core Dev Group
- YunoHost Core
- Moulinette
- Web admin
- SSOwat
- Dynette
- YNH-Dev
The community is aware about the importance to listen to users and take advice about their contributions for the future of the project.
- ##### Distribution Group
- Creation and maintenance of installation images on various architectures
- Distribution of images
- Management of Debian packages distribution
## Occasional contributors
- ##### Infra/Sysadmin Group
- Infrastructure
- Website (wiki, forum, chat room, redmine, Mumble)
- Demo
- Services
- [ip.yunohost.org](https://ip.yunohost.org/) and ip6.yunohost.org
- [yunoports](http://ports.yunohost.org/)
- nohost.me and noho.st
- [yunodash](https://dash.yunohost.org/)
- [yunopaste](http://paste.yunohost.org/)
These are the people who contribute to the project on an ad hoc basis. Any person wishing to do so is, without prior agreement, welcome and entitled to contribute to the project (provided that they do not go against the values of the project).
- ##### Apps Group
- apps.json list
- App development tools (package_checker, package linter)
The community provides as much documentation and tools as possible to guide new contributors in their first contributions in a spirit of caring.
- ##### Communication Group
- Documentation
- Communication (announcement of project evolutions on the forum, social networks)
- Translation
- Mutual assistance (support)
Contributions often take the form of *Pull Request* (PR) (for example, on the *core*, on the apps, on the doc, ...) but can also be translations, graphic elements, security audits, etc...
Groups are open to all contributors willing to participate to the development of YunoHost. Everyone can register with the communication channels associated with the group they want to get involved with. Everyone is free to exchange with the rest of the group and to submit a decision point which will follow a prior stage of exchange and improvement of the proposal.
In order to facilitate its management, each group names a coordinator (and a deputy) whose role is:
With some exceptions, occasional contributors can help with reviews, but they do not act to integrate their work into the project. They also do not have a vote in formal decision-making. They are, however, welcome to express their opinions if they wish.
- to welcome and to federate new regular contributors to the group
- to keep the Council informed of decisions taken within the group (see next point)
## Regular contributors (RC)
The choice of a communication tool is left to each group depending on its relevance (forum, chat, email, etc.)
These are the people who regularly contribute to the project in the form of work, ensure the review and integration of the work of other contributors, as well as the short and long term maintenance of the project as a whole.
#### Definition and structure of the Council
Regular contributors are organised into working groups:
YunoHost is growing and it's important to maintain a coherence among all the groups. However, it is impossible to impose on every member within every group to take interest or to get involved in all aspects of the project (due to time and competency constraints). To address this, it has been suggested that a meta-group be created where every group has at least one representative: hence the Council.
The Council is independent of groups and brings together contributors wishing to get involved in the project to the maximum extent. It's role is to:
- **Core Group**: work on the central system part of the project (mainly YunoHost, YunoHost-Admin, Moulinette, SSOwat repositories) and on the distribution tools (.deb packages, preinstall images) and development (ynh-dev)
- **Apps Group**: focus on new applications packaging and collectively maintain current apps, work also on catalog index, define good packaging practices and metrics tools for quality control.
- **Infra Group**: deploys, administers, maintains and saves the various services needed by the project (documentation, forum, chatrooms, demo, paste, stack mail, CI, diagnostic, dynette, dashboard, …)
- **Support / doc / comm group**: animates the mutual aid on the forum and the support rooms, ensures the maintenance and update of the doc, communicates on the evolutions of the project on the forum, the social networks, or in conference.
- take important decisions affecting YunoHost which are dependent on one single group (for instance, changing the wiki engine)
- regularly follow up on the overall aspect of the project to ensure its cohesion (Mumble meeting)
- call on the whole community of contributors (or even end-users) when a decision appears divisive between groups or within the Council
Since there are multiple connections between these different themes, it is not uncommon for a person to be a member of several of these groups. Nevertheless it is necessary and sufficient to be a member of one of these groups to obtain the status of regular contributor.
To take part at Council-level votes, you must have contributed to the project and have obtained a right to vote (or right of entry) at the Council. This right is delivered by the Council (and may be upon request). The Council is free at any moment to change its decision process.
To be a member of the Council does not imply that you have access to all resources (infrastructure, repositories, etc.).
Anyone who has already contributed at least once to the project can apply for regular contributor status. This request is then subject to a vote of acceptance by all the other regular contributors.
### A decision process based on soft consensus
Being a member of a group entitles you to certain administrative rights detailed in appendix A, typically the right to validate and integrate your own work or the work of other contributors. Good use should be made of these rights as described in the next section. Being regular contributors also makes it possible to propose a vote when it is necessary to formally record a decision for the project.> []
Decisions to be taken can be of 2 kinds:
Regular contributors are expected to coordinate regularly with the rest of the team, for example by participating in meetings or via chat and forum.
1. for a group (for example, "to merge a PR" would be assumed by the Dev Group whereas to "post a tweet" would fall under the responsibility of the Communication Group)
2. for the overall project (for instance, to decide on a release with new features)
If a consensus is not reached over a decision within a particular group, they must refer to the Council for further discussions. If no consensus has been reached, the proposal will be submitted to a vote by all contributors.
#### The decision process in detail
##### 1) Initiating a decision
- can be initiated by anyone following predefined media within each group (e.g. to open a PR automatically triggers this process)
- necessarily public with the exception of well-defined situations (bug related to a critical security issue or vote relative to individuals)
- an end-date is automatically set for every type of proposition. This date is used for various reasons:
- to leave enough time for everyone to express themselves and to avoid hasty decisions
- to maintain a certain rhythm otherwise if the quota of responses is reached then there's no need to wait for everyone's views within a group
- the quota is evaluated according to people registered in a group (or the Council, depending on the situation) who have expressed their desire to be considered as a regular voter => for instance kload could wish to give their opinion at a particular occasion, but with no intention of applying as a active voting member at the Council
- so it can be postponed upon simple request by any one member of the group—and only the group, not all contributors.
##### 2) Opening a discussion with several possible responses:
Anyone can change their position at any moment, but it's expected to let the group react if necessary (e.g. avoid going from positive to negative to reject a proposal altogether after just 3 minutes).
- "simple" replies
- "I agree" –> counts as a positive view
- "It seems good to me, but I'd rather abide by others' opinion" –> if there are only such views (or like the next one) and at least one positive view and the due date is past, then the proposal is accepted
- "no views" / "I'm not in a position to express a helpful view (e.g. I can't code in X)"
- delayed reponse
- request for clarification, in which case the decision is suspended
- refusal: any refusal should be argued and justified
##### 3) Suspension/Postponement
- while there is no response, a decision is considered suspended; at the moment of a response, the end date is automatically postponed (if needed) (for a duration to be determined, which is shorter than the initial time)
- in a situation where there are positive and negative views, or where there is a choice between several proposals
##### 4) Request for modifications
- however, it may happen that discussions take place around these modifications; if such is the case, there is a new decision to be added to the list of existing decisions, and the process applies again (with a postponement of the date)
- if there aren't enough people agreeing, the date is postponed and a recall must be sent
- if the result is very close, the group is invited to rediscuss the matter if it is important, otherwise this could turn into a divisive issue and of tensions in the future
##### 5) Closure
- if the group is unanimous in its decision
- with agreements only
- with refusals only
- no opinions (relying on others' views)
- For a minor or standard decision, if the quota of responses is reached by the minimal deadline and there's a consensus.
- The quota of responses means necessary views as detailed below according to different types of decisions. The percentage is based on the number of active members in the group. The coordinator and its deputy are in charge of managing active and inactive members in a group, as they maintain an up-to-date list of members at least at every decision point within the group. (An inactive member who shows up for a decision automatically becomes active).
- If it isn't possible to have enough people (vacations, not enough members in a group to provide their views), a group can request closing a vote before the voting quota is reached; there's then a new postponement and if the new postponed date is reached, then the proposal is closed according to recorded views.
###### Micro-decision:
- A decision taken and immediately applied by a single member. This kind of decision must necessarily be reversible, and can be questioned by anyone from any group.
###### Minor decision
- Initial duration: 1 week.
- Minimal duration: 3 days.
- Postponement, if necessary: 3 days.
- Necessary views: 2 members of a group (the person who initiated the decision can express their view); in an anticipated format, 3 of which 2 members of the group.
###### Standard decision:
- Initial duration: 2 weeks.
- Minimal duration: 1 week.
- Postponement, if necessary: 1 week.
- Necessary views: 50% of members of a group (the person who initiated the decision can express their view); in an anticipated format, 66% of members.
- Validation by voting (when applicable): 75% of positive votes.
###### Major decision:
- Initial duration: 1 month.
- Postponement, if necessary: 2 weeks.
- Necessary views: 75% of members of a group (the person who initiated the decision can express their view).
- Validation by voting (when applicable): 90% of positive votes.
##### 6) Application
Then a member of a group can announce their decision as effective (and proceed with necessary actions such as releasing, merging, announcing, etc.). If certain actions are required, it's important that people commit themselves to performing them, since a decision without designated people is of little use
## Composition of groups
- Council : Bram, ju, ljf, Maniack, Moul, opi, theodore
- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi
- Apps : Bram, cyp, frju365, JimboJoe, Josue-T, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki
- Infra : Bram, Ju, Maniack C, Moul, opi
- Communication
- Com : Bram, Moul, korbak, ljf, opi, frju365
- Doc : Moul, Theodore
- Trans : Jean-Baptiste
- Distribution : Heyyounow
## Summary table of the number of views required for a decision
_Values are rounded (e.g. 5.4 => 5 and 5.5 => 6)._
The loss of membership of a group takes place by voluntary departure of the person, or following a vote of radiation for inactivity, non-respect of the charters or the values of the project, or abuse of the rights of administration.
| | **Minor** | **Standard** | **Major** |
|----------------------|---------|----------|---------|
| **Council** |
| Standard closure | 2 | 4 | 5 |
| Anticipated closure | 3* | 5 |
| Closure by voting | 5 | 5 | 6 |
| **Core Dev** |
| Standard closure | 2 | 3 | 5 |
| Anticipated closure | 3* | 4 |
| Closure by voting | 4 | 5 | 5 |
| **Apps** |
| Standard closure | 2 | 5 | 8 |
| Anticipated closure | 3* | 7 |
| Closure by voting | 7 | 8 | 9 |
| **Infra** |
| Standard closure | 2 | 3 | 4 |
| Anticipated closure | 3* | 3 |
| Closure by voting | 3 | 4 | 5 |
| **Communication -> Com** |
| Standard closure | 2 | 2 | 3 |
| Anticipated closure | 3* | 3 |
| Closure by voting | 3 | 3 | 4 |
| **Communication -> Doc** |
| Standard closure | 1 | 1 | Council |
| Anticipated closure | 2* | 2* |
| Closure by voting | Council | Council | Council |
| **Distribution** |
| Standard closure | 1 | Council | Council |
| Anticipated closure | 1 | Council |
| Closure by voting | 1 | Council | Council |
# Validation and integration of PR
\* of which 1 view can be external to the group
Due to the nature of the project, contributions are mainly made in the form of "pull requests" (PR) or "merge requests" (MR). The realization, the review, and the collective validation of PRs are important issues, since they are precisely what makes the project alive from a purely technical point of view.
For the translation group, the process needs to be adapted.
Behind each integration request can be hidden various human and technical issues among which stability (not breaking everything because of an unforeseen branching), security (not introducing flaws or malicious code), durability (limiting the *bus factor* and the technical debt), pragmatism ("good enough"), agreement with the spirit of the project (UX, ..), evolution on the short and long term. The review and validation process of a PR is also a complicated exercise insofar as it is time consuming, and can be a source of tension or frustration. One of the obstacles to the validation of a PR is also often linked to a feeling of lack of legitimacy in accepting the integration of a PR, or to the psychological impact of being the person who has accepted the integration of a PR.
For the documentation group, the number of views for an anticipated closure of a minor decision eat for the moment limited (there are only 2 people in the group). The other types of decision are taken by the Council.
A crucial issue in the organization of the project is therefore to find a set of rules and good practices that allow for a fluid, balanced operation, with validation as much as possible by consensus, and that distributes the responsibility to the collective rather than to individuals.
For the distribution group, since there's only Heyyounow at the moment, the Council will have the task of making Standard and Major decisions.
## Best practices and recommendations
## Administration group's rights
This part list administration rights for differents groups of YunoHost project:
- When a job has significant implications (or, for occasional contributors), it is strongly encouraged to discuss it in advance with the rest of the team to ensure that the imagined implementation fits with the spirit of the project and with the other work of the team.
- Correctly describe its RP and the problem it addresses (and if applicable, the technical details needed to test)
- Ensure the correction of problems reported by the automatic testing tools (CI)
(Warning, this is not decision rights here).
## Validation process
### Council
- No administration right. Authorizations are completed through the other groups membership,
- Forum: ["Conseil" group member](https://forum.yunohost.org/groups/Conseil).
This section details the process of validating the RPs in the different repositories of the project. The objective of this process is to achieve a "soft consensus".
### Core Dev
- GitHub: Devs team member inside YunoHost's organization (permission to push, merge…),
- Redmine: project member of [`YunoHost`](https://dev.yunohost.org/projects/yunohost) and [`Moulinette`](https://dev.yunohost.org/projects/moulinette),
- Continous integration: writting access to CI-Core,
- XMPP: ["dev"](xmpp:dev@conference.yunohost.org?join) channel moderator,
- Forum: ["Dev" group member](https://forum.yunohost.org/groups/Dev).
Contributors are individually and collectively responsible for gauging the importance of an RP to define the extent to which it should be lightly or thoroughly validated by other group members.
- The "micro" PR: it is a typographical correction, a correction for an obvious bug... These PR can be integrated by its author without explicit validation by another member of the group.
- Medium" PRs: these are maintenance operations (e.g. updating an application, minor cleaning/refactoring, adding a small feature, ...). It is usually better to get a validation from another member of the group.
- The "big project" PRs: these are new features or important refactorings, with major consequences for the future of the project or the app. It is then strongly advised to obtain a thorough validation by at least one other member of the group, and an agreement in principle from the other members.
Other contributors may freely take part in the review of an RP. The author of an RP may also request or remind other contributors that their RP is awaiting review. After a certain period of time, if it appears that no contributor has time or energy available to participate in the review of an RP, then it can still be merged by its author.
If a disagreement emerges during or after the validation of a PR, a cordial discussion should be held with the rest of the team in order to reach a consensus on the way forward. If no consensus is reached, a vote is held to make a decision, in which all regular contributors to the project can participate.
# Collective decision making
When Regular Contributors need to make a formal decision about the project ("resolution"), or to resolve a conflict after a consensus search has failed, any Regular Contributor can initiate a formal voting process. All regular contributors can take part in this vote.
# Appendix A. Group Administration Fees
This part lists the administration rights for the different groups of the YunoHost project.
N.B. these are not decision making rights, but access and modification rights on the different platforms used by the project.
Members of these groups agree to abide by [the project's system administration policy](adminsyscharter.md).
### Core
- GitHub: member of the [Devs team of the YunoHost organization](https://github.com/orgs/YunoHost/teams/devs)
- permission to create branches, merge PRs (respecting the rules stated above)
- Continuous integration: access rights to Gitlab to interact with the CI core?
- Forum: member of the [Dev group.](https://forum.yunohost.org/groups/Dev)
-Chatrooms: admin on the Dev chatroom
### Infra
- Servers: SSH access using SSH key on some (as needed) or every servers,
- GitHub: [Infra team member inside YunoHost's organization](https://github.com/orgs/YunoHost/teams/infra) (permission to push, merge…),
- Redmine: [Infra project member](https://dev.yunohost.org/projects/y-u-no-infra/),
- Forum, Weblate, Redmine, XMPP, CI: administrator,
- Forum: [Infra group member](https://forum.yunohost.org/groups/Infra).
### Apps
- GitHub: YunoHost-Apps [Owner](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner) (permission to push and merge on all repositories),
- Redmine: [Apps project member](https://dev.yunohost.org/projects/apps),
- GitHub: [Apps team member inside YunoHost's organization](https://github.com/orgs/YunoHost/teams/apps) (permission to push, merge…),
- Continous integration: access to [CI-Apps](https://ci-apps.yunohost.org),
- XMPP: [Apps channel moderator](https://im.yunohost.org/logs/apps),
- Forum: [Apps group member](https://forum.yunohost.org/groups/Apps).
- GitHub: (Owner) [of the YunoHost-Apps organization](https://github.com/orgs/YunoHost-Apps/people?utf8=%E2%9C%93&query=%20role%3Aowner)
- permission to create branches and merge PRs on all app repositories (respecting the rules stated above)
- Github: member of the [`Apps` team of the `YunoHost` organization](https://github.com/orgs/YunoHost/teams/apps)
- permission to create branches and merge PR on the catalog repository (apps), exampleynh, packagelinter, packagecheck, ... (respecting the rules stated above)
- Forum: Member of [`Apps` group](https://forum.yunohost.org/groups/Apps).
- Chatrooms: admin on the Apps chatroom
### Communication
- Forum: [Com group member](https://forum.yunohost.org/groups/Communication).
### Infra
- Servers: SSH access by key on some (as needed) or on all servers,
- GitHub: member of the [`Infra` team of the `YunoHost` organization](https://github.com/orgs/YunoHost/teams/infra),
- Forum, Weblate, XMPP, CI: administrator,
- Forum: member of the [`Infra` group](https://forum.yunohost.org/groups/Infra).
- Chatrooms: admin on the Dev and Infra chatroom
#### Documentation
- GitHub: [Doc team member of YunoHost's organization](https://github.com/orgs/YunoHost/teams/doc).
### Support, Doc, Communication, Translation
- GitHub: member of the [`Doc` team of the `YunoHost` organization](https://github.com/orgs/YunoHost/teams/doc).
- permission to create branches and merge PRs on the "doc" repository (respecting the rules stated above)
- Forum: moderator status, member of the [`Support & Doc` group](https://forum.yunohost.org/groups/SupportDoc), possibility to have the group badge visible next to the avatar.
- Diaspora*: access to the account [YunoHost](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
- Twitter: access to the [YunoHost](https://twitter.com/yunohost) account,
- Weblate: administrator on the [translation tool](https://translate.yunohost.org/projects/yunohost/).
- Chatrooms: admin on the Doc chatroom
#### Communication
- Diaspora*: [account access](https://framasphere.org/people/01868d20330c013459cf2a0000053625),
- Twitter: [account access](https://twitter.com/yunohost),
- Forum: [account access](https://forum.yunohost.org/users/yunohost/activity).
#### Translation
- Weblate: [translator tool admin](https://translate.yunohost.org/projects/yunohost/).
# Appendix B. Composition of the different groups 154
#### Mutual assistance (support)
- Forum: moderator status,
- XMPP: [`support` chanel moderator](xmpp:support@conference.yunohost.org?join).
Last updated on 2022-03-15
### Distribution
- GitHub: [YunoHost's organisation `Distrib` team member](https://github.com/orgs/YunoHost/teams/distribution),
- Information: image distribution (ISO…) should be done in collaboration with `Infra` group (and `Doc`),
- Publication: SFTP access can be set up,
- Forum: [`Distribution` group team member](https://forum.yunohost.org/groups/Distribution).
- **Core** : Aleks, Bram, Kayou, ljf, Tagadda, axolotle, tituspijean
- **Apps** : Ericg, Josue, Kayou, tituspijean, yalh76, frju365, Tagadda
- **Infra** : Aleks, Bram, Kayou, ljf, yalh76, tituspijean
- **Support/doc/comm/trad/bureaucracy** : Aleks, Ericg, ljf, tituspijean, Tagadda, JimboJoe, wbk
## Pending decisions for the groups
# Appendix C. Resolutions
### Council
- Should we elect Council members rather than co-opt them? There's a risk of it becoming a "political campaign"!
- Should special interest group membership be restricted to cooptation like for the Council?
- Proposal to change Council to Collegiate
- Migrate the project infrastructure server under YunoHost (with prepackaged apps like pad, dogs and mumble?)
- New system for documentation
- Improvement of documentation
- XMPP server migration
- Hosting of our Git forge
- Review the build system: stable <— testing <— branches
- Freeze nohost.me and abandoning services
### Core Dev Group
- How to manage pull requests?
- Each ticket gives rise to a branch and a ticket; you make a pull/merge request, the community verifies that it works, a decision is taken to integrate.
### Apps Group
- For community-based apps, issues are on GitHub as they should be, but discussions are on the forum
### Communication Group
- Bug report from the forum
- Cleanup of the forum to avoid noise
- Proposal to delete support chat
- How to make the forum a more active and central hub
- How to organise rights on the forum (if groups want to vote on the forum)
### Miscellaneous
- Request on the forum with notification to the Council members and to representatives of relevant special interest groups
- Vote over 2 weeks with a post on the forum
- Create 4 channels for Core Dev, Apps, Communication and Infrastructure
- A release should be validated by all 4 (or 5) interest groups
- Communication in French and English
- Directory or group contact for new people. Maybe just a directory to know who's who. https://yunohost.org/#/contribs to be completed. And to be highlighted.
- Proposal to leave YunoHost members auto-determine themselves -> How to manage access rights?
## Current means of communication
- Get-togethers at events
- Weekly Mumble meetings
- [Forum](https://forum.yunohost.org).
- [Bugtracker Redmine](https://dev.yunohost.org).
- Git Forge for code reviews: [YunoHost](https://github.com/YunoHost) [YunoHost-Apps](https://github.com/YunoHost-Apps).
- [XMPP chat rooms](https://yunohost.org/#/chat_rooms)
- On the fact that the commercial sale of services related to YunoHost, such as distribution, support, or outsourcing, is allowed.
- On good app packaging practices, in particular to respect the common practice defined in exampleynh rather than factoring
- Meeting dates
- On the criteria for integrating apps into the catalog