Dans un certain nombre de projets, le "bug" est la particule élémentaire pour les travaux de développement. Là ce n'est pas le cas. Il n'y a pas non plus de merge requête ouverte, ni de tableau de suivi.
C'est assez étrange, je trouve. Quelqu'un en sait un peu plus ? C'est le projet de développement ultime ?
Ce n'est pas ironique, c'est mal exprimé. Ce que je veux dire c'est que là, on voit le projet complètement à jour de toutes les demandes, de toutes les remontées de bugs, sans aucune merge request ouverte. Je trouve ça super étrange :
d'un côté c'est bien et ça montre une hyper réactivité de l'équipe de dév
d'un autre côté, ça fait plus de 20 ans que je fais du développement et je n'ai jamais vu un projet aussi "à jour sur les demandes" et "sans aucuns travaux en cours" (genre tous les soirs les MR sont terminées).
Dit autrement : comment se fait-il que le projet Flask est aussi dynamique là où la majorité des projets libres ou professionnels ne sont jamais à ce niveau d'avancement entre demandes et réponses / corrections.
Beaucoup de ce qui est habituellement dans les bugs se trouve dans l'onglet discussions.
Leur PR ne sont pas des objets de travail habituels. Si tu regarde la durée de vie de PR est relativement petite. Leur politique encourage a retarder les PR.
Au final il semble que l'essentiel du travail est fait par David Lord et qu'il pousse à fond pour tout mettre dans les discussions et ne laisser que des bugs suffisamment qualifiés dans les issues.
Au final si on regarde les PR et les issues :
tu n'a pas forcément le travail en cours dans les PR (ça reste sur la machine du dev ou sur un fork du projet j'imagine)
tu n'a aucun faux bugs dans les issues
tu as des bugs dans les discussions elles ne sont justes pas encore qualifiées
Ne voyez pas de critique c'est juste comme ça que c'est organisé, c'est juste qu'il faut du coup l'avoir en tête quand on compare avec d'autres projets.
Ah oui donc c’est juste une autre moyen de sacrifier à la religion des indicateurs. Attention, je ne dis pas que c’est pas bien, ils ont simplement déporté la liste de ticket que les autres ont. Ce n’est pas une mauvaise idée en soit de mettre en œuvre un hall d’entrée qui permette de faire le tri et de caractériser avant de faire un ticket propre, ce qui signifie aussi qu’à la fin le ticket propre tu peux le mettre en lien quelque part et il est concis et efficace. Mais ça veut dire qu’à la fin, la liste d’issue et de PR ne sont pas du tout des indicateurs représentatifs (en comparaison avec d’autres projets qui fonctionnent différemment) car ce qui peut y être listé dans d’autres projets est intégralement externalisé.
Il y a aussi des projets qui ont des bug trackers externes, donc là aussi la liste de ticket est vide, elle est même absente. Ça rappelle simplement que la méthode GitHub n’est pas l’alpha et l’oméga des méthodes de travail et qu’on ne peut hâtivement supposer la représentativité de tel ou tel indicateur spécifique à la méthode GitHub.
ce commentaire est sous licence cc by 4 et précédentes
Je t’invite à questionner ton besoin de contradiction.
Ça peut juste être bien plus facile pour une équipe réduite de gérer comme ça.
J’ai écrit :
Ce n’est pas une mauvaise idée en soit de mettre en œuvre un hall d’entrée qui permette de faire le tri et de caractériser avant de faire un ticket propre.
Donc je répète : je t’invite à questionner ton besoin de contradiction.
Soit tu contredis en étant à côté de la plaque, soit tu répètes ce que celui à qui tu réponds a déjà dit… mais avec une formulation contradictoire. C’est quoi le but ?
ce commentaire est sous licence cc by 4 et précédentes
À part ici je n'ai rien vu qui faisait mention de ses indicateurs
Le titre de la publication à laquelle nous répondons tous, y compris toi:
Et c'est ce à quoi faisait référence le ici : la page sur la quelle nous sommes et qui n'a aucun lien avec les membres du projet. Je n'ai pas trouvé dans la communication du projet une mise en avant (ni même une évocation) de ses indicateurs. Donc je ne vois pas en quoi c'est :
Ah oui donc c’est juste une autre moyen de sacrifier à la religion des indicateurs.
Je crois que tu te perds dans ta propre réthorique
À part ici je n'ai rien vu qui faisait mention de ses indicateurs
Le titre de la publication à laquelle nous répondons tous, y compris toi:
Tu confonds des trucs comme:
- les questionnements de ce journal
- la politique du projet flask
Ce n'est pas parce que quelqu'un sur linuxfr se questionne vis à vis de certains indicateurs que le choix de fonctionnement du projet flask est un moyen de sacrifier à la religion des indicateurs.
Ce n'est pas parce que quelqu'un sur linuxfr se questionne vis à vis de certains indicateurs que le choix de fonctionnement du projet flask est un moyen de sacrifier à la religion des indicateurs.
À quel moment je dis que le projet flask sacrifie à la religion des indicateurs ?????
Tout ce que je dis c’est qu’il est possible à tout lecteur de cette discussion de sacrifier à la religion des indicateurs en appliquant la méthode de flask ou en évaluant les résultats de flask de cette manière.
C’est bien à ce journal que je réponds. Comme le dit barmic qui confirme encore qu’il fait des suppositions étranges pour contredire:
la page sur la quelle nous sommes et qui n'a aucun lien avec les membres du projet
Je réponds à la page sur laquelle nous sommes et qui n’a aucun lien avec les membres du projet.
Il ne faut pas se servir des suppositions et autres affirmations extrapolées de barmic sur ce que je dis pour interpréter ce que je dis.
La confusion est dans le commentaire de barmic qui donne a posteriori un sens différent à mon commentaire, c’est ce qui permet de nourrir sa contradiction complètement artificielle.
ce commentaire est sous licence cc by 4 et précédentes
L'équipe de mainteneurs est généralement très réactive, et en plus de cela le produit est plus ou moins stable. Le seul projet d'évolution dont j'ai entendu parler récemment, c'est la fusion avec Quart afin d'avoir un support natif de l'async.
Dans l'absolu le 0 ticket ouvert c'est impressionnant (en plus d'être satisfaisant), mais si on suit une ligne de conduite stricte et active, ça peut se faire bien, la preuve. Parmi les règles à suivre :
- N'avoir aucune pitié pour les tickets d'aide à l'utilisation
- Ne pas hésiter à envoyer bouler les propositions de fonctionnalité (exemple)
- Et enfin être super réactif sur les problèmes au sens de bogues ou risques de sécurité
Personnellement c'est un mode de gestion que je trouve tout à fait valable, surtout quand on considère à quel point les tickets sur les plateformes publiques sont à peu près tout le temps la foire.
En fait je n'arrive pas bien à comprendre pourquoi on mélange les rapports de bogues (truc qui cloche) et les demandes de fonctionnalités. Les deux devraient être séparés même en saisie parce que ce n'est pas du tout la même démarche.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Parce que multiplier les inputs pour les développeurs c'est contraignant. Une priorité 1 sur l'outil A est supérieure ou égale à une priorité A sur l'outil B ?
En soit particulièrement sur les petites équipes tout va devoir être nécessairement linéarisé.
Il existe des outils qui vont permettre d'avoir différentes entrées et d'ensuite mutualisé ça pour que tout ceux qui sont impliqué ai tout dans une seule vue. Le plus connu c'est jira.
Plus tu fais de la sophistication, plus tu as un travail de gestion (là le projet passe un certain temps à rappeler les règles et les faire appliquer). Chaque projet met en balance le gain et les inconvénients.
Parce que dans les 2 cas, il s'agit d'un travail, d'une tâche à réaliser. Il faut que le développeur corrige ou implémente quelque chose. La nature du travail reste relativement similaire, s'adresse aux mêmes personnes donc il y a une certain logique à tout garder ensemble.
J'entends bien vos arguments. Mais, c'est déconcertant quand tu dis, tiens ça serait bien que ça fasse ça et qu'on te sort "ben fais un rapport de bug". Ça passe bien côté développement, mais du côté des utilisateurs et utilisatrices de base, moins, la logique ne saute pas aux yeux. Il y a une ergonomie (ou un vocabulaire) à trouver. Fossils fait ça plutôt bien d'ailleurs.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
C'est un sujet de réflexion assez vaste. Ne serait-ce que dans les bugs : il y a les bugs en cours de documentation (on a constaté une anomalie, on souhaiterait la corriger mais il faut encore clarifier le problème) et un bug "prêt" qui est auto-suffisant pour être pris en charge par un développeur. Le fait d'avoir tout au même endroit simplifie la recherche d'information et le suivi mais génère du "bruit" lorsqu'on veut une vue d'ensemble.
Sur Tracim on s'est posé la question et aujourd'hui on a 3 "inputs" :
les demandes utilisateur / client qui arrivent par tout un tas de chemins (email, discussion, ticket, chat, espace communautaire, etc). Ces demandes sont "regroupées en vrac" dans un espace Tracim interne
une fois suffisamment claires, ces demandes sont introduites dans un doc de suivi (tableur) qui va permettre de prioriser ces demandes clients. on a environ 100 demandes aujourd'huis, bug et fonctionnalités confondues.
le travail de priorisation abouti à l'écriture de tickets (github) qui vont être pris en charge en terme de développement
Ce mode de fonctionnement permet notamment de conserver une base de travail publique (les ticket github, accessibles à tout un chacun) tout en travaillant en priorité sur les demandes faites par les clients (ceux qui paient nos salaires).
On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.
Cette description succinte ne prend pas en compte les bugs identifiés durant les phase de test et livraison de fin de sprint, qui sont dans un sas type "on le garde là pour le moment car si on peut le corriger dans la foulée, ça ne passera même pas par un ticket"
En écrivant ça, je me dis qu'on pourrait prévoir une conf sur le sujet du process de développement si ça intéresse des gens …
On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.
Justement, ticket n'est pas bogue… On peut même ne pas avoir d'erreur et avoir plein de tickets si l'outil sert à faire du support. À vérifier, mais il me semble que github avait introduit la possibilité d'étiquetage des issues (nom malheureux et confusionnant dans le cas présent)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
Pour Garradin, outre l'aide du logiciel. Il y a des listes de diffusion : entraide et support et Fossils. L'aide passe exclusivement par le site et les listes. D'ailleurs, il y a moins d'appels à l'aide depuis que la documentation sur le site est plus copieuse (encore heureux).
Il y a aussi des listes pour les dév. et l'auto-hébergement. La documentation développement est sur le wiki.
Concernant les bogues et demandes de fonctionnalités : ça passe soit par les listes de discussion, auquel cas, et cela peut faire l'objet de tickets dans Fossils, soit directement par des tickets dans Fossils. Il y a trois types de tickets :
Bug
Documentation
Demande de fonctionnalité
auxquels on affecte un facteur de sévérité.
Il y a un truc très important pour les rapports de bugs, c'est la qualité et la clarté d'utilisation du formulaire de saisie qui n'est pas toujours au rendez-vous.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
Et des cas comme ça tu en a pleins. Ça génère des discussions sur ce qu'est ou n'est pas une demande avec beaucoup de subjectivité et potentiellement de l'égo. Tu veux croiser les informations, les relier entre elles,… ne pas normalisé ça dans un seul outil ajoute de la complexité.
Tout ça pour des projets qui ont très peu de petites mains et dont le temps qu'ils ont à passer sur le projet n'est pas illimité. Tu peux considéré Flask comme étant maintenu par une seule personne (il y en a un qui fait 90% et 2 autres commiteurs qui contribuent un peu) qui développe, test, répond à tout le monde etc…
Si c'est pour que les utilisateurs ne soient pas trop surpris est-ce que tu pense que « ben ouvre un tiquet » est moins surprenant ?
Parce que d'un point de vue utilisateur la frontière entre un bug et une fearture request peut être fine. En gros, ça marche pas comme je le pense.
Parce que les outils ne font pas la différence : c'est un ticket. La différence peut se faire dans les champs à remplir ou dans les tags. Mais ça compte toujours pour 1 dans le total.
GH a introduit le concept de "discussions" qui pourrait délester la section issue des demandes d'aide et des discussion de nouvelles features. Peu de projets l'active de ce que je connais.
Parce que les contributeur n'ont qu'un seul endroit où aller voir. Et pas de resaisi à faire entre deux outils. Certains projets on un chat pour le support, un forum pour les discussions, un outil de tickets pour les bugs. C'est un choix valide aussi.
# 0 bug en cours
Posté par dovik (site web personnel) . Évalué à 5.
C'est d'autant plus impressionnant qu'il y a eu 75 millions de téléchargement juste sur le mois passé…
# Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 3.
Dans un certain nombre de projets, le "bug" est la particule élémentaire pour les travaux de développement. Là ce n'est pas le cas. Il n'y a pas non plus de merge requête ouverte, ni de tableau de suivi.
C'est assez étrange, je trouve. Quelqu'un en sait un peu plus ? C'est le projet de développement ultime ?
[^] # Re: Où se passe le suivi des développements ?
Posté par Ambroise . Évalué à 3. Dernière modification le 07 juillet 2022 à 08:34.
C'est peut-être ironique…
Mais il y a eu 2351 tickets fermés (https://github.com/pallets/flask/issues?q=is%3Aissue+is%3Aclosed) et 2206 pull requests fermées…
Il faut autre choses ? 🤔
[^] # Re: Où se passe le suivi des développements ?
Posté par gUI (Mastodon) . Évalué à 4. Dernière modification le 07 juillet 2022 à 08:37.
Et le dernier
commitc'était il y a 10 heures. Pas mal comme stats.En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
Ce n'est pas ironique, c'est mal exprimé. Ce que je veux dire c'est que là, on voit le projet complètement à jour de toutes les demandes, de toutes les remontées de bugs, sans aucune merge request ouverte. Je trouve ça super étrange :
Je sais pas si c'est plus clair …
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 4.
Dit autrement : comment se fait-il que le projet Flask est aussi dynamique là où la majorité des projets libres ou professionnels ne sont jamais à ce niveau d'avancement entre demandes et réponses / corrections.
C'est une vraie interrogation !
[^] # Re: Où se passe le suivi des développements ?
Posté par GG (site web personnel) . Évalué à 7.
Ouvre un ticket pour voir
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Où se passe le suivi des développements ?
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
:-D
[^] # Re: Où se passe le suivi des développements ?
Posté par nico4nicolas . Évalué à 9.
Ca a déjà été fait.
[^] # Re: Où se passe le suivi des développements ?
Posté par barmic 🦦 . Évalué à 10.
Beaucoup de ce qui est habituellement dans les bugs se trouve dans l'onglet discussions.
Leur PR ne sont pas des objets de travail habituels. Si tu regarde la durée de vie de PR est relativement petite. Leur politique encourage a retarder les PR.
Au final il semble que l'essentiel du travail est fait par David Lord et qu'il pousse à fond pour tout mettre dans les discussions et ne laisser que des bugs suffisamment qualifiés dans les issues.
Au final si on regarde les PR et les issues :
Ne voyez pas de critique c'est juste comme ça que c'est organisé, c'est juste qu'il faut du coup l'avoir en tête quand on compare avec d'autres projets.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Où se passe le suivi des développements ?
Posté par Thomas Debesse (site web personnel) . Évalué à 2.
Ah oui donc c’est juste une autre moyen de sacrifier à la religion des indicateurs. Attention, je ne dis pas que c’est pas bien, ils ont simplement déporté la liste de ticket que les autres ont. Ce n’est pas une mauvaise idée en soit de mettre en œuvre un hall d’entrée qui permette de faire le tri et de caractériser avant de faire un ticket propre, ce qui signifie aussi qu’à la fin le ticket propre tu peux le mettre en lien quelque part et il est concis et efficace. Mais ça veut dire qu’à la fin, la liste d’issue et de PR ne sont pas du tout des indicateurs représentatifs (en comparaison avec d’autres projets qui fonctionnent différemment) car ce qui peut y être listé dans d’autres projets est intégralement externalisé.
Il y a aussi des projets qui ont des bug trackers externes, donc là aussi la liste de ticket est vide, elle est même absente. Ça rappelle simplement que la méthode GitHub n’est pas l’alpha et l’oméga des méthodes de travail et qu’on ne peut hâtivement supposer la représentativité de tel ou tel indicateur spécifique à la méthode GitHub.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Où se passe le suivi des développements ?
Posté par barmic 🦦 . Évalué à 1.
À part ici je n'ai rien vu qui faisait mention de ses indicateurs. Ça peut juste être bien plus facile pour une équipe réduite de gérer comme ça.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Où se passe le suivi des développements ?
Posté par Thomas Debesse (site web personnel) . Évalué à 5.
Le titre de la publication à laquelle nous répondons tous, y compris toi:
Ce sont des indicateurs.
Je t’invite à questionner ton besoin de contradiction.
J’ai écrit :
Donc je répète : je t’invite à questionner ton besoin de contradiction.
Soit tu contredis en étant à côté de la plaque, soit tu répètes ce que celui à qui tu réponds a déjà dit… mais avec une formulation contradictoire. C’est quoi le but ?
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Où se passe le suivi des développements ?
Posté par barmic 🦦 . Évalué à 1.
Et c'est ce à quoi faisait référence le ici : la page sur la quelle nous sommes et qui n'a aucun lien avec les membres du projet. Je n'ai pas trouvé dans la communication du projet une mise en avant (ni même une évocation) de ses indicateurs. Donc je ne vois pas en quoi c'est :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Où se passe le suivi des développements ?
Posté par Psychofox (Mastodon) . Évalué à 5.
Je crois que tu te perds dans ta propre réthorique
Tu confonds des trucs comme:
- les questionnements de ce journal
- la politique du projet flask
Ce n'est pas parce que quelqu'un sur linuxfr se questionne vis à vis de certains indicateurs que le choix de fonctionnement du projet flask est un moyen de sacrifier à la religion des indicateurs.
[^] # Re: Où se passe le suivi des développements ?
Posté par Thomas Debesse (site web personnel) . Évalué à 3. Dernière modification le 09 juillet 2022 à 17:06.
À quel moment je dis que le projet flask sacrifie à la religion des indicateurs ?????
Tout ce que je dis c’est qu’il est possible à tout lecteur de cette discussion de sacrifier à la religion des indicateurs en appliquant la méthode de flask ou en évaluant les résultats de flask de cette manière.
C’est bien à ce journal que je réponds. Comme le dit barmic qui confirme encore qu’il fait des suppositions étranges pour contredire:
Je réponds à la page sur laquelle nous sommes et qui n’a aucun lien avec les membres du projet.
Il ne faut pas se servir des suppositions et autres affirmations extrapolées de barmic sur ce que je dis pour interpréter ce que je dis.
La confusion est dans le commentaire de barmic qui donne a posteriori un sens différent à mon commentaire, c’est ce qui permet de nourrir sa contradiction complètement artificielle.
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Où se passe le suivi des développements ?
Posté par ǝpɐןƃu∀ nǝıɥʇʇɐW-ǝɹɹǝıԀ (site web personnel) . Évalué à 5.
C'est peut-être un projet avec uniquement des bugs de Higgs ? Plus difficiles à caractériser que le bug commun .
« IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace
[^] # Re: Où se passe le suivi des développements ?
Posté par azmeuk (site web personnel) . Évalué à 3.
L'équipe de mainteneurs est généralement très réactive, et en plus de cela le produit est plus ou moins stable. Le seul projet d'évolution dont j'ai entendu parler récemment, c'est la fusion avec Quart afin d'avoir un support natif de l'async.
# Question de choix
Posté par Élafru . Évalué à 4.
Dans l'absolu le 0 ticket ouvert c'est impressionnant (en plus d'être satisfaisant), mais si on suit une ligne de conduite stricte et active, ça peut se faire bien, la preuve. Parmi les règles à suivre :
- N'avoir aucune pitié pour les tickets d'aide à l'utilisation
- Ne pas hésiter à envoyer bouler les propositions de fonctionnalité (exemple)
- Et enfin être super réactif sur les problèmes au sens de bogues ou risques de sécurité
Personnellement c'est un mode de gestion que je trouve tout à fait valable, surtout quand on considère à quel point les tickets sur les plateformes publiques sont à peu près tout le temps la foire.
[^] # Re: Question de choix
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
En fait je n'arrive pas bien à comprendre pourquoi on mélange les rapports de bogues (truc qui cloche) et les demandes de fonctionnalités. Les deux devraient être séparés même en saisie parce que ce n'est pas du tout la même démarche.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Question de choix
Posté par barmic 🦦 . Évalué à 2.
Parce que multiplier les inputs pour les développeurs c'est contraignant. Une priorité 1 sur l'outil A est supérieure ou égale à une priorité A sur l'outil B ?
En soit particulièrement sur les petites équipes tout va devoir être nécessairement linéarisé.
Il existe des outils qui vont permettre d'avoir différentes entrées et d'ensuite mutualisé ça pour que tout ceux qui sont impliqué ai tout dans une seule vue. Le plus connu c'est jira.
Plus tu fais de la sophistication, plus tu as un travail de gestion (là le projet passe un certain temps à rappeler les règles et les faire appliquer). Chaque projet met en balance le gain et les inconvénients.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Question de choix
Posté par nico4nicolas . Évalué à 3.
Parce que dans les 2 cas, il s'agit d'un travail, d'une tâche à réaliser. Il faut que le développeur corrige ou implémente quelque chose. La nature du travail reste relativement similaire, s'adresse aux mêmes personnes donc il y a une certain logique à tout garder ensemble.
[^] # Re: Question de choix
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 5.
J'entends bien vos arguments. Mais, c'est déconcertant quand tu dis, tiens ça serait bien que ça fasse ça et qu'on te sort "ben fais un rapport de bug". Ça passe bien côté développement, mais du côté des utilisateurs et utilisatrices de base, moins, la logique ne saute pas aux yeux. Il y a une ergonomie (ou un vocabulaire) à trouver. Fossils fait ça plutôt bien d'ailleurs.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Question de choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
C'est un sujet de réflexion assez vaste. Ne serait-ce que dans les bugs : il y a les bugs en cours de documentation (on a constaté une anomalie, on souhaiterait la corriger mais il faut encore clarifier le problème) et un bug "prêt" qui est auto-suffisant pour être pris en charge par un développeur. Le fait d'avoir tout au même endroit simplifie la recherche d'information et le suivi mais génère du "bruit" lorsqu'on veut une vue d'ensemble.
Sur Tracim on s'est posé la question et aujourd'hui on a 3 "inputs" :
Ce mode de fonctionnement permet notamment de conserver une base de travail publique (les ticket github, accessibles à tout un chacun) tout en travaillant en priorité sur les demandes faites par les clients (ceux qui paient nos salaires).
On est très loin du 0 bug (actuellement, c'est plus de 1700 tickets ouverts) ; mais c'est aussi un moyen de tracer le problèmes et de ne pas ignorer des problèmes remontés par le passé mais qu'on n'a pas (encore) eu le temps de traiter.
Cette description succinte ne prend pas en compte les bugs identifiés durant les phase de test et livraison de fin de sprint, qui sont dans un sas type "on le garde là pour le moment car si on peut le corriger dans la foulée, ça ne passera même pas par un ticket"
En écrivant ça, je me dis qu'on pourrait prévoir une conf sur le sujet du process de développement si ça intéresse des gens …
[^] # Re: Question de choix
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 4.
Justement, ticket n'est pas bogue… On peut même ne pas avoir d'erreur et avoir plein de tickets si l'outil sert à faire du support. À vérifier, mais il me semble que github avait introduit la possibilité d'étiquetage des issues (nom malheureux et confusionnant dans le cas présent)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Question de choix
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2. Dernière modification le 08 juillet 2022 à 06:57.
Oui on est bien d'accord :-)
[^] # Re: Question de choix
Posté par Ysabeau 🧶 🧦 (site web personnel, Mastodon) . Évalué à 3.
Pour Garradin, outre l'aide du logiciel. Il y a des listes de diffusion : entraide et support et Fossils. L'aide passe exclusivement par le site et les listes. D'ailleurs, il y a moins d'appels à l'aide depuis que la documentation sur le site est plus copieuse (encore heureux).
Il y a aussi des listes pour les dév. et l'auto-hébergement. La documentation développement est sur le wiki.
Concernant les bogues et demandes de fonctionnalités : ça passe soit par les listes de discussion, auquel cas, et cela peut faire l'objet de tickets dans Fossils, soit directement par des tickets dans Fossils. Il y a trois types de tickets :
auxquels on affecte un facteur de sévérité.
Il y a un truc très important pour les rapports de bugs, c'est la qualité et la clarté d'utilisation du formulaire de saisie qui n'est pas toujours au rendez-vous.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Question de choix
Posté par barmic 🦦 . Évalué à 3.
C'est pas si simple. La frontière peut être ténue entre un bug et une nouvelle fonctionnalité.
Si on reprend la discussion récente qu'on a eu avec Thomas Debesse est-ce que bien se comporter avec plus de 32Gio de RAM c'est une évolution du logiciel ou est-ce que c'est un bug ?
Et des cas comme ça tu en a pleins. Ça génère des discussions sur ce qu'est ou n'est pas une demande avec beaucoup de subjectivité et potentiellement de l'égo. Tu veux croiser les informations, les relier entre elles,… ne pas normalisé ça dans un seul outil ajoute de la complexité.
Tout ça pour des projets qui ont très peu de petites mains et dont le temps qu'ils ont à passer sur le projet n'est pas illimité. Tu peux considéré Flask comme étant maintenu par une seule personne (il y en a un qui fait 90% et 2 autres commiteurs qui contribuent un peu) qui développe, test, répond à tout le monde etc…
Si c'est pour que les utilisateurs ne soient pas trop surpris est-ce que tu pense que « ben ouvre un tiquet » est moins surprenant ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Question de choix
Posté par steph1978 . Évalué à 2.
J'y vois plusieurs raisons.
Parce que d'un point de vue utilisateur la frontière entre un bug et une fearture request peut être fine. En gros, ça marche pas comme je le pense.
Parce que les outils ne font pas la différence : c'est un ticket. La différence peut se faire dans les champs à remplir ou dans les tags. Mais ça compte toujours pour 1 dans le total.
GH a introduit le concept de "discussions" qui pourrait délester la section issue des demandes d'aide et des discussion de nouvelles features. Peu de projets l'active de ce que je connais.
Parce que les contributeur n'ont qu'un seul endroit où aller voir. Et pas de resaisi à faire entre deux outils. Certains projets on un chat pour le support, un forum pour les discussions, un outil de tickets pour les bugs. C'est un choix valide aussi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.