Définition de YunoHost
Objectifs
Selon le site web : « 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. »
YunoHost est avant tout un logiciel, il n’a pas vocation à héberger des services auxiliaires estampillés sous le même nom (support payant, dns, vpn, hébergement). La fourniture de services devrait être laissée à d’autres structures gravitant autour du logiciel, qu’elles soient des entreprises ou des associations. Cela afin de concentrer l’activité de Yunohost sur la qualité du logiciel. Ce postulat pose la question des services peu gourmand en ressources comme nohost.me, ip.yunohost.org, ports.yunohost.org ou encore la liste des apps qui sont nécéssaires pour faire fonctionner pleinement une instance YunoHost. A termes ces services devraient pouvoir être proposés par des tiers de façon que l’utilisateur puisse avoir le choix d’être indépendant des serveurs YunoHost.
Valeurs
Un logiciel libre et communautaire
Par rapport à d’autres initiatives, (InternetCube, Sandstorm, Freedombox, cozy, ArkOS, serveur NAS (synology), kodi) YunoHost se distingue en étant :
- un logiciel sous licence libre
- entièrement communautaire
- reposant sur des applications libres existantes (roundcube, baikal, etc.)
Que chacun peut s’approprier
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, a amené une partie des contributeurs de YunoHost à créer la Brique Internet / InternetCube 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.
Explication sur le mode de gouvernance de YunoHost
Une structure ouverte, organisée en quatre groupes fédérés par un conseil
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 des contributeurs de YunoHost, il a été décidé d’une organisation en groupes spécialisés, fédérés par un conseil de contributeurs clés.
Schéma d’organisation du projet YunoHost :
Les groupes
YunoHost est organisé en 4 groupes de contributeurs en fonction des intérêts:
- [Core Dev & Infra|LIEN VERS PLUS BAS]
- [Apps|LIEN VERS PLUS BAS]
- [Communication|LIEN VERS PLUS BAS]
Ces 4 groupes sont ouvert à tous: chacun peut lire, écrire son avis (si il juge en avoir un pertinent), poser une question, faire des propositions, prendre part à une décision.
L’objectif est de permettre aux nouveaux arrivant de s’insérer facilement dans l’équipe YunoHost.
Si il n’y a pas de consensus au sein du groupe, les questions sont traitées par le conseil.
Pour les décisions qui ne sont pas spécifiées comme pouvant être prise à titre individuelle, il y a 3 types de votes en fonction de l’importance et du type de décision:
Vote Mineur:
Durée initiale: 1 semaine.
Décalage, si nécessaire: 3 jours.
Avis nécessaires: 3 dont au moins 2 membres du conseil faisant partie du groupe (celui qui a initié le vote peut voter).
Vote Standard/Moyen:
Durée initiale: 2 semaines.
Décalage, si nécessaire: 1 semaine.
Avis nécessaires: 4 dont au moins 2 membres du conseil faisant partie du groupe (celui qui a initié le vote peut voter).
Vote Majeur :
Durée initiale: 1 mois.
Décalage, si nécessaire: 2 semaines.
Avis nécessaires: 5 et au moins la moitié des membres du conseil actifs faisant partie du groupe (celui qui a initié le vote peut voter).
Toutes décisions individuelles réversibles peut être remise en cause par un vote.
###Scope
-
Ce qui ne fait pas consensus au sein d’un groupe
-
Ce qui est jugé important/majeur
-
Ce qui est transversal
-
Ce qui ne peut pas être public
- bug/faille de sécurité avant publication d’un correctif
- discussions sur des personnes
- peut être certaines discussion d’infra sensible###
###Exemple
-
Release
-
Attribution de droit (Accès infra, Accés git)
-
Cooptation d’un contributeur
-
Réévaluation du processus de décision
-
Grandes orientations fonctionnelles###
###Modalité de consultation des discussions
Les discussions sont au maximum publiques.
###Modalité pour le droit de vote
Le conseil détermine lui même ses membres (cooptation) par le biais d’un vote comme toute décision du conseil.
Une décision est close :
-
si tous les membres actifs du conseil ont voté
-
ou si au moins 4/5 des underlinemembres actifs du conseil ayant un avisunderline sont pour au bout de 2 semaines
-
ou si 4 semaines sont passées
Pour une décision un membre actif est : -
soit un membre du conseil régulier, c’est à dire un membre du conseil qui a manifesté sont souhait d’être toujours considéré comme actif puisqu’il souhaite répondre à participer à toutes les décisions (a-t-on vraiment besoin de ce point? à part bloquer le process parce que le(s) fameux membre du conseil(s) régulier est parti en vacances, je vois pas ce que ça apporte) => ben si on nomme kload ou beubeud comme membre du conseil ça me semble logique de les considérer comme non régulier et donc de ne pas les comptabiliser dans les 4/5ème (sauf si ils répondent évidemment)
-
soit un membre du conseil qui vient de répondre à la dite décision#
#Page: Groupe Core Dev (redmine, xmpp, pad, forum || ml?)
Scope
Concerne les contributeurs aux outils suivants: -
Core YunoHost
-
Moulinette
-
Admin web
-
SSOwat
-
Dynette
-
YNH-Dev
-
Création d’image et des scripts de build automatique associé
-
Infrastructure
-
Site web (wiki, forum, salon de discussion, redmine, mumble)
-
Démo
-
Services
- ip.yunohost.org
- yunoport
- nohost.me
- yunopaste
Type de prise de décision
-
Modification des processus de développement (forum || ml ? redmine ? forge git comme pour les bonnes pratiques des apps ? wiki? pad ?)
- => Vote Majeur
-
Implémentation d’une feature ou d’un fix (redmine + codereview forge git, pad)
- Ecrire des specs sur un ticket redmine dont une partie compréhensible pour ceux qui font la doc
- Si c’est une feature ou un bug compliqué à résoudre : Chaque dev intérréssé améliore ces specs et donne ses idées
- Un Vote Standard peut être demandé pour marquer l’intention de développer ce qui est spécifié (histoire de réveiller le ticket)
- Ecriture d’un code dans une branche dont le nom est TYPE-NUMEROTICKET-DESCRIPTION (exemple “fix-533-restore-app-is-broken”) (éventuellement de façon concourante à l’amélioration des specs si c’est judicieux)
- Merge request (démarrage du délais de décision)
- Test et code review par plusieurs personnes => si modification RESET du délais de décision
- Vote pour le merge (underlinehistoire de ne pas faire porter la responsabilité du merge sur une seule personneunderline)
- Enormes modifications => Vote Majeur
- Petite fonctionnalité/ bug nécéssitant plus qu’une dizaine de ligne => Vote Standard
- Petit bugfix => Vote Mineur
- Merge + clore le ticket redmine et le placer dans la future release
- Ecrire des specs sur un ticket redmine dont une partie compréhensible pour ceux qui font la doc
-
Choix d’infrastructure (redmine)
- => Vote standard ou Vote en conseil
-
Redémarer un serveur (sauf urgence ou serveur non critique) (à consigner dans le carnet de bord \url{https://dev.yunohost.org/documents/12} + xmpp)
- => Vote mineur
Elements ne nécéssitant pas de prise de décision collective à priori
- => Vote mineur
-
Fix esthétique du code ?** (git + xmpp)**
-
Priorisation de développement (redmine + xmpp)
- Contexte: aujourd’hui il y a 13 tickets concernant la doc, 123 demandes de nouvelles features, 159 bugs ouverts
- Faut il évaluer l’importance de certains bugs (priorité redmine) et leurs facilité de résolution par rapport à d’autres (tag easy-pick dans redmine) ? oui \o/ +1 easypick
- Comment on fait pour classer collectivement tout ça ??? Au feeling ? Les changements (priorité/tag) seront argumentés+discutés dans l’issue directement, je pense que pas mal de projets fonctionnent comme ça
- oui, la maintenance du bugtracker est une activité en soit (pas tres attirante) : fermer ce qui est fixé/n’est plus valide/a été abandonné par le reporter après demande d’info/…, classifier/tagguer/linker proprement toutes les issues, demander du feedback qd nécessaire (ping), …
-
la préparation sur une infrastructure de test
-
les opérations d’adminsys routinière (à consigner dans le carnet de bord \url{https://dev.yunohost.org/documents/12} + xmpp)
- mettre à jours discourse,
- installer un truc pas chiant,
- fixer redmine qui fait chier etc… brefle, le bon jugement de la personne est de mise mais historiquement ça n’a rarement posé problème
-
Suppression d’un nom de domaine en .noho.st à condition de vérifier: (forum)
- le domaine est bien down
- la personne sait donner à peu prés la date de création
#Page: Groupe Apps (forge git + forum + redmine)
Scope
Concerne les contributeurs aux applications YunoHost ainsi que les contributeurs aux outils de vérification et de suivie des apps:
-
Apps Officielles
-
Apps Communautaires
-
Outils de développements d’app (package_checker, package linter, yunodash)
Type de prise de décision -
Intégration d’une app en officiel (forum + redmine)
- une (ou un groupe de) personne(s) propose que son app devienne officielle (elle ne doit pas être parfaite) en faisant cette proposition, cette personne ou se groupe s’engage à :
- maintenir l’application à long terme
- adhérer aux principes de YunoHost (si d’application)
- sauf si demande pour ne pas avoir cette application en officielle (par une personne du groupe), le processus est entamé l’équipe travaille alors pour rendre l’application conforme aux guidelines (review, feedback, modif)
- une fois que l’application n’a plus de modifications à faire (ou que le groupe considère que les modifications ne sont pas bloquantes) on entame alors un processus de décision classique
- => Vote standard
-
Validation d’un développement sur une app officielle (forge git + forum + redmine)
- même process que pour l’implémentation d’une feature dans le coeur
-
- appel à tester sur le forum
-
Définition des guidelines (code review sur la forge git)
- Chaque YEP doit faire l’objet d’une PR => Vote standard
-
Choix d’implémentation pour la création d’outil ou de technique pour créer de la synergie entre apps (forge git + forum + redmine)
- même process que pour l’implémentation d’une feature dans le coeur
-
- appel à tester sur le forum
Elements ne nécéssitant pas de prise de décision collective à priori
- appel à tester sur le forum
-
Contribution à une app communautaire (forum)
-
Test d’une app (forum)
-
Ajout d’une app communautaire (git)
-
Donner les droits sur leur dépot aux auteurs de chaque app communautaires (forge git)
#Page: Groupe Communication (translate, wiki, github, redmine, pad, ???)
Scope
-
Documentation
-
Communication externe (twitter)
-
Traduction
-
Animation de la communauté ?
Type de prise de décision -
Stratégie de communication (forum ? ML ?)
- Conférence/Atelier
-
Remise en cause de terminologie (exemple: store vs dépôt d’application) (translate ? forum ? ML ?)
- Si problème => Vote en conseil
-
Annulation de contribution à la doc (github => A CHANGER PAR UN MEILLEUR WIKI)
- Peut être désactiver directement par quelqu’un qui a un compte doc
- Si problème => Vote en conseil
Elements ne nécéssitant pas de prise de décision collective à priori
-
Coordination doc (redmine ou page discussion du wiki? forum/ml?)
-
Ecriture et publication de la doc pour ceux qui ont un compte (github => A CHANGER PAR UN MEILLEUR WIKI)
-
Traduction (translate + ML/forum de traducteur ? )
-
Communication routinière
-
- twitter l’annonce de travail ou de décision déjà prise
-
- RT quelqu’un·e qui parle de nous (peut être à l’exception de trucs commerciaux)
-
-
Réorganisation légère du forum
#REMARQUES
##Idées pour l’animation d’équipe
Idées générales pour la cohésion inter-groupe, l’accueil:
-
Organiser un Brique Camp
-
Réunion mumble mensuelle
Apps -
Mise en avant du tutorat pour la création d’app
-
1 event régulier sur la création d’app ?
Core dev -
Garder le salon de dev MAIS ATTENTION il devrait être réservé pour l’amélioration et l’entraide mais pas pour la prise de décision, si c’est le cas la discussion doit être répercutée sur un media asynchrone.
-
Session mumble/xmpp de triage d’issue queue ! +1
- ju +1 : cette activité étant tellement rébarbative, c’est le meilleur moyen !
Adminsys
- ju +1 : cette activité étant tellement rébarbative, c’est le meilleur moyen !
-
cérémonie de remise d’accès ?
Communication -
1 rendez-vous mumble/jistimeet régulier pour rusher sur la doc et la traduction ?
##Forum vs ML
###Pro Forum
Il y a 700 utilisateurs sur le forum, la plupart savent écrire des lignes dans un terminal, peut être certains savent coder, traduire, écrire de la doc, dessiner des interfaces… Rapprocher les décisions des utilisateurs c’est peut être permetre à certains de rejoindre l’aventure.
On peut s’inscrire au sujet et au catégorie du forum en fonction de ce que l’on souhaite suivre.
###Pro ML
Plein de geek ont l’habitude des ML
##Multiplication des canaux de discussion
Je trouve qu’il y a beaucoup de canaux de discussion, ce serait bien de pouvoir simplifier
##Animation de l’équipe de traduction
Je trouve que l’on intégre mal les traducteurs au sein de YunoHost… On ne les connait pas bien, c’est dommage.
#PLAN DE MIGRATION VERS CE NOUVEAU FONCTIONNEMENT