Compte rendu de la réunion de gouvernance du projet YunoHost

Réunion YunoHost 22 et 23 octobre 2016 à Paris

L’objectif de cette réunion était de définir le positionnement de YunoHost et d’organiser la prise de décision au sein de l’équipe de contributeurs de YunoHost. Ce document est le bilan du week end, il sera sans doute amélioré dans les jours et semaines à venir.

Présents : @ljf, @Maniack_Crudelis, @Moul, @theodore

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. »

Nous proposons de limiter YunoHost au simple logiciel et de ne traiter aucun service auxiliaire estampillé sous le même nom (support payant, dns, 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 comme nohost.me, qui devra être débattue.

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 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.

Organisation de YunoHost

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 des contributeurs 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.

Schéma d’organisation du projet YunoHost :

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 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-projet en groupes thématiques :

  • Groupe Core Dev

  • Core YunoHost

  • Moulinette

  • Admin web

  • SSOwat

  • Dynette

  • YNH-Dev

  • Groupe Apps

  • Apps Officielles

  • Apps Communautaires

  • outils de développements d’app (package_checker, package linter)

  • Groupe Communication

  • Documentation

  • Communication (annonce évolutions du projet sur le forum, réseaux sociaux)

  • Traduction

  • Groupe Infra/Adminsys

  • Infrastructure

  • Site web (wiki, forum, salon de discussion, redmine, mumble)

  • Démo

  • Services

  • Groupe Support

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, de voter et de proposer au vote une décision à la suite d’une étape d’échange et d’amélioration de la proposition.
Afin de faciliter sa gestion, chaque groupe nomme donc un coordinateur (et un remplaçant) dont le rôle est :

  • d’accueillir et 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)

Le choix d’un outil de communication est laissé à chaque groupe en fonction de sa pertinence (forum, chat, ML, etc.).

Définition et constitution du Conseil

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étence). Pour pallier à cela, il est proposé de créer un meta-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éuni les contributeurs souhaitant s’impliquer le plus dans le projet, son rôle est de :

  • 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

Le choix d’un outil de communication est laissé au conseil, ses décisions doivent néanmoins être consultable par l’ensemble de la communauté de contributeur.
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 (infra, 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.

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 contrib.
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
  • il y a deux types de refus
    • “cela doit être fait autrement”
    • “on ne doit pas faire ça”
  • 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é (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 ai 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)
  • si le quota de réponse est atteint et que la date est atteinte
  • 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 quand même, il y a alors un nouveau décalage de la date et si cette nouvelle date est franchie, la proposition est clôturée
    • si 1/3 arrondi au supérieur (exemple: 1/3 de 4 == “1.33…” -> 2) [à débattre pour ce %] des participant·e·s s’étant exprimé·e·s sur cette question sont favorables au vote, alors le vote est ouvert et prend fin lorsque tout le monde a répondu (ou si nécessaire, après une date de clôture)
  • pourcentage d’avis positifs différents suivant l’importance de la prise de décisions : 50 %, 66 %, 80 %.
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

Plan d’action

Différentes idées ont été relevées au cours de la réunion par les personnes présentes. Les décisions du week-end devraient être publiée sur le forum (ou autre) pour être détaillées et discutées, en vue d’être acceptées.

Plan de migration

Il est proposé d’appliquer dés à présent ce processus décisionnel, toutefois vu que ce n’est qu’un brouillon, chaque personne est invitée à publier des propositions de modifications/améliorations/précisions et à les soumettre. Les décisions se prendront sur le forum étant donné que Maniack et Moul ont des problèmes techniques de réception ou d’écriture sur la liste de discussion mail. Rappel il est possible de s’abonner par mail au forum, par contre la fonctionnalité de réponse par mail semble ne pas fonctionner.

Mise en place d’un système de vote via Discourse plus intéressant que par mailling list.

Conseil : Bram, ju, ljf, Maniack C, Moul, opi, (scith, tostak, theodore) (à élire ? auto-promotion par méritocratie ? renouvellement au lieu de demander un retrait par d’autres membres (processus négatif))

  • Representants des groupes d’intérêts (élus ou auto-proclamés) :
    • Dev : opi, Bram, ju, ljf
  • Apps : Maniack, tostaki, Moul, ljf
  • Infra : opi, Bram, ju, Moul
  • Com
    • Com : Bram, Moul
    • Doc : Moul, theodore
    • Trad : Jean-Batiste

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?)
  • Let’s Encrypt
  • 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

Groupes 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.

Groupes Apps

  • Pour les apps communautaires, les issues sont bien sur Github, les discussions sur le forum

Support

  • Rapport de bug à partir du forum
  • Faire en sorte de nettoyer le forum pour éviter le bruit
  • Proposition de supprimer le salon de support

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 ?

Notes

Moyens de communication actuel :

  • IRL
  • Réunion Mumble
  • Forum
  • Listes de diffusion : contrib et app
  • Bugtracker Redmine
  • Forge git pour les review de code sur les PR
  • Salon de discussions XMPP

F.A.Q ?

Quelle différence avec d’autres projets (ArkOS, Cozy, Sandstorm, etc.)

  • Cozy : gouverné par une entreprise qui développe toutes les applications pour une meilleure intégration entre-elles. Basé sur Debian.
  • Sandstorm : distribution proche de la distribution YunoHost.
  • ArkOS : en développement, basé sur Arch GNU/Linux.

Pourquoi continuer YunoHost ?

La communauté de YunoHost est grandissante et beaucoup de gens comptent dessus, son architecture technique basée sur des logiciels existants et sa gestion entièrement communautaire en font un projet unique. Enfin parce que c’est amusant et que l’aventure est belle :slight_smile:

Références

7 Likes
  • :ok: Copie du compte rendu ici
  • :ok: Mise en page
  • :ok: Image organisation du projet YunoHost
  • :ok: Mise en page pas respectée sur la section “Le processus de prise de décision en détail”.
  • :ok: On renomme Conseil en Collégiale ? Doit être fait dans le texte et sur l’image.
  • (ljf: je propose de laisser tel quel cette question étant abordée en section 3b)
  • :ok: On publie aux admins pour le moment.
  • :ok: Publication du post aux modérateurs.
  • :ok: Publication à tout le monde.

  • Discussions entre les contributeurs du projet.
  • Adaptation de la proposition initiale.
  • Votes en fins de discussions avec date préremptoire.

Est-ce que c’est envisageable d’ajouter le groupe Distribution ? Un groupe consacré à la création des images, pour toutes les solutions autres qu’une installation manuelle (cartes arm etc.) et à leur distribution (torrent, upload sur build.yunohost.org). Ce groupe s’occuperait aussi de toute la doc revolvant autour du sujet, et de la création de build bot dans l’idéal.

1 Like

Merci pour ce compte-rendu :heart:

Je suis OK dans les grandes lignes. Et je suis pour adopter assez vite un process, qu’on expérimente assez vite sur quelques cas. Ce n’est qu’en l’experimentant vraiment qu’on se rendra compte de ses manques, de ses lourdeurs, bref de son adéquation à nos façons de travailler, notre disponibilité pour l’appliquer sérieusement, etc…

Il manque une proposition de définition des durées pour la décision et quotas à atteindre. Comme je l’ai dit ailleurs je suis partisan de l’option la plus simple possible. Définir 2 types de décisions (mineure/majeure) me semble suffisant à première vue.

Pour le medium, je suis personnellement plus disposé à utiliser notre ML ou redmine que le forum, qui me semble moins adapté car c’est un outil dédié au support. Peut-être que chaque groupe devrait se trouver son propre medium de prédilection (les décisions de dev/infra sur la ML, les décisons sur les apps et la com sur le forum) : chaque groupe s’autogérerait en quelque sorte.

Le point qui me pose le plus problème c’est l’idée que les groupes soient par défaut ouverts à n’importe qui. Je ne vois pas comment ça va fonctionner, et cela s’oppose à l’idée de la méritocratie en vigueur dans les projets libres généralement (c’est les gens qui sont vraiment investis dans le projet qui prennent les décisions), et à l’idée que les “experts” sont les mieux placés pour prendre une décision finale (car ils connaissent les conséquences d’une décision, en terme de risques, maintenance, bien mieux qu’un tout nouveau venu qui souhaite s’impliquer dans le projet). Cela n’empêche pas que les avis de tout le monde soit recueillis pour mettre de l’eau au moulin, et que le “groupe” qui prend la décision le fasse avec cette entrée d’informations.

@heyyounow Pour un groupe Distribution, si tu te reconnais là-dedans mais dans aucun autre groupe, alors c’est que ça fait sens ! J’ai participé au dev et à l’infra de yunohost, mais je ne me suis effectivement jamais trop préoccupé des images, qui me semble donc constituer une activité à part des autres.

J’ai surement oublié plein de choses à dire/certaines inconsistence dans cette proposition de process, mais voilà donc déjà une premiere réaction, en attendant les vôtres.

Je propose d’attendre une réaction d’au moins tous les contribs habituels ici, et d’ensuite essayer de re-rédiger une version du process en fonction de ce qui se dit, avec pour objectif de l’appliquer dans la foulée.

1 Like

Salut, tout me convient aussi :slight_smile:
Quelques questions cependant:

  • En quoi consiste le groupe support, étant donné que YNH n’a plus vocation à assurer véritablement de service ? Le fonctionnement actuel du support sur le forum me convient et semble fonctionner pas mal : entraide des utilisateurs selon leur passage. Si c’est pour nettoyer le forum de temps en temps sans forcément supporter tout le support, je fusionnerais avec le groupe comm (community management).

  • Les personnes pouvant être dans plusieurs groupes, je suppose que le conseil est composé de représentants de groupes distincts ? C’est-à-dire pas de représentant pour plusieurs groupes ?

A part ça:

  • Je veux bien rejoindre le groupe “Apps” et pourquoi pas “Support” (ou Comm si fusion proposée plus haut)

  • Excellente idée d’avoir notre propre infra sous YunoHost ! Autant montrer l’exemple et ça donnera un coup de boost pour packager de nouvelles apps

  • Super idée d’avoir notre propre forge (sous infra YunoHost), au moins pour mettre le core et les apps officielles.

  • Gel de nohost,me OK. Mais pour l’abandonner ca va etre chaud vu les utilisateurs actuels. I déalement il faudrait trouver une asso qui accepte de les reprendre, et informer les possesseurs. Bref très compliqué la migration je trouve … Mais bonne idée de geler en attendant.

Indépendamment du document dans son ensemble, auquel j’adhère bien évidemment, je viens apporter mon avis sur les décisions à prendre.

Je pense effectivement qu’un vote risque de réduire la communauté à un débat de politiciens en campagne. Je préfère que le “conseil” continue à choisir ses membres comme c’était le cas jusqu’à présent. (Même si le “conseil” n’existait que de fait)

C’est aussi ma préférence, chaque groupe devrait pouvoir intégrer les contributeurs qui ont prouvé leur motivation et leur intérêt pour Yunohost et qui sont intéressés pour rejoindre un groupe et s’impliquer d’avantage.

Peu m’importe, si ça en gène certains, soit.

Je trouve ça plus simple à maintenir, plus pratique avec le sso. Plus pratique pour gérer les accès.
Facile à backuper, facile à déployer avec un script qui va bien si nécessaire.
Et ça montre l’exemple, tout en prouvant qu’on a confiance en notre logiciel.

Étant donné les messages de plus en plus anxiogène de Firefox face aux certificats auto-signés, Let’s Encrypt est vraiment très intéressant. L’intégrer dans Yunohost serait un vrai plus. Si l’app est mûre pour ça…

Je crois avoir réussi à utiliser simone pour écrire de la doc qu’une seule fois il y a longtemps… J’utilise github depuis.
Je pense que github freine les contributions sur la doc de la part de personnes peu à l’aise avec ce genre d’outil de dev.

Éviter un service centralisé remporte toujours mon adhésion… Même si ce doit être qu’un miroir de backup.

Déléguer les services a des structures dont c’est d’avantage le métier me semble préférable, afin de nous concentrer sur la qualité du code et du logiciel dans son ensemble.
Du moins aujourd’hui que Yunohost se répand et que des structures commencent à le proposer.
En revanche, je pense qu’il faut geler mais pas abandonner les nohost.me pour ne pas pénaliser les utilisateurs en possédant.

Parler uniquement en français risque d’exclure tout les éventuels contributeurs non francophone, c’est certainement une mauvaise idée…
Mais parler uniquement en anglais exclue tout les contributeurs non anglophones. Hors, Yunohost est principalement utilisé par des francophones aujourd’hui, et les français ne sont pas les plus doués en langues étrangères…
Alors ne soyons pas discriminant, dans un sens comme dans l’autre. (Bien que ce soir là tout de suite, pas le courage de traduire…)

L’idée n’est pas de fliquer, mais bien de savoir qui fait quoi pour que chacun soit en mesure de s’adresser à la bonne personne. D’une part.
Et d’autre part, permettre à chacun de voir son nom affiché comme contributeur de Yunohost est une marque de respect envers son implication et un plaisir pour le contributeur qui se sentira reconnu.

Chacun doit pouvoir s’intéresser librement à l’activité d’un groupe et pouvoir s’y investir ou demander à l’intégrer. Mais laisser chacun intégrer n’importe quel groupe de son propre chef me semble gênant pour la cohérence de Yunohost si personne ne cadre.


Si suffisamment de personnes sont intéressées pour rejoindre un tel groupe, ça me semble une bonne idée. Une installation plus automatisée est plus accessible qu’une install de Debian. C’est donc un atout à maintenir.

A mon sens, ça fait partie des points à débattre.
3 types de décisions, “mineur” “standard” “majeur” comme proposé par Bram sur le salon me semble une bonne idée pour simplifier le process.
Mon avis:
Mineur:
Durée initiale: 1 semaine.
Décalage, si nécessaire: 3 jours.
Avis nécessaires: 3.

Standard:
Durée initiale: 2 semaines.
Décalage, si nécessaire: 1 semaine.
Avis nécessaires: 1/3 du groupe.

Majeur :
Durée initiale: 1 mois.
Décalage, si nécessaire: 2 semaines.
Avis nécessaires: 2/3 du groupe.

Ça me semble le plus raisonnable, tout les supports ne sont pas forcément adapté à tout les contributeurs, ni à toutes les contributions.

Si possible (rapport au nombre de contrib vraiment actif actuellement), il me semble préférable d’avoir une représentation la plus large possible avec au moins un représentant de chaque groupe.

Salut,
Au niveau des objectifs et de l’orga dans l’ensemble tout me convient et les propositions sont logiques. Je pense qu’il faudra juste veiller à ce que ça reste simple en pratique.

Je suis également partant pour être dans le groupe Apps et pourquoi pas aider dans des sujets d’infra. Je vois pas mal de bonnes idées dans les décisions à venir. J’ai quelques idées moi aussi notamment pour faire de l’intégration continue aux niveau des apps en réutilisant les projets existants. Dans le groupe Apps il faudra aussi définir un workflow d’officialisation d’une app, il me semble que des specs sont déjà largement rédigées.

100% pour une partie de l’infra sous yunohost ainsi qu’une forge git, bien que peut être en mirroir avec github pour les contributeurs externes.

Concernant la communication entre groupes je préférais le forum aux ML. On pourrait imaginer un forum par groupe où les discussions sont ouvertes entre groupes. Pour moi c’est plus adapté pour des discussions sur quelques jours/semaines, et en plus le système de vote est intégré.

Je ne m’exprime pas sur toutes les propositions j’imagine qu’elles seront discuté individuellement plus tard.

Pour info je bosse sur un document plus détaillé:
http://pad.arn-fai.net/p/yunohost-gouvernance

Bon moi je suis ailleurs jusque mardi. Donc j’aurais pas le temps d’avancer sur une version simplifiée d’ici là. (j’ai préféré coder sur mon app wifiwithme_ynh ce soir. N’hésitez pas si vous voulez faire bouger ce trucs, faire un système de PR ou autre…

Le pad de ljf a été dupliqué sur ce forum pour être travailler avec un suivi de l’historique et la possibilité d’en discuter.

Je suis content de partager les valeurs de ce projet, bravo pour ce travail de mise à plat.

Être identifié sur la traduction me va bien, il faudra simplement définir si on parle de coordinateur des traductions française, et? coordinateur des traductions Yunohost (multilingue).

Dans le premier cas, mon rôle est d’assurer la qualité des traductions françaises, alors que dans le second, je peux exprimer des recommandations/demandes pour renforcer le support linguistique de la plateforme Yunohost.

Les deux rôles m’intéressent, mais je souhaiterais que cela soit explicitement acté afin que cela ne pose pas de difficultés.

J’ai fait une copie exacte du compte rendu dans ce dépôt git. Puis j’ai fait quelques modifications de mise en page sans modifier le contenu.

À partir de ce dépôt git, il est possible d’intégrer, de modifier et d’adapter son contenu avant sa ratification.

Des parties pourront être intégrées par Pull requests, entre autres, à partir de cette nouvelle version. Je pense en particulier aux types de prises de décisions.

Ce dépôt pourra être facilement intégré à l’aide d’un git subtree au système de documentation actuel.

Merci pour le CR :wink:
ma participation est très en dents de scie, je n’arrive pas à me libérer suffisamment de temps pour être présent en continue,
mais je suis par là , principalement sur le xmpp où je file un coup de main quand je peux en fonction de mes compétences,
merci à vous tous pour tout le travail abattu ,
lâchez pas l’affaire !
<3

1 Like

Bonjour,

En tant qu’utilisateur lambda, je me permet de donner mon avis sur l’abandon du nohost.me. Je pense que c’est dommage, lors de ma première install de yunohost, si la preconfig automatique et la dispo immediate de nohost.me n’avait pas existait j’aurais sans doute vite abandonné :

  • premièrement parce que les configs supplémentaire m’auraient rebutées,
  • et deuxièmement parce que mon serveur n’aurait pas été visible immédiatement de l’extérieur.

à mon avis le nohost.me est dans l’esprit de “rendre accessibles au plus grand nombre l’installation et l’administration d’un serveur” dans la mesure ou il permet de simplifier des configs et des démarches pour une première approche de l’auto-hébergement.

Merci de donner ton avis.
L’idée n’est pas d’arrêter ce service au sensu stricto sensu du terme.
L’idée est que le projet YunoHost ne fournisse plus ce service, car ça n’est pas sa vocation. Sa vocation est de développer un logiciel système d’exploitation et non un perstataire de services.
L’idée est que d’autres groupes prennent la main sur ce service par un essaimage.
Bien entendu, l’installation resterait simplifié au sens, où au moment de l’installation on rajoute juste le choix du fournisseur de notre nom-domaine. Une valeur par défaut pourraient être faite comme pour les dépôts dans nos distributions.
Ces fournisseurs pourraient très bien être les FAI associatifs.

Je ne suis pas d’accord avec le soucis de configuration pouvant apparaitre sans nohost.me

Avoir un nom de domaine n’est pas compliqué. Le faire pointer sur un serveur non plus, surtout si OVH, Gandi ou autre t’expliquent comment faire…

Yunohost ne demande que le nom de domaine original, et que cela soit nohost.me ou TONDOMAINE.TLD, cela ne change rien à la configuration.

Salut, ça répond quand même à un besoin différent je pense.

Le nohost est un DynDNS qui permet également d’éviter la nécessité d’avoir une IP fixe (que tout le monde n’a pas). Utiliser un autre dyndns (noip etc) n’est pour le moment pas à la portée du premier venu car YunoHost ne dispose pas à ma connaissance de client dyn intégré à l’interface webapp (ni même à la moulinette).
Comme le dit Moul je pense aussi que ce service nohost sera plus simple à remplacer une fois qu’un client dyn sera intégré de base à YNH et ce de manière simple d’usage (dans l’interface admin, rajouter un domaine de type dyn, OVH ou autre).

J’ai tenté de faire une app rustine pour ça mais elle est pas encore prêt et est un peu dans un carton en ce moment car je n’en ai pas le besoin …

Ah, je n’avais pas songé à la notion d’IP dynamique.

Mea Culpa. :smiley: