Tickets pour la gestion des applications

Contribute Room Apps packaging
1

Le débat est en cours pour savoir où doivent se trouver les issues des applications.

Pour les applications communautaires, je crois que la question se pose peu. Elles sont pour le moment sur les dépôts git de chaque app.

En revanche, pour les apps officielles, les issues sont pour le moment sur redmine, et certains préférerais les voir revenir sur leur dépôts git.

Voilà l’état des discussions pour le moment:

Décision standard (sauf si objection). La date de clôture initiale est donc fixée au 1er décembre.

1 Like
2

Salut, je pense que les issues apps officielles doivent être dans la même plateforme que les autres issues officielles (core etc…) par soucis de cohérence.

Les points soulevés ci dessus relèvent du fonctionnement de redmine moins évident que celui de github.

Du coup, quelles étaient les raisons de mettre en place Redmine pour yunohost au départ (plutôt que de rester sur github) ?

A terme, si les dépôts officiels migrent sur gogs ou gitlab, l’usage de redmine sera-t-il remis en cause ?

3

Est-ce plus cohérent pour l’utilisateur final qu’une partie des apps aient leur issues sur github et l’autre sur redmine?

4

A mon propre avis non, tout devrait être sur gît :smiley: d’où ma question sur le pourquoi du redmine car il y a peut être des raisons qui ont fait que gît n’était pas adapté …

Mais si le core est sur redmine et les apps sur github, j’ai peur que les utilisateurs s’emmêlent pour le report de bugs et au final n’en remontent que peu sur le core. Au moins la on sait que tout ce qui est officiel c’est sur redmine (apps comme core)

Après en tant que packageur je préfère aussi github, et ce sera déroutant pour moi si mes apps passent en officielles et que du coup je doive tout gérer sur redmine …

5

J’ignore pourquoi redmine, je n’étais pas présent au moment où il est apparu. J’ignore tout autant si il sera remis en question.

Encore cette même remarque, je ne suis pas pour dissocier de trop les différentes parties de Yunohost, déjà que le Core a tendance à être enclavé, mais redmine est vraiment peu pratique en l’état pour gérer les issues des apps.
Pour ma part, tout sur github m’allait très bien, ou une autre forge git. Même si je déteste git…

1 Like
6

Pour la mise en place de redmine, c’était une période où j’étais assez peu actif. Cependant je me souviens que :

  • il y avait une volonté claire de réduire la dépendance à GitHub, par cohérence avec les objectifs défendus par le projet.
  • le fait d’avoir tous les bugs centralisés étaient + facile à gerer pour le core : on peut bouger des bugs entre moulinette et yunohost et brique_internet par exemple.
  • ça donne un guichet unique d’entrée aux utilisateurs : ils peuvent poster une issue sans avoir à se poser la question de savoir si c’est un probleme de l’app ou du core, et de savoir comment/où reporter des issues pour l’un ou pour l’autre

Pour les apps c’est vrai que ça se discute… Je rejoins @Maniack_Crudelis et @tostaki sur les critiques de redmine notamment pour les apps. J’ai beau aimer le concept d’autohéberger nos issues, je reconnais qu’à l’usage “c’était mieux avant”. Pour moi, en tant que développeur d’app. Je parle pas au nom de l’utilisateur standard… Faire converger les intérêts des deux parties sur un meme outil c’est pas forcément facile.

Ce serait bien que les contribs actifs à l’époque corrige/complète ma petite liste de “pourquoi redmine” et qu’on essaie d’évaluer pour chacun des buts si oui ou non on a progressé/c’est utile.

1 Like
7

Merci

Sur ces points on doit pouvoir se débrouiller avec Gitlab (à terme si on migre nos dépots) ?
Peut-être aussi avec Gogs je sais pas ?

Pour ce point Redmine semble pas mal en effet … A moins de faire un helpdesk mais ce serait pire pour tout le monde :frowning:
On pourrait éventuellement soit avoir le guichet unique sur le forum (pas très pratique), soit sur un repo gitlab (depuis lequel on migre les issues vers les repos adaptés).

Attendons de lire d’autres raisons …
Mais selon moi il vaudrait mieux attendre de migrer les repos vers gitlab ou gogs (si jamais c’est prévu ??) avant de décider de changer la localisation des issues d’applications non ?

8

Sur ce point je suis bien d’accord !
Si on pouvais même tout migrer, ou avoir un miroir ce serait bien.

Sur ce point, clairement git n’est pas adapté. Il est difficile de définir dés le début l’origine d’un bug.
Et ce n’est pas à l’utilisateur final de déterminé dans quel dépôt ouvrir son issue.

Toutefois, tout cela est très approprié au core de Yunohost. Mais pour les app, je ne suis pas convaincu.

9

Le débat n’est pas clos, et aucun accord clair n’émerge. J’invite donc chaque membre du groupe à s’exprimer.

État des lieux de la discussion (plus ou moins impartiale sans doute)
A partir de la situation actuelle, à savoir les issues d’apps officielles sur redmine.

Les plus:

  • Cohérence des rapports de bug sur la partie officielle de Yunohost, centralisée sur redmine.
  • Suivi global des rapports de bug de Yunohost, que ce soit sur le core ou les apps.
  • Possibilité de créer des sous-projets par app pour les dissocier.
  • Évite de dissocier les différentes parties de Yunohost.
  • Réduit la dépendance à Github.
  • Permet aux utilisateurs de ne pas se préoccuper de savoir si c’est un bug d’une app ou du core.

Les moins:

  • Les bugs d’applications sont mélangés entre eux, il faut fouiller pour trouver ceux concernant une app en particulier.
  • Un mainteneur d’app risque de ne pas voir des issues le concernant (En fouillant je viens de justement de trouver une vieille issue wordpress datant de 3 mois. Je n’en connais pas l’état aujourd’hui!)
  • Sinon, il reçoit des notifications pour l’ensemble des apps officielles, et doit lire chaque notification pour savoir si il est concerné. (Ce point serait réglé par la création de sous-projets)
  • Incohérence des rapports de bug des applications, certaines (communautaires) sont sur github, tandis que d’autres (officielles) sont sur redmine.
  • Oblige un packageur à changer d’outils sans cesse pour voir le code, répondre, merger et fermer l’issue. Alors que sur github, un seul outil suffit.
  • Risque que les utilisateurs ne rapporte pas les bugs du core sur redmine si les apps sont sur github???
  • On peut installer une forge git pour ne pas être dépendant de github.
1 Like
10

Bon ben je vote le retour à Github en attendant de migrer sur notre propre forge. Parce que ça fonctionne quand même du tonnerre sur l’organisation “yunohost apps” avec les équipes et tout.

11

Dans les arguments pour redmine y avait aussi :

  • c’était le gros bordel entre tous les répos sur plein de comptes utilisateurs différents (on avait pas l’orga yunohost, kload y était opposé sans que j’ai jamais capté pourquoi, idem pour yunohost-apps)
  • résultat personne savait jamais où rapporter les bugs, donc ça finissait perdu un peu partout ou en query de kload et ça mourrait dans un coin
  • tout avoir centralisé permettait de faire une gestion centralisé plus efficace et de déplacer les issues entre projets
  • une partie de notre public ne voulait pas avoir à se faire de compte github (on défend l’autohébergement quoi …)
  • la possibilité de rapporter un bug sans avoir à se faire un compte était aussi une demande

Donc autant pour le core c’est pleinement justifié, autant pour les apps ça l’a moins l’air nécessaire et c’est vrai que redmine est un peu pénible pour facilement filtrer par catégories (en testant rapidement). Les sous projets sont peut être une bonne alternative.

Personnellement j’aime bien le statu-quo: redmine pour les apps officielles (à aménager en sous projets) et github (autre ?) pour les non-officielles.

Le point “guichet d’entré unique” me semble vraiment important pour notre communauté, cela simplifie énormément les choses et ça nous permet à nous en tant que groupe de tout gérer au même endroit.

1 Like
12

J’imagine assez le bordel que ça devait être !

C’est effectivement une problématique de github, d’autant que le service n’est pas totalement libre. J’ignore si gogs ou gitlab permettent l’ouverture d’issues sans création de compte.
C’est un argument indéniable en faveur de redmine.

C’est pas le cas actuellement, on a une partie sur redmine, l’autre sur github. Et c’est pareil pour les utilisateurs.
J’aime aussi l’idée du “guichet unique”, mais en l’état ça me semble bien difficile, sauf à tout renvoyer sur github, ce qui n’est pas souhaitable pour le core.
Les apps communautaires ne sont, certes, pas officielles, mais elles n’en sont pas moins une part très importante de Yunohost.

13

Les apps communautaires ne sont, certes, pas officielles, mais elles n’en sont pas moins une part très importante de Yunohost.

Tout à fait, mais je ne désespère pas de voir dans un futur proche une partie de ces apps se joindre à la liste des apps officielles :slight_smile:

14

Gitlab le permet aussi apparement, en revanche aucune idée si l’ouverture de rapports sans inscription est possible.

Mais pour cela, et d’un point de vue Communication, un compte unique Forum/Wiki/Forge serait idéal et apporterait une vraie cohérence dans le parcours de contribution :

  1. si j’ai un problème, je me renseigne en consultant la doc
  2. si je n’y trouve pas l’information, je vais chercher de l’aide sur le forum
  3. soit mon problème était lié à une mauvaise compréhension/une lacune dans la doc, j’améliore cette dernière
  4. soit le problème était nouveau, dans ce cas je rapporte un bug

Ça rejoint un peu la discussion sur l’utilisation de YunoHost pour l’infrastructure (puisque, si je dis pas de bêtise, ça permettrait un SSO facilement) :wink:

1 Like
15

Ça reviendrait à créer un compte Yunohost à chaque membre du forum?
Ça implique la création d’utilisateur indépendamment de l’admin (je crois que quelqu’un y a travaillé, scith peut-être) mais surtout, est-ce que Yunohost est capable de supporter cette charge?

Dans une moindre mesure un compte Yunohost pour chaque membre de groupe serait plus faisable à mon avis. (Mais je ne connais pas les limites de Yunohost en la matière)

16

Salut, on dirait qu’il y a deux éléments distincts à la réponse “comment gérer les tickets YNH ?” d’après la discussion : 1) pour les devs et 2) pour les utilisateurs.

1) Pour les devs, je pense que la gestion de tickets sur la forge est assez pratique (core comme apps). D’autant plus que certaines forges proposent une vue d’ensemble on dirait (au moins un flux d’activité), des notifs, et de déplacer des issues (comme gitlab). En ce moment l’organisation de YNH Apps sur github est très efficace. Pas sur qu’il y ait une roadmap multi-repo par contre.

  • Redmine peut être lié à certaines forges pour les tickets, permet le roadmap et une vue d’ensemble, mais n’est pas forcément lié à notre outil de code (pas de snippets de code, plateforme différente, …). Plus quelques problèmes relevés comme les notifs, le suivi, …

  • Les forges sont nos outils de travail donc un point d’entrée unique pour travailler sur le code. Les tickets sont faciles à lier au code et aux différents repos. Personnellement je trouve ça bien plus pratique et intégré …

2) Pour les utilisateurs, il y a surtout l’enjeu de la simplicité du parcours. Les éléments identifiés dans la discussion:

  • Guichet unique (tout au même endroit)
  • Possibilité de ticket anonyme
  • Eventuellement un même compte utilisateur que pour le forum
  • Facile à utiliser

Redmine permet le guichet unique anonyme, pourquoi pas lié au forum (avec un SSO) mais je ne le trouve pas forcément facile.

Le forum permet le guichet unique compte unique (éventuellement anonyme mais pas besoin ici), est facile à utiliser. Par contre il faut rapatrier ensuite les tickets sur notre forge (ou autre), ou avoir une équipe de modération pour orienter du guichet vers la forge.

La forge permet le compte unique (avec SSO) mais n’est pas forcément guichet unique ou facile à utiliser. On peut éventuellement la compléter par une doc “ouvrir un ticket” avec un arbre de décision qui permet de rediriger vers le repo approprié ou vers le forum au pire.

Le helpdesk permet le guichet unique anonyme mais bon … Qui veut faire du helpdesk toute la journée? :laughing:

Voici les options que je vois …

Personnellement j’ai une préférence pour avoir le guichet unique “dev” sur notre propre forge, et le guichet unique “utilisateur” sur le forum (ou sur la forge pour les initiés) pour les raisons suivantes:

  • Les devs travaillent sur la forge, donc tickets sur la forge
  • Les utilisateurs avertis postent directement sur la forge. La doc peut ainsi aider les indécis à poster les problèmes dans les repo appropriés (arbres de décision)
  • Les utilisateurs qui ne savent pas ou cherchent la facilité postent sur le forum. Soit “on” (les modérateurs ou d’autres utilisateurs) les redirigent vers la forge, soit le problème existe déjà et “on” ferme et renvoie vers le post du forum, soit “on” le crée nous-même dans la forge et “on” le référence sur le forum.

Oui ça peut faire du boulot sur le forum, mais à terme l’idée est de rendre le forum encore plus dynamique et central : que les utilisateurs s’entraident (comme maintenant), que les devs aillent sur le forum (si ils veulent, mais ils ont beaucoup à apporter), que le “parcours utilisateur” soit simplifié et centralisé autour du forum. On peut éventuellement rajouter des catégories dans le forum support ou réorganiser en fonction je sais pas

En plus c’est à peu près la manière dont ca marche aujourd’hui il me semble: les gens ignorent qu’il y a un Redmine, postent sur le forum. On les redirige vers le Redmine ou on règle ca directement sur le forum … Quel est alors l’intérêt de Redmine si le guichet unique se fait principalement sur le forum ?

Désolé du pavé :laughing:

17

Oui en effet j’ai des scripts PHP pour créer des comptes utilisateurs sur YunoHost. Mais comme tu dis on peut avoir des comptes yunohost pour les personnes des groupes, et des comptes normaux pour les autres (éventuellement liés d’une autre manière).

Je pense aussi que des comptes utilisateurs YNH risque d’être compliqué (permissions LDAP sur les apps, retrait de la boite mail, charge d’users, …) mais ça peut être un super challenge et une démonstration exemplaire du potentiel de yunohost … “Vous utilisez déjà yunohost sans le savoir” :smile: + sso + compte XMPP, etc

18

La référence à YunoHost pour l’infrastructure a brouillé le propos de mon message, je voulais décrire un fonctionnement similaire à celui énoncé par @scith, avec lequel je suis entièrement d’accord.

J’ajoutais le fait de ne pas avoir à se recréer un nouveau compte pour passer du forum à la forge (ce que permettrait un gitlab auto-hebergé) ce qui faciliterait les contributions. YunoHost n’est en rien obligatoire pour ça.

19

Si c’est pour les apps, l’équipe on l’a. C’est au mainteneur de répondre aux utilisateurs de son app, et de rediriger vers la forge si nécessaire.
Ce qui est déjà souvent le cas d’ailleurs.[quote=“scith, post:16, topic:2154”]
Les devs travaillent sur la forge, donc tickets sur la forge
Les utilisateurs avertis postent directement sur la forge. La doc peut ainsi aider les indécis à poster les problèmes dans les repo appropriés (arbres de décision)
Les utilisateurs qui ne savent pas ou cherchent la facilité postent sur le forum. Soit “on” (les modérateurs ou d’autres utilisateurs) les redirigent vers la forge, soit le problème existe déjà et “on” ferme et renvoie vers le post du forum, soit “on” le crée nous-même dans la forge et “on” le référence sur le forum.
[/quote]
Par la force des choses c’est déjà comme ça que ça marche, et je trouve ça pas plus mal. Le forum est facile pour les utilisateurs, ce qui n’est pas le cas de redmine et github, et les forges (d’apps communautaires) centralisent toutes les infos pour les packageurs.

En quoi gitlab permet ça? Je n’ai jamais utilisé gitlab, c’est pour ça que je pose la question.

20

Moi non plus mais peut être via un plugin GitLab OmniAuth plugin - #29 by Falco - plugin - Discourse Meta