gwen.works
+103
GOVERNANCE.md
+103
GOVERNANCE.md
···
1
+
# Gouvernance de Churros
2
+
3
+
## Termes
4
+
5
+
### Majorité qualifiée
6
+
7
+
Vote dont plus des deux tiers du corps votant est favorable
8
+
9
+
### Fonctionnalité majeure
10
+
11
+
Fonctionnalité dont l'implémentation demande un travail conséquent, c'est-à-dire au moins l'un des points suivants:
12
+
13
+
- Un nouveau module dans l'API GraphQL
14
+
- Une modification du layout principal (`/` ou `/(app)`) de l'interface
15
+
- Un changement dans le Wiki du projet sur l'architecture du code
16
+
- Un bump major de la version du paquet de la base de données
17
+
18
+
Exemples:
19
+
20
+
- Provider OAuth2
21
+
- La Frappe
22
+
- UI v2
23
+
- Formulaires
24
+
- Shops
25
+
26
+
## Rôles
27
+
28
+
### Core Team (Owner)
29
+
30
+
Possède les droits suivants:
31
+
32
+
- Droit de veto sur une décision de merger ou non une MR d'un _maintainer_.
33
+
- Déployer une nouvelle version en prod.
34
+
- Push sur la branche déployée (par exemple `main`) directement.
35
+
- Changer les tags de priorité (sur une issue / MR) choisis par un·e _maintainer_
36
+
37
+
### Maintainers
38
+
39
+
Possède les droits suivants:
40
+
41
+
- Décision sur le fait d'intégrer ou pas une MR à main
42
+
- Changer les tags de priorité sur une issue / MR qu'iel n'a pas ouverte
43
+
44
+
### Developers
45
+
46
+
N'importe qui ayant un commit qui existe sur main et dont le droit n'a pas été explicitement révoqué par un membre de la _Core Team_
47
+
48
+
## Obtention de rôles
49
+
50
+
### Core Team
51
+
52
+
#### Bureau de net7
53
+
54
+
Le bureau en fonction de net7 doit nommer 3 personnes qui assurerons le rôle de Core Team. Il y a (minimum) 2 élections par année scolaire. Le choix est voté en réunion de bureau.
55
+
Au moins un membre de la Core Team doit être un membre du bureau de net7 afin d'assurer la bonne communication entre la _Core Team_ et le bureau de net7.
56
+
57
+
#### Destitution
58
+
59
+
- Tout _maintainer_ peut démarrer une procédure de destitution de la _Core Team_ actuel. La décision est prise par vote à _majorité qualifiée_ des _maintainers_ actuels.
60
+
- Le bureau de net7 peut decider a tout moment de réélire
61
+
62
+
### Maintainers
63
+
64
+
#### Candidatures
65
+
66
+
Tout _developer_ peut candidater au rôle de _maintainer_. L'accès à ce rôle lui est conféré par vote à _majorité qualifiée_ des _maintainers_ actuels.
67
+
68
+
#### Expiration
69
+
70
+
Tout _maintainer_ n'ayant pas effectué de commit depuis plus d'un an se voit retirer son rôle de _maintainer_. Iel peut ensuite candidater de nouveau.
71
+
72
+
#### Responsabilités
73
+
74
+
- Garder les dépenances à jour via une MR `chore(deps): upgrade dependencies` de temps en temps (une fois par mois)
75
+
- Garder à jour la documentation, autant externe (de l'API) qu'interne (wiki du projet et CONTRIBUTING.md)
76
+
77
+
## Modifications de ce fichier
78
+
79
+
Toute modification de ce fichier doit être proposée puis votée à _majorité qualifiée_ des _maintainers_ actuels (avec droit de veto par la _Core Team_).
80
+
81
+
La proposition de modification doit être faite sous forme d'une merge request, afin que l'ensemble des changements apportés soit clairement compréhensible.
82
+
83
+
## Fermeture de MRs
84
+
85
+
Fermer une MR revient à refuser l'implémentation actuelle dans son intégralité. Si l'on souhaite signaler que la feature n'est pas prioritaire et sera merge plus tard, il vaut mieux ajouter le tag `later` à la MR et informer lea _developer_ de la raison de la décision.
86
+
87
+
## Conversation “devteam”
88
+
89
+
Tout _developer_ est invité à rejoindre une conversation servant à la communication du projet. Cette conversation doit aussi être le lieu des votes. Ceci permet à tout _developer_ de participer à l'argumentation d'un vote et à observer les résultats de votes.
90
+
91
+
Les comptes rendus des réunions de bureau de net7 sont également partagés dans cette conversation, si ils mentionnent Churros. Le reste des informations peut être laissé tel quel ou censuré. En particulier, les resultats de vote d'élection de la _Core Team_ doivent figurer dans les comptes rendus.
92
+
93
+
## Travail en collaboration
94
+
95
+
Effectuer des réunions hebdomadaire si l'EDT le permet, afin de garder les troupes motivées et que la base de code évolue. Ces temps permettent de parler des problèmes, des priorités, de regarder les MRs et surtout de coder à plusieurs.
96
+
97
+
## Décisions majeures d'ajout ou de suppression de fonctionnalités
98
+
99
+
Avant de commencer une MR sur une fonctionnalité demandant un travail conséquent, ou la suppression d'une _fonctionnalité majeure_ existante, procéder à un vote des maintainers.
100
+
101
+
## Ne jamais oublier l'objectif initial de Churros
102
+
103
+
Détruire Vibly.