CONFIG/creation-du-fichier-modele-de-ticket-pour-demander-une-evolution-de-la-plateforme #2
Labels
No Label
Bug
Communication
Evolution
Organisation
Patch
Service
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Ouvaton/EvolutionPlateforme#2
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Ce dépôt a pour vocation de favoriser l'ouverture de tickets pour lister toute idée d'évolution de la plateforme, selon le principe:
Réaliser un modèle de rédaction de ticket, permet souvent de mieux comprendre les demandes d'évolutions proposées.
Pour commencer à produire la rédaction de ce modèle de ticket, j'ai créé une branche:
Sur cette branche j'ai créé un répertoire
.giteaet dans ce répertoire j'ai créé un fichier appeléISSUE_TEMPLATE.mdNote: pour créer un répertoire via l'interface web, j'ai tout simplement placer ce texte
.gitea/ISSUE_TEMPLATE.mddans la case du nom du fichier à créer.Je pense que le modèle de ticket est trop ambitieux. Il faudra laisser les gens donner leur idée, et ensuite les aider à détailler et reformuler. Une fois l'idée correctement"formée", on en fait un .MD qu'on met dans le dépôt, et on tag le ticket comme "amélioration demandée". On tag ensuite en cours, puis on clos.
Si tu donnes un truc aux gens qui les force à écrire tout de suite plus que "je veux ça parce que c'est une bonne idée". Mieux vaut les laisser faire, puis les aider à affiner.
On peut gérer les droits en écriture sur le dépôt ? Si oui, on limite l'écriture à un certain nombre de "volontaires".
Je vais tenter un contenu en 2 parties.
L'idée n'était pas de faire des fichiers .md par idée.
Mais le principe est plutôt de faire de chaque ticket (chaque issue) une demande.
Le ticket que je rédige actuellement, est un modèle de ticket sous format .md qui sera appelé automatiquement lorsqu'une personne ouvrira un ticket. Chaque ticket ouvert, aura par défaut, les rubriques du ticket modèle.
Les tickets pourront être remplis par la personne émétrice de l'idée, ou bien par une personne qui détecte cette idée et qui a les moyens de remplir un nouveau ticket dans le cas ou la personne émétrice n'a pas envie (le temps, les moyens, les connaissances, etc ...) de se servir de gitea et de ce dispositif.
Ça te parait mieux ?
Ok alors. C'est ce qu'il me semblait, mais comme le modèle n'était pas appliqué, je me suis dit que ça n'était pas ça. Dans ce cas, très bien.
J'ai finalisé la première maquette du modèle de ticket:
Des commentaires apparaissent en mode écriture. Ils aident au remplissage.
Seuls le titre et le résumé sont à remplir "obligatoirement" pour que la proposition d'évolution soit prise en compte.
Le reste des sections sont optionnelles et peuvent être remplies plus tard.
Je sollicite votre avis @mpatout , @gurvan , @pladame , @fdelalleau , @crouchouse : on fait une première tentative avec ce modèle de ticket que je rends comme texte par défaut pour chaque ouverture de ticket sur ce dépôt ?
Personnellement, je le trouve trop long et trop compliqué. Il risque de faire peur à des néophytes comme @fdelalleau le faisait remarquer. Je serais partisan de le réduire au titre et au résumé, et de mettre un lien vers un fichier modèle complet pour les personnes qui souhaitent aller plus loin. Et/ou , faire un modèle simplifié (par défaut) et un modèle complet pouvant être appelé lors de la création du ticket (menu).
Je rejoins @antoine-c , trop compliqué en soi si on veut que ce soit largement utilisé. L'idée d'un modèle simplifié et d'un modèle détaillé est effectivement intéressante.
Ok.
J'ai rédigé 2 modèles:
Pour le modèle simplifié, je pars du principe que le nom du ticket fait office de "titre" du ticket, sans avoir à le rapeler dans le texte du ticket.
Par défaut, ce sera le modèle simplifié qui apparaîtra à chaque ouverture de nouveau ticket.
Je vais maintenant m'atteler à écrire une page explicative sur le wiki du dépôt, qui servira de page d'accueil pour les personnes qui désirent poster une idée d'amélioration via ce dépôt.
Cela vous va ?
Quand on ouvre un ticket, on a maintenant le texte du modèle simplifié qui apparaît.
Mes remarques:
Je penses qu'un renvois sur un wiki un peu plus détaillé (on enlève les explication du MD et on les mets en wiki) serait préférable. Et mettre dans le wiki un home avec les objectifs du dépôt un peu plus détaillés, plus un renvois depuis le readme.
Après effectivement, il est nécessaire de mettre en début de ticket une indication (plus) succincte de ce qu'il faut faire. En gros, "merci de mettre un titre un explicite, et d'essayer de donner les infos suivantes : [ce que tu as mis en phrases, mais en puces]. Pour plus d'informations, cf le wiki". C'est moins abrupte...
Ok. J'ai simplifié le texte.
Quand on ouvre un nouveau ticket, cela ouvre le modèle de ticket.
Je commence à rédiger la page du wiki sur une branche spécifique dans un fichier markdown situé dans un répertoire .wiki créé à la racine du dépôt, au même niveau que le répertoire .gitea.
Quand la rédaction sera suffisamment aboutie, j'en ferai un copié/collé sur la page home du wiki.
J'ai avancé dans la rédaction de la page du wiki
Cette page serait l'URL que nous pourrions utiliser pour indiquer aux personnes où se rendre pour proposer une amélioration de la plateforme.
Qu'en pensez-vous ?
Ce fichier .md est utilisé pour rédiger la page du wiki.
Bonjour
Mon avis :
Le ticket me semble très bien ; la page par contre, je la trouve très verbeuse et j'ai peur qu'elle ne décourage. J'aurais tendance à mettre le minimum mais à garder "sous la main" cette page afin d'avoir la trame des questions à poser par l'un(e) d'entre nous pour demander des infos complémentaires, et en cela elle est très complète : merci Antoine !
Je suis d'accord avec Claire. Ne peut-on pas avoir 2 page, une première avec juste le simplifié, et un renvois vers une seconde pour ceux qui veulent avoir accès au détaillé ?
Pas sûr de comprendre. Tu parles bien de la page d'accueil du wiki ?
Si oui, que penserais-tu si on met sur une seconde page de wiki, toute la partie de la page intitulée "Comment utiliser le modèle détaillé à la place du modèle simplifié par défaut" avec le tout code au format markdown à copier ?
Cela ferait une page d'accueil "épurée". Ou faut-il encore plus simplifier ?
À moins que tu ne parles de simplifier le ticket détaillé ?
je parle bien de la page d'accueil qui selon moi est trop dense. Une page épurée avec 2 infos
Ok. Merci pour vos retours. J'ai compris. Je m'y mets dès que j'ai un moment de disponible ...
@mpatout : j'ai besoin de tes lumières ... Peux-tu me dire quelle sera la "politique" d'accès à la rédaction des tickets sur ce dépôt ?
J'ai besoin de cette info pour rédiger la page du wiki (how-to). J'ai besoin de savoir si la rédaction des tickets sur ce dépôt gitea d'ouvaton, sera réservée exclusivement à des personnes ayant un compte sur cette l'instance Gitea d'Ouvaton, ou si "toute" personne pourra poster un ticket, y compris les personnes qui ne sont pas identifiées sur l'instance Gitea d'Ouvaton.
Nota: sur le wiki de ce dépôt, je compte indiquer qu'il existe 3 canaux pour poster une proposition d'amélioration de la plateforme :
Salut,
C'est a déterminer, mais un compte sera en effet nécessaire pour ouvrir un ticket.
Le forum est probablement idéal pour les propositions de sociétaires.
Ok. Merci pour l'info.
J'ai mis à jour la partie wiki du dépôt en tenant compte de vos remarques.
https://git.ouvaton.coop/Ouvaton/EvolutionPlateforme/wiki
C'est mieux ?
Quelle procédure souhaites-tu pour qu'un utilisateur ouvre un compte ?
Pour l'instant, on arrive sur une page de connexion, sans possibilité de s'inscrire.
Les demandes sont à faire sur https://forums.ouvaton.coop/t/gitea-un-nouveau-service-sur-la-plateforme/1934.
Dans ce cas, je propose:
Qu'en pensez-vous ?
Modif du wiki de ce dépôt:
Ça me semble bien. C'est peut-être beaucoup d'étapes et de comptes à ouvrir (d'abord sur le forum puis sur Gitea), mais ça peut faire découvrir Git !
Par contre on ouvre l'accès à Gitea aux non-sociétaires ?
Il y a peu de comptes et de demandes (deux structures pour le moment, mais avec plusieurs utilisateurs), mais je regarde avant d'en ouvrir un si le compte Ouvadmin lié a une part sociale.
moi aussi je trouve ça très bien. PAr contre, peut être en Quelquees mots dire ce qu'est GIT et GITEA ... parce que je ne suis pas sûre que tous les coopérateurs sachent ce que c'est
Les quelques mots ça peut se limiter à juste indiquer des liens vers wikipedia pour GIT https://fr.wikipedia.org/wiki/Git et la doc GITEA https://docs.gitea.io/fr-fr/
Pour les non sociétaires, je ne sais pas trop : tout dépend du % . Je n'ai pas suivi : on en est à combien de % de non sociétaire ??
Oui, un lien vers Wikipedia et un vers le site de Gitea c'est bien.
Les non-sociétaires représentent 21.02 % du CA et 24.31 % des comptes ouverts.
On peut alors se limiter aux sociétaires dans un premier temps. Et ouvrir ensuite aux autres si on voit que ça végète (nombre à fixer, je n'en ai aucune idée ... un avis ?), disons au bout de 6 mois (?)
PS : je ne mets pas des dates et des chiffres dans mes mails parce que je suis psycho rigide mais parce que je sais d'expérience que si on dit "plus tard", "un jour", "le plus tôt possible" pour les dates ça ne se fait jamais ... et "suffisament", "un nombre conséquent" pour les chiffres, pareil
Ça vous va ?
Tu parles des:
Des comptes ouverts mais sans part sociale. :-)
tu dégaines plus vite que ton ombre !! je pouvais le faire aussi ;) ... mais pas aussi vite !
pour ça, je pencherais pour la dernière catégorie. La première et la 3ème je ne les avais pas envisagées ; la seconde ... attendre 1 mois ne me semble pas trop long à condition que l'essai soit transformé
Comme dit précédemment, en 1er uniquement aux sociétaires puis selon ... mais en gardant a minima le côté "a un pied dans la coop" par un compte à jour de paiement.
J'ai le sentiment que nous pourrions ouvrir l'accès à gitea aux personnes qui ont un compte ouvert payant et payé et qui ne sont pas sociétaires.
Car cela permet d'avoir un maximum de sources d'idées, y compris en provenance des personnes qui ne se sentent pas une âme "sociétaire". Avoir l'avis de ces personnes en particulier me semblerait intéressant. Idéalement, pouvoir filtrer par un label les posts des non-sociétaires pourraient s'avérer utile.
L'adresse git@ouvaton.coop utilisée par Gitea dépasse le quota de 20 mails / heure. :-)
Je viens de l'augmenter.
Ok pour ouvrir un accès à Gitea aux comptes sans parts sociales, il peut s'agir d'un accès sans possibilité de créer des dépôts.
Sur la thématique des suggestions/requêtes/propositions des utilisateurs d'Ouvaton, je viens de découvrir le logiciel http://www.phpback.org/ de l'équipe qui développe OpenSupports.
Enfin, je ne comprends pas la distinction entre compte payant à jour et compte payant pas à jour. Un compte payant pas à jour est un compte fermé, et là plus d'accès à Gitea (sauf si on décide de rendre l'accès à Gitea public, ce qui me semble délicat sur son serveur actuel).
Question:
Est-ce que l'on met dans les prochains échos de la coop de septembre pour indiquer aux personnes qu'elles peuvent désormais proposer des améliorations de la plateforme en se rendant sur la page d'accueil du wiki de ce dépôt ?
Oups, désolé. Ça peut poser problème ?
Ok pour moi.
Ce pourrait être un 4ème vecteur à spécifier dans la page d'accueil du wiki de ce dépôt.
À "nous" ensuite, de faire des "copiés" des suggestions faites sur les différents vecteurs pour ensuite ouvrir des tickets et "coller" leur contenu.
En le précisant, on s'assure que l'on parle bien de ce cas de figure. Il ne peut théoriquement pas y avoir de comptes ouverts ayant en retard de paiement, mais cela pourrait arriver tout de même, comme cet exemple fictif: une personne est en retard de paiement, son compte est fermé, la personne râle, on ré-ouvre son compte et on lui donne quelques jours pour régulariser.
je pense juste que Matthieu donnait ça comme une info positive, signe qu'il y a "de la vie" sur Gitea
mummm , c'est pas un peu "compliqué" s'il faut (sans jeu de mot) qu'on s'y colle ?
Ça me semble une bonne idée d'ajouter un texte dans les Échos à venir.
Je viens de faire une rapide proposition (https://pad.ouvaton.coop/prochain_bulletin).
Pour git@ouvaton.coop, non pas de problème au contraire. C'est bon de voir de l'activité. :-)
Ok pour les comptes "à jour" ou pas. L'exemple est loin d'être fictif. ;-)
pour le bulletin, j'ai toujours la même approche : comme on voit que le début sur le site, il mee semble important de commencer par ce qu'on veut mettre en avant
Donc soit c'set la version php, soit gitea ...
et moije mettrais gitea . la maj de PHP pour moi ce pourrait être un bandeau de rappel sur ouvaton.coop, et/ou ur ouvadmin . Parce que c'est important mais pas "de l'actu"
Je trouve que dans le bulletin on mélange un peu les choux et les carottes et on met sur le même plan des choses comme upgrader php qui est un impératif technique-sécurité et des infos comme "donnez nous vos idées"
Php on en parle depuis des lustres. D'où mon idée du bandeau pour "le dire bien fort"
Le retrait dans 6 mois de la v5.6 de PHP, encore utilisée par 54 % des sites, c'est une grosse actu ! Le support engendré par la disparition de la v5.6 va être (trés) important. Bandeau (je viens d'en ajouter un), mails, Échos, réseaux sociaux, etc, il faut en parler partout.
Après l'ordre dans les Échos m'importe peu, c'est que dans 6 mois PHP, on pourra le mettre plus en avant fin 2020/début 2021, alors ok pour commencer par la possilbité de proposer des améliorations de la plateforme.
très bien le bandeau ! moi aussi je pense qu'il faut MARTELER en effet ... pour le plus possible anticiper et étaler dans le temps les supports.
tu le mettrais pas en couleurs pour qu'on le voit mieux ?? genre sur fond jaune poussin ? tant pis si c'est moche !
et peut être aussi alterner : bandeau, pop'up ... on le sait, on s'habitue très vite ...
je n'ai plus qu'un accès minimaliste au site mais je me propose pour le faire si tu n'as le temps et si vous acceptez
sur ouvadmin je sais pas faire, mais ça serait bien aussi : il y a sans doute plus d'utilisateurs d'ouvadmin en direct que d'ouvaton.coop pour aller gérer leur site ?
Si on a encore plus de 40 % de PHP 5.6 au premier janvier 2021, on dégaine le jaune poussin !!
Sur Ouvadmin un bandeau va venir s'afficher sur le coté si au moins un espace web est en 5.6 sur le compte. C'est dans ma liste, mais j'ai pas encore travailé dessus.
Dites: et si on mettait en place d'autres dépôt fonctionnant sur le principe de celui-ci, pour lister les idées d'amélioration dans les autres domaines d'Ouvaton (ie : les autres groupes 1-4) ?
J'en dis que :
Tu me devances. Merci. C'est aussi mon avis. Ce dernier échange sur la duplication de ce dépôt, serait la transition pour le fermer. Je me dis que nous pourrions essayer d'ouvrir 3 autres dépôts (avec principe identique à celui-ci) et voir si cela fonctionne. Si l'un des dépôts ne fonctionne pas (ne permet pas d'être utilisé pour le but recherché), alors nous le fermeront. Je partirais sur cette idée d'ouvrir et voir.
Fermeture du ticket