From ca472d3a866b5bfa3f2cf3fdfd537a76f5d8edd9 Mon Sep 17 00:00:00 2001 From: Moul Date: Tue, 18 Apr 2017 19:57:57 +0200 Subject: [PATCH 01/29] =?UTF-8?q?[fix]=20admin=20rights=20for=20Apps=20gro?= =?UTF-8?q?up:=C2=A0remove=20admin=20right=20on=20XMPP=20chat=20room.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 6268a7e7..ac2fb7c9 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -251,7 +251,7 @@ Cette partie liste les kits de droits d’administration pour les différents gr - 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 : admin et modérateur sur le [salon `Apps`](xmpp:apps@conference.yunohost.org?join), +- XMPP : modérateur sur le [salon `Apps`](xmpp:apps@conference.yunohost.org?join), - Forum : membre du [groupe `Apps`](https://forum.yunohost.org/groups/Apps). ### Communication From d7b7b24bc261806ac08c07c26b7bdf0b87a2e77a Mon Sep 17 00:00:00 2001 From: Jimmy Monin Date: Sun, 2 Jul 2017 18:15:59 +0200 Subject: [PATCH 02/29] Add cyp to the Apps Group --- yunohost_project_organization.md | 2 +- yunohost_project_organization_fr.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/yunohost_project_organization.md b/yunohost_project_organization.md index 4d27e2db..10745e14 100644 --- a/yunohost_project_organization.md +++ b/yunohost_project_organization.md @@ -171,7 +171,7 @@ Then a member of a group can announce their decision as effective (and proceed w - Distribution : Heyyounow - Council : Bram, ju, ljf, Maniack, Moul, opi, theodore - Core Dev : AlexAubin, Bram, Ju, ljf, Moul, opi -- Apps : Bram, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki +- Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki - Infra : Bram, Ju, Maniack C, Moul, opi - Communication - Com : Bram, Moul, korbak, ljf, opi diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index ac2fb7c9..1fd28765 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -172,7 +172,7 @@ Alors un membre du groupe peut annoncer la décision comme effective (et procéd - Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore. - Core Dev : AlexAubin, Bram, Ju, ljf, Moul, opi -- Apps : Bram, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki +- Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki - Infra : Bram, Ju, Maniack C, Moul, opi - Communication - Com : Bram, Moul, korbak, ljf, opi From 4b7146b2328f4df8b56eec7ef5a8e8bacb72b340 Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Wed, 5 Jul 2017 19:57:11 +0200 Subject: [PATCH 03/29] First draft for new review process --- yunohost_project_organization_fr.md | 88 +++++++++++++++++++++++++++++ 1 file changed, 88 insertions(+) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 1fd28765..9a0d1d94 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -101,6 +101,94 @@ Les décisions à prendre peuvent être de deux ordres : Si un consensus sur une décision à prendre n'est pas trouvée au sein d'un groupe, ce dernier devra 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. + +### Processus de validation des demandes d'intégration (pull requests) + +#### 1. Proposition + +N'importe quel contributeur peut proposer une demande d'intégration (pull request, abrégée PR dans la suite) dans les divers dépôts liés au projet YunoHost (core, apps, infra, ...). + +La demande d'intégration doit obligatoirement décrire les points suivants : +- problème auquel réponds la PR +- solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR +- comment tester la PR (sauf si le test est réellement trivial) +- status actuel de la PR (ex. : non terminé, en attente de revues, ...) + +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 design (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 aux autres contributeurs d'émettre des avis sur la PR pendant ce temps. + +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, ...) + + +#### 2. Revue et validation collective + +(Cette section ne s'applique pas aux PR "micro" qui peuvent être validée directement par leur auteur.) + +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. + +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. 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, ...). + + +| | **Mineure** | **Standard** | **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 | + +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). + + +#### 3. Intégration (merge) d'une PR + +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". + +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 processus d'intégration est interrompu et retourne à la partie 2). + +À 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. + + +#### Cas particuliers + +Plusieurs cas particuliers peuvent se présenter et dont la résolution est décrite ci-après. + +##### Refus d'une PR + +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 + + +##### Changement d'auteur d'une PR + +Si l'auteur d'une PR devient indisponible, manque de temps ou souhaite se consacrer à d'autres travaux, un autre contributeur peut prendre la main en tant qu'auteur de la PR, après concertation informelle avec le groupe. Dans ce cas, il assure la gestion de la PR (e.g. développement, résolution des problèmes soulevés, ...), mais ne compte plus dans les quotas de validation de la PR. + + +##### 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 +- deux semaines se sont écoulées depuis que 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 "standard" n'ont pas été remplis + +Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite engager cette prodécure. À 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. + + + + #### Le processus de prise de décision en détail ##### 1) Initiation d'une décision à prendre From 664dfe6604ea7955bc384138c80c3373a9ed1fa7 Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Wed, 5 Jul 2017 23:15:59 +0200 Subject: [PATCH 04/29] Misc small fixes --- yunohost_project_organization_fr.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 9a0d1d94..fe2e9216 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -116,7 +116,7 @@ La demande d'intégration doit obligatoirement décrire les points suivants : 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 design (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 ; +- 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, ...) @@ -138,7 +138,7 @@ Une fois la PR déclarée comme terminée, les contributeurs sont invités à do 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. 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, ...). -| | **Mineure** | **Standard** | **Majeure** | +| | **Mineure** | **Moyenne** | **Majeure** | |-----------------------------------|-------------|--------------|-------------| | **Accord sur le principe** | 2 | 3 | 4 | | **Relecture en diagonale** | 1 | 2 | 3 | @@ -182,7 +182,7 @@ En cas de manque de relecteurs, l'auteur d'une PR peut déclencher une procédur - il s'agit d'une PR mineure ou moyenne - deux semaines se sont écoulées depuis que 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 "standard" n'ont pas été remplis +- les quotas de relecture "standards" n'ont pas été remplis Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite engager cette prodécure. À 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. @@ -226,7 +226,7 @@ Tout le monde peut changer de positions à n'importe quel moment, mais il est de - que des avis positifs - que des refus - sans avis (s'en remet aux autres) - - Pour une décison mineure ou moyenne/standard, si le quota de réponse est atteint à la durée minimale et que le consensus est obtenu. + - Pour une décison mineure ou moyenne, si le quota de réponse est atteint à la durée minimale et que le consensus est obtenu. - Le quota de réponse correspond aux avis nécessaires, détaillé ci-après dans les types de décisions. Le pourcentage est rapporté au nombre d'actifs dans le groupe concerné. La gestion des actif et inactif dans le groupe est à la charge du coordinateur et du suppléant qui doivent maintenir à jour la liste des membres au minimum à chaque décision du groupe. (Un inactif qui se manifeste lors d'une décision redevient automatiquement actif.) - s'il n'est pas possible d'avoir assez de monde (vacances, plus assez de membres du groupe pouvant avoir un avis) il est possible pour le groupe de demander la clôture même si le quota d'avis n'est pas atteint, il y a alors un nouveau décalage de la date et si cette nouvelle date est franchie, la proposition est clôturée selon les avis donnés. From 69ee916fbc298f93c2ce3bbd0eb8a758585254ba Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 15:49:33 +0200 Subject: [PATCH 05/29] Removing the old decision process --- yunohost_project_organization_fr.md | 111 ---------------------------- 1 file changed, 111 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index fe2e9216..6f39acf9 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -187,75 +187,6 @@ En cas de manque de relecteurs, l'auteur d'une PR peut déclencher une procédur Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite engager cette prodécure. À 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. - - -#### Le processus de prise de décision en détail - -##### 1) Initiation d'une décision à prendre - - peut-être initiée par n'importe qui suivant les mediums définis au sein de chacun des groupes (exemple : ouvrir une PR déclenche automatiquement ce processus) - - forcément publique à l'exception de situations bien définies (bug relatif à la sécurité critique ou vote sur les personnes) - - une date de clôture est automatiquement définie par type de proposition. La définition de la date remplie plusieurs fonctions : - - pouvoir laisser le temps à tout le monde de s'exprimer et ne pas prendre la décision trop vite - - maintenir un rythme car si le quota des réponses est rempli avant le temps imparti, il n'y a pas besoin d'attendre l'avis de tout les membres du groupe - - le quota est à évaluer en fonction des personnes inscrites au groupe (ou au Conseil selon la situation) qui ont manifesté leurs souhaits d'être considéré comme votant régulier => exemple kload peut vouloir donner son avis ponctuellement, mais à priori il ne souhaitera pas être considéré comme membre votant actif du Conseil - - pouvoir être repoussable sur simple demande d'une des personnes du groupe. Et seulement du groupe, pas tous les contributeurs. - -##### 2) Ouverture de la discussion, plusieurs réponses possibles : -Tout le monde peut changer de positions à n'importe quel moment, mais il est de bon ton de laisser au groupe le temps de réagir si cela est nécessaire (pas passer de positif à négatif puis rejeter la proposition 3 min après par exemple.) - -- réponses dites "simple" - - "je suis d'accord" -> vaut pour un avis positif - - "ça me semble bon, mais je préfère m'en remettre aux autres" -> si jamais il n'y a que des avis comme cela (ou le suivant) et au moins un avis positif et que la date est passé, la proposition est acceptée - - "pas d'avis" / "je ne suis pas en position de donner un avis pertinent (exemple: je sais pas coder en X)" -- réponses délayantes/différées - - demande de précisions, dans ce cas la décision est suspendue -- refus: tout refus doit être argumenté et justifié - -##### 3) Suspension/Repoussement - - tant qu'il n'y a pas de réponse, la décision est suspendue, au moment de la réponse, la date de clôture est automatiquement repoussée (si besoin) (pour une durée, à définir, moins longue que la première fois) - - situation où il y a des avis positifs et négatifs ou situation où il y a un choix à faire entre plusieurs propositions - -##### 4) Demande de modifications - - mais il se peut qu'il y ait discussion autour de ces modifications, si c'est le cas, cela devient une nouvelle décision à adjoindre à la liste des décisions à prendre et le processus s'y applique alors (et cela repousse la date) - - dans le cas contraire, un membre du groupe peut demander à ce que l'on fasse un vote qui portera sur la liste des possibilités qui font conflits + "ce vote est mal formulé, reformulons le" - - s'il n'y a pas assez de monde d'accord, la date est repoussée et un rappel doit être envoyé - - si le résultat est vraiment serré, le groupe est invité à rediscuter de la question si elle est importante, car cela pourrait être source de division et de tension à l'avenir - -##### 5) Clôture - - si le groupe est unanime dans sa décision - - que des avis positifs - - que des refus - - sans avis (s'en remet aux autres) - - Pour une décison mineure ou moyenne, si le quota de réponse est atteint à la durée minimale et que le consensus est obtenu. - - Le quota de réponse correspond aux avis nécessaires, détaillé ci-après dans les types de décisions. Le pourcentage est rapporté au nombre d'actifs dans le groupe concerné. La gestion des actif et inactif dans le groupe est à la charge du coordinateur et du suppléant qui doivent maintenir à jour la liste des membres au minimum à chaque décision du groupe. (Un inactif qui se manifeste lors d'une décision redevient automatiquement actif.) - - s'il n'est pas possible d'avoir assez de monde (vacances, plus assez de membres du groupe pouvant avoir un avis) il est possible pour le groupe de demander la clôture même si le quota d'avis n'est pas atteint, il y a alors un nouveau décalage de la date et si cette nouvelle date est franchie, la proposition est clôturée selon les avis donnés. - -###### Micro décision: -- Décision prise et appliquée par un seul membre sans délai. Ce type de décision doit impérativement pouvoir être réversible, et peut être remise en question par n'importe quel membre du groupe. - -###### Décision Mineure: -- Durée initiale: 1 semaine. -- Durée minimale: 3 jours. -- Décalage, si nécessaire: 3 jours. -- Avis nécessaires: 2 membres du groupe (celui qui a initié cette prise de décision peux donner son avis). 3, dont 2 membres du groupe pour anticiper. -- Validation par vote (le cas échéant): 66% de votes positifs. - -###### Décision Standard/Moyenne: -- Durée initiale: 2 semaines. -- Durée minimale: 1 semaine. -- Décalage, si nécessaire: 1 semaine. -- Avis nécessaires: 50% des membres du groupe (celui qui a initié cette prise de décision peux donner son avis). 66% des membres du groupe pour anticiper. -- Validation par vote (le cas échéant): 75% de votes positifs. - -###### Décision Majeure : -- Durée initiale: 1 mois. -- Décalage, si nécessaire: 2 semaines. -- Avis nécessaires: 75% des membres du groupe (celui qui a initié cette prise de décision peux donner son avis). -- Validation par vote (le cas échéant): 90% de votes positifs. - -##### 6) Application -Alors un membre du groupe peut annoncer la décision comme effective (et procéder aux actions nécessaires comme releaser, merger, annonce, autre ...). Il est important que s'il y a besoin de certaines actions, des personnes se soient engagées à les faire, une décision sans désigner est moyennement utile - ## Composition des groupes - Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore. @@ -268,48 +199,6 @@ Alors un membre du groupe peut annoncer la décision comme effective (et procéd - Trad : Jean-Baptiste - Distribution : Heyyounow -## Tableau récapitulatif du nombre d'avis nécéssaire pour la prise de décision - -_Les valeurs sont arrondies (exemple: 5,4 => 5 et 5,5 => 6)._ - -| | **Mineure** | **Standard** | **Majeure** | -|----------------------|---------|----------|---------| -| **Conseil** | -| Clôture classique | 2 | 4 | 5 | -| Clôture anticipée | 3* | 5 | -| Clôture par vote | 5 | 5 | 6 | -| **Core Dev** | -| Clôture classique | 2 | 3 | 5 | -| Clôture anticipée | 3* | 4 | -| Clôture par vote | 4 | 5 | 5 | -| **Apps** | -| Clôture classique | 2 | 5 | 8 | -| Clôture anticipée | 3* | 7 | -| Clôture par vote | 7 | 8 | 9 | -| **Infra** | -| Clôture classique | 2 | 3 | 4 | -| Clôture anticipée | 3* | 3 | -| Clôture par vote | 3 | 4 | 5 | -| **Communication -> Com** | -| Clôture classique | 2 | 2 | 3 | -| Clôture anticipée | 3* | 3 | -| Clôture par vote | 3 | 3 | 4 | -| **Communication -> Doc** | -| Clôture classique | 1 | 1 | Conseil | -| Clôture anticipée | 2* | 2* | -| Clôture par vote | Conseil | Conseil | Conseil | -| **Distribution** | -| Clôture classique | 1 | Conseil | Conseil | -| Clôture anticipée | 1 | Conseil | -| Clôture par vote | 1 | Conseil | Conseil | - -\* dont 1 avis qui peut être externe au groupe - -Pour la traduction, le processus reste à adapter. - -Pour la doc, le nombre d'avis pour la cloture anticipée d'une décision mineure est pour le moment réduit (vu qu'il n'y a que 2 personnes dans le groupe). Les autres types de décisions sont prises par le conseil. - -Pour le groupe distribution, étant donné qu'il n'y a pour l'instant que Heyyounow, le Conseil sera sollicité pour les décisions Standard ou Majeure. ## Droits d’administration afférents aux groupes Cette partie liste les kits de droits d’administration pour les différents groupes du projet YunoHost : From 41962f53f0c6bcf2494d9a9c6ead05d439a30409 Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 15:59:24 +0200 Subject: [PATCH 06/29] Adding a 1 week delay w.r.t. to PR being ready before merging --- yunohost_project_organization_fr.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 6f39acf9..70cacf58 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -153,11 +153,10 @@ Si l'auteur ne fait pas parti du groupe concerné par la PR, tous ces quotas son 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". -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 processus d'intégration est interrompu et retourne à la partie 2). +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 processus d'intégration est interrompu et retourne à la partie 2). Pour les PRs moyennes et majeures, cette 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. À 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. - #### Cas particuliers Plusieurs cas particuliers peuvent se présenter et dont la résolution est décrite ci-après. From 5220184449177f1bf26ba5d24fdc101c3ca46a16 Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 16:52:58 +0200 Subject: [PATCH 07/29] Demande d'integration/Integration ---> Pull Request/Merge --- yunohost_project_organization_fr.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 70cacf58..2d7e1ce6 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -102,13 +102,13 @@ Les décisions à prendre peuvent être de deux ordres : Si un consensus sur une décision à prendre n'est pas trouvée au sein d'un groupe, ce dernier devra 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. -### Processus de validation des demandes d'intégration (pull requests) +### Processus de validation des pull requests #### 1. Proposition -N'importe quel contributeur peut proposer une demande d'intégration (pull request, abrégée PR dans la suite) dans les divers dépôts liés au projet YunoHost (core, apps, infra, ...). +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, ...). -La demande d'intégration doit obligatoirement décrire les points suivants : +La proposition doit obligatoirement décrire les points suivants : - problème auquel réponds la PR - solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR - comment tester la PR (sauf si le test est réellement trivial) @@ -149,11 +149,11 @@ Les relecteurs rapportent également le degré de relecture et de tests effectu 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). -#### 3. Intégration (merge) d'une PR +#### 3. Merge d'une pull request 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". -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 processus d'intégration est interrompu et retourne à la partie 2). Pour les PRs moyennes et majeures, cette 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. +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. À 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. From 4ee87f0ed547e9f60e8f7aeadf90e232a04a2ed7 Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 16:55:07 +0200 Subject: [PATCH 08/29] Trying to generalize stuff to describe in a PR --- yunohost_project_organization_fr.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 2d7e1ce6..693dafac 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -111,8 +111,8 @@ N'importe quel contributeur peut proposer une pull request (abrégée PR dans la La proposition doit obligatoirement décrire les points suivants : - problème auquel réponds la PR - solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR -- comment tester la PR (sauf si le test est réellement trivial) -- status actuel de la PR (ex. : non terminé, en attente de revues, ...) +- comment tester la PR (sauf si s'il n'y a rien a tester) +- status actuel de la PR (ex. : non terminé, en attente de revues, choix techniques à faire...) 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) ; From 2a4fc00b67f93191e9b96a703b237f5374a5b5ce Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 17:06:00 +0200 Subject: [PATCH 09/29] =?UTF-8?q?D=C3=A9lai=20de=20une=20semaine=20depuis?= =?UTF-8?q?=20le=20dernier=20commit/comment=20pour=20la=20validation=20all?= =?UTF-8?q?=C3=A9g=C3=A9e?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- yunohost_project_organization_fr.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 693dafac..16d02002 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -179,9 +179,10 @@ Si l'auteur d'une PR devient indisponible, manque de temps ou souhaite se consac 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 -- deux semaines se sont écoulées depuis que la PR a été déclarée comme prête +- 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. À 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. From 99aab8e10d014bdbb9b012eea2f2593b2b516c3a Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 10 Jul 2017 17:20:07 +0200 Subject: [PATCH 10/29] Tentative de clarification qu'un reviewer peut cocher plusieurs cases --- yunohost_project_organization_fr.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 16d02002..34fa93a4 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -135,10 +135,10 @@ Il appartient aussi à l'auteur de la PR de juger de son importance. (Ce jugemen 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. -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. 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, ...). +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, ...). -| | **Mineure** | **Moyenne** | **Majeure** | +| | **Mineure** | **Moyenne** | **Majeure** | |-----------------------------------|-------------|--------------|-------------| | **Accord sur le principe** | 2 | 3 | 4 | | **Relecture en diagonale** | 1 | 2 | 3 | From f2d76ae0e3ccc0dbdad0ce67d451eb6c63a44640 Mon Sep 17 00:00:00 2001 From: Laurent Peuch Date: Sat, 22 Jul 2017 19:20:25 +0200 Subject: [PATCH 11/29] remove duplicated line --- yunohost_project_organization.md | 1 - 1 file changed, 1 deletion(-) diff --git a/yunohost_project_organization.md b/yunohost_project_organization.md index 10745e14..5dbb5d94 100644 --- a/yunohost_project_organization.md +++ b/yunohost_project_organization.md @@ -168,7 +168,6 @@ Then a member of a group can announce their decision as effective (and proceed w ## Composition of groups -- Distribution : Heyyounow - Council : Bram, ju, ljf, Maniack, Moul, opi, theodore - Core Dev : AlexAubin, Bram, Ju, ljf, Moul, opi - Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki From 08592460096412e26ffa7fbfca75823eb11042ed Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 24 Jul 2017 18:45:24 +0200 Subject: [PATCH 12/29] =?UTF-8?q?R=C3=A9=C3=A9criture=20du=20d=C3=A9but=20?= =?UTF-8?q?de=20la=20section=20:=20procedure=20'recommand=C3=A9e'=20et=20n?= =?UTF-8?q?on=20imp=C3=A9rative?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- yunohost_project_organization_fr.md | 14 ++++---------- 1 file changed, 4 insertions(+), 10 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 34fa93a4..eee12fb5 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -92,18 +92,12 @@ Le choix d'un outil de communication est laissé au Conseil, ses décisions doiv 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...). -### Un processus de prises de décision basé sur un consensus mou - -Les décisions à prendre peuvent être de deux ordres : - -1. pour un groupe (par "exemple merger une PR" serait affecté au groupe Dev tandis que "poster un tweet" serait de la responsabilité du groupe Communication) -2. pour l'ensemble du projet (par exemple décider d'une release avec des nouvelles fonctionnalités) - -Si un consensus sur une décision à prendre n'est pas trouvée au sein d'un groupe, ce dernier devra 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. - - ### Processus de validation des pull requests +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 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. + +Si un consensus ne peut être trouvé au sein d'un gorupe 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. + #### 1. Proposition 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, ...). From af42f2a000e393f6210f3287d50da81e0664bccc Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 24 Jul 2017 19:00:49 +0200 Subject: [PATCH 13/29] =?UTF-8?q?Le=20groupe=20peut=20fournir=20un=20templ?= =?UTF-8?q?ate=20des=20infos=20pour=20d=C3=A9crire=20une=20PR?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- yunohost_project_organization_fr.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index eee12fb5..bd9ca9e0 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -102,11 +102,13 @@ Si un consensus ne peut être trouvé au sein d'un gorupe en suivant le processu 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, ...). -La proposition doit obligatoirement décrire les points suivants : -- problème auquel réponds la PR -- solution, stratégie, résumé des changements, et/ou choix techniques utilisés dans la PR -- comment tester la PR (sauf si s'il n'y a rien a tester) +L'auteur est vivement encouragé à décrire sa proposition 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 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) ; @@ -131,7 +133,6 @@ Une fois la PR déclarée comme terminée, les contributeurs sont invités à do 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, ...). - | | **Mineure** | **Moyenne** | **Majeure** | |-----------------------------------|-------------|--------------|-------------| | **Accord sur le principe** | 2 | 3 | 4 | From 4449fa32a6a2d26bfe2cdbc4789be64fc7ca03ae Mon Sep 17 00:00:00 2001 From: Alexandre Aubin Date: Mon, 24 Jul 2017 19:06:53 +0200 Subject: [PATCH 14/29] Typo --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index bd9ca9e0..8abbd96b 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -94,7 +94,7 @@ Pour participer aux votes du Conseil, il faut avoir contribué au projet et avoi ### Processus de validation des pull requests -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 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. +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 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. Si un consensus ne peut être trouvé au sein d'un gorupe 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. From 71891fe721238dc56a2cf7e7db22a143d494ca45 Mon Sep 17 00:00:00 2001 From: Maniack Crudelis Date: Mon, 31 Jul 2017 11:24:14 +0200 Subject: [PATCH 15/29] PR model for apps group --- apps_group_PR_model.md | 51 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) create mode 100644 apps_group_PR_model.md diff --git a/apps_group_PR_model.md b/apps_group_PR_model.md new file mode 100644 index 00000000..6b10e01b --- /dev/null +++ b/apps_group_PR_model.md @@ -0,0 +1,51 @@ +## Problem +- *Description of why you made this PR* + +## Solution +- *And how you fix that* + +## PR Status +*Obviously, you should really check these affirmations* +Work finished. Package_check, basic tests and upgrade from last version OK. +Could be reviewed and tested. + +## Validation +--- +*Minor decision* +- [ ] **Upgrade previous version** : +- [ ] **Code review** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **CI succeeded** : +When the PR is mark as ready to merge, you have to wait for 3 days before really merge it. + +*Medium decision* +- [ ] **Complete test** : +- [ ] **Upgrade previous version** : +- [ ] **Code review** : +- [ ] **Code review** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **CI succeeded** : +- [ ] **CI succeeded** : +One public package check log is enough instead of two checks. +When the PR is mark as ready to merge, you have to wait for 7 days before really merge it. + +*Major decision* +- [ ] **Complete test** : +- [ ] **Complete test** : +- [ ] **Upgrade previous version** : +- [ ] **Upgrade previous version** : +- [ ] **Code review** : +- [ ] **Code review** : +- [ ] **Code review** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **Approval (LGTM)** : +- [ ] **CI succeeded** : +- [ ] **CI succeeded** : +- [ ] **CI succeeded** : +One public package check log is enough instead of three checks. +When the PR is mark as ready to merge, you have to wait for 7 days before really merge it. From 24508ef04190bcd418d29f143886df471fdde421 Mon Sep 17 00:00:00 2001 From: Julien Vaubourg Date: Sun, 27 Aug 2017 19:21:32 +0200 Subject: [PATCH 16/29] =?UTF-8?q?Pallier=20quelque=20chose=20:=20transitif?= =?UTF-8?q?=20direct=20sans=20pr=C3=A9position=20(#56)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 1fd28765..bb817201 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -3,7 +3,7 @@ ## 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. +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. ## Définition de YunoHost From 91578a0d42aefcf777deee876de45858c1938c3b Mon Sep 17 00:00:00 2001 From: Moul Date: Mon, 18 Sep 2017 13:33:09 +0200 Subject: [PATCH 17/29] Add JimboJoe to dev team. --- yunohost_project_organization.md | 2 +- yunohost_project_organization_fr.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/yunohost_project_organization.md b/yunohost_project_organization.md index 5dbb5d94..e6c25788 100644 --- a/yunohost_project_organization.md +++ b/yunohost_project_organization.md @@ -169,7 +169,7 @@ Then a member of a group can announce their decision as effective (and proceed w ## Composition of groups - Council : Bram, ju, ljf, Maniack, Moul, opi, theodore -- Core Dev : AlexAubin, Bram, Ju, ljf, Moul, opi +- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi - Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki - Infra : Bram, Ju, Maniack C, Moul, opi - Communication diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index bb817201..61cf2331 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -171,7 +171,7 @@ Alors un membre du groupe peut annoncer la décision comme effective (et procéd ## Composition des groupes - Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore. -- Core Dev : AlexAubin, Bram, Ju, ljf, Moul, opi +- Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi - Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki - Infra : Bram, Ju, Maniack C, Moul, opi - Communication From acb75a22d89cca1151bb743179bc82435efe984a Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:11:43 +0200 Subject: [PATCH 18/29] [fix] Missing words --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 8abbd96b..5415a3ea 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -102,7 +102,7 @@ Si un consensus ne peut être trouvé au sein d'un gorupe en suivant le processu 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, ...). -L'auteur est vivement encouragé à décrire sa proposition des informations +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...) From 6d222cf5e0d02bcf8d5f4f43856dae2e6173bc8e Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:13:44 +0200 Subject: [PATCH 19/29] [fix] Typo --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 5415a3ea..6b6c8190 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -96,7 +96,7 @@ Pour participer aux votes du Conseil, il faut avoir contribué au projet et avoi 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 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. -Si un consensus ne peut être trouvé au sein d'un gorupe 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. +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. #### 1. Proposition From 4a87ec02126654a1ec50dac6b4a64f79b5639cdf Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:16:20 +0200 Subject: [PATCH 20/29] [fix] Wording --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 6b6c8190..70d22c3f 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -116,7 +116,7 @@ L'auteur est vivement encouragé à respecter les bonnes pratiques suivantes : - 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 aux autres contributeurs d'émettre des avis sur la PR pendant ce temps. +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. 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. From ebba33723429069624c91ed4e180cf1f97bfb628 Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:17:30 +0200 Subject: [PATCH 21/29] [fix] Missing words --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 70d22c3f..d6808834 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -94,7 +94,7 @@ Pour participer aux votes du Conseil, il faut avoir contribué au projet et avoi ### Processus de validation des pull requests -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 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. +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. 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. From 36be0d11273f66d1660d16600e242f17a529fb6b Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:18:45 +0200 Subject: [PATCH 22/29] [fix] Typo --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index d6808834..2f898e2d 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -127,7 +127,7 @@ Il appartient aussi à l'auteur de la PR de juger de son importance. (Ce jugemen #### 2. Revue et validation collective -(Cette section ne s'applique pas aux PR "micro" qui peuvent être validée directement par leur auteur.) +(Cette section ne s'applique pas aux PR "micro" qui peuvent être validées directement par leur auteur.) 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. From 5f6b921c894f827224f135a5011c76c4a003d681 Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:54:44 +0200 Subject: [PATCH 23/29] [enh] More info about PR with several authors --- yunohost_project_organization_fr.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 2f898e2d..3edbe9bf 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -164,9 +164,13 @@ Une PR peut être refusée et clôturée par n'importe quel membre du groupe con - aucun autre membre du groupe n'a manifesté son accord avec le principe de la PR -##### Changement d'auteur d'une PR +##### Co-création -Si l'auteur d'une PR devient indisponible, manque de temps ou souhaite se consacrer à d'autres travaux, un autre contributeur peut prendre la main en tant qu'auteur de la PR, après concertation informelle avec le groupe. Dans ce cas, il assure la gestion de la PR (e.g. développement, résolution des problèmes soulevés, ...), mais ne compte plus dans les quotas de validation de la PR. +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 From b91f0fea31be02735ea2a7b2c6c781f0f45450c2 Mon Sep 17 00:00:00 2001 From: "ljf (zamentur)" Date: Tue, 3 Oct 2017 15:57:13 +0200 Subject: [PATCH 24/29] [enh] Add obligation about light validation --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 3edbe9bf..cc19df93 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -183,7 +183,7 @@ En cas de manque de relecteurs, l'auteur d'une PR peut déclencher une procédur - 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. À 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. +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 From 7d039de176b8d3ca84832033262b77396d7f52cc Mon Sep 17 00:00:00 2001 From: Maniack Crudelis Date: Mon, 20 Nov 2017 00:30:03 +0100 Subject: [PATCH 25/29] Replace CI by a badge This badge is linked to the new CI dev. This CI makes automatic tests for each branches of official apps. --- apps_group_PR_model.md | 11 +++-------- 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/apps_group_PR_model.md b/apps_group_PR_model.md index 6b10e01b..82c5e940 100644 --- a/apps_group_PR_model.md +++ b/apps_group_PR_model.md @@ -16,7 +16,7 @@ Could be reviewed and tested. - [ ] **Code review** : - [ ] **Approval (LGTM)** : - [ ] **Approval (LGTM)** : -- [ ] **CI succeeded** : +- [ ] **CI succeeded** : [![Build Status](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/badge/icon)](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/) *Please replace APP and BRANCH in this link* When the PR is mark as ready to merge, you have to wait for 3 days before really merge it. *Medium decision* @@ -27,9 +27,7 @@ When the PR is mark as ready to merge, you have to wait for 3 days before really - [ ] **Approval (LGTM)** : - [ ] **Approval (LGTM)** : - [ ] **Approval (LGTM)** : -- [ ] **CI succeeded** : -- [ ] **CI succeeded** : -One public package check log is enough instead of two checks. +- [ ] **CI succeeded** : [![Build Status](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/badge/icon)](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/) *Please replace APP and BRANCH in this link* When the PR is mark as ready to merge, you have to wait for 7 days before really merge it. *Major decision* @@ -44,8 +42,5 @@ When the PR is mark as ready to merge, you have to wait for 7 days before really - [ ] **Approval (LGTM)** : - [ ] **Approval (LGTM)** : - [ ] **Approval (LGTM)** : -- [ ] **CI succeeded** : -- [ ] **CI succeeded** : -- [ ] **CI succeeded** : -One public package check log is enough instead of three checks. +- [ ] **CI succeeded** : [![Build Status](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/badge/icon)](https://ci-apps-dev.yunohost.org/jenkins/job/APP_ynh%20BRANCH%20(Official)/) *Please replace APP and BRANCH in this link* When the PR is mark as ready to merge, you have to wait for 7 days before really merge it. From ed7d8a466fab9a03af4b41e2dca771072d1aef4a Mon Sep 17 00:00:00 2001 From: Maniack Crudelis Date: Mon, 12 Mar 2018 22:24:12 +0100 Subject: [PATCH 26/29] Add Josue to apps group --- yunohost_project_organization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization.md b/yunohost_project_organization.md index e6c25788..a60cf4d1 100644 --- a/yunohost_project_organization.md +++ b/yunohost_project_organization.md @@ -170,7 +170,7 @@ Then a member of a group can announce their decision as effective (and proceed w - Council : Bram, ju, ljf, Maniack, Moul, opi, theodore - Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi -- Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki +- 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 From 8f14814a8a517d1ac6ff6a01edbcedc023158e70 Mon Sep 17 00:00:00 2001 From: Maniack Crudelis Date: Mon, 12 Mar 2018 22:26:23 +0100 Subject: [PATCH 27/29] Add Josue to apps group --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index c12ae02c..246a6ad6 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -190,7 +190,7 @@ Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite e - Conseil : Bram, ju, ljf, Maniack, Moul, opi, theodore. - Core Dev : AlexAubin, Bram, JimboJoe, Ju, ljf, Moul, opi -- Apps : Bram, cyp, frju365, JimboJoe, Ju, ljf, Maniack C, Maxime, Moul, Scith, Tostaki +- 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 From f1c80e57ca08fcf45ccced7b5a67e2ac9ef4341a Mon Sep 17 00:00:00 2001 From: frju365 Date: Sat, 31 Mar 2018 17:11:05 +0200 Subject: [PATCH 28/29] [add] me to the doc/com group --- yunohost_project_organization.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization.md b/yunohost_project_organization.md index a60cf4d1..4fdfe208 100644 --- a/yunohost_project_organization.md +++ b/yunohost_project_organization.md @@ -173,7 +173,7 @@ Then a member of a group can announce their decision as effective (and proceed w - 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 + - Com : Bram, Moul, korbak, ljf, opi, frju365 - Doc : Moul, Theodore - Trans : Jean-Baptiste - Distribution : Heyyounow From 38ae1d0d4d9fd3364b9c812c31a0f9e51958f5b7 Mon Sep 17 00:00:00 2001 From: frju365 Date: Sat, 31 Mar 2018 17:11:40 +0200 Subject: [PATCH 29/29] [add] me to the com/doc group --- yunohost_project_organization_fr.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/yunohost_project_organization_fr.md b/yunohost_project_organization_fr.md index 246a6ad6..d0747ecb 100644 --- a/yunohost_project_organization_fr.md +++ b/yunohost_project_organization_fr.md @@ -193,7 +193,7 @@ Dans ce cas, l'auteur annonce sur le fil de discussion de la PR qu'il souhaite e - 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 + - Com : Bram, Moul, korbak, ljf, opi, frju365 - Doc : Moul, Theodore - Trad : Jean-Baptiste - Distribution : Heyyounow