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.