Alors que la v4 est de plus en plus utilisée, il devient de plus en plus dur de garder une trace des fonctionnalités demandées par la communauté, et surtout il devient urgent d’avoir un moyen de prioriser les développements.
Nous utilisons GitHub côté développement afin de lister les développements prévus/en cours/terminé.
Sauf que j’ai de plus en plus de demandes de développements, et actuellement mon seul moyen de savoir que “ce développement est beaucoup demandé”, c’est de me souvenir que j’ai vu cette requête dans plusieurs posts: bref, c’est pas viable
Cette catégorie est super simple: c’est un board où chaque post est une demande de fonctionnalité. Ensuite, tout le monde sur ce forum peut voter pour les fonctionnalités qu’il souhaite voir dans Gladys.
Cette liste, ordonnées par nombre de vote, donnera à toute personne qui veut nous aider sur Gladys une idée des fonctionnalités les plus demandées.
Cette catégorie ne remplace pas GitHub
Attention, cette catégorie ne vient surtout pas remplacer notre flow GitHub actuel qui reste le même.
Vous avez trouvé un bug dans Gladys? Créez une issue Github.
Vous avez une ampoule Philips Hue non gérée par Gladys ? Créez une issue Github.
Vous développez sur Gladys et voulez référencer votre développement ? Créez une issue GitHub.
Cette catégorie est utile en amont de GitHub. Elle est destiné aux “utilisateurs” qui veulent faire entendre leur voix et voir si d’autres utilisateurs veulent la même fonctionnalité dans Gladys
Le nouveau flow
L’utilisateur créé une feature request sur le forum
La feature reçoit un grand nombre de vote
Après discussion avec les mainteneurs Gladys, on décide que la feature sera développé
Une Issue GitHub est créée
On met une référence vers l’issue GitHub sur le forum dans le post de la feature
La feature est développée, on ferme l’issue Github et le sujet sur le forum, avec un post expliquant le développement effectué.
Effectivement on peut ajouter certains trucs déjà prévus histoire de montrer l’exemple, et de lier le post sur le forum à l’issue/la PR ça permettra de mieux faire le lien entre le Github qui est lu que par les devs/et la communauté qui est lue que par les utilisateurs
@AlexTrovato Tu es un membre « Trust level 2 », tu as donc 6 votes à distribuer, c’est bien ça?
Je trouve pas ça déconnant, sinon tout le monde va voter pour tout et il n’y aura pas vraiment de différence entre les features.
On pourra ré-évaluer la quantité de vote dispo par utilisateurs quand il y aura plus de post. Par exemple si il y a 100 features dans la catégorie, on peut donner 15 votes pour que l’utilisateur puisse voter pour les 15% qu’il préfère. Vous en pensez quoi?
Ce n’est pas possible de désactiver la fonction meilleure réponse pour une catégorie seulement, du moins je n’ai pas trouvé!
Je suis également du même avis. 15% cela permet vraiment de s’attacher aux principales fonctionnalités que l’on recherche. Et au fur et à mesure des avancements, on pourra choisir d’autre chose.
Pour le coup, lorsqu’on crée un topic par contre, tu comptabilise un vote pour le créateur ou l’on doit voter dessus également ? Si ce n’est pas le cas, peut-être le préciser car j’ai vu des sujets créés sans votes, et j’en ai fait de même ^^
Normalement si ! Quand une feature est développée et le sujet fermé, les votes sont relâchés, ce n’est pas le cas ?
Si tout le monde vote pour tout alors on aura une égalité parfaite entre toutes les features, ca perd l’intérêt d’avoir un système de vote.
Si tu as explosé ton quota, soit tu arrête de voter, soit tu redistribue différemment tes votes à toi de choisir ce que tu trouves plus intéressant à développer pour toi.
On pourra rajouter des crédits de vote à l’avenir mais pour l’instant compte tenu du nombre assez faible de features proposées (28 au moment où j’écris ces lignes), ça veut dire que tu peux voter pour 20% des features, ça me semble cohérent.
