Pods: Étiquettes GitHub

~ « Needs Changelog » comme étiquette pourrait peut-être disparaître. J'ai intégré les mises à jour du journal des modifications au processus de fusion et je n'ai pas utilisé cette étiquette de courte durée.~
Terminé

Je n'ai pas eu le temps de passer au peigne fin, mais je ne vois rien de flagrant d'emblée dans un premier écumage. Je peux trouver quelques ajustements, omissions, suppressions sur une passe solide, mais mon instinct est que ce serait une énorme amélioration par rapport au système d'étiquettes actuel tel que proposé.

"Patch" est celui que je n'ai jamais utilisé dans mon flux de travail, car il me semble redondant. Si c'est un PR, alors c'est un patch. Mais @sc0ttkclark a traditionnellement utilisé cette étiquette, elle peut donc avoir une valeur de workflow pour lui.

~ Component: Multi-site serait un bon ajout, c'est un autre domaine comme l'API REST et les modèles qui seraient utiles pour commencer à marquer à des fins de filtrage.~

Terminé

Focus : rétrocompatibilité
Focus : Compatibilité/Dépréciation
Focus : Compatibilité

Pour ces trois, peut-être affinés :

Focus: Backward Compatibility
Focus: Deprecation
Focus: Third Party Compatibility

Edit : c'est fait

En plus de ces petites choses jusqu'à présent, je suis tout à fait GO là-dessus. La classification est bien meilleure et j'aimerais l'utiliser bien que 2.7.7.

Je veux d'abord obtenir un avis explicite de @jimtrue et @sc0ttkclark .

Quelle est la différence entre Discussion et Team Discussion ? Pourraient-ils être remplacés par Needs: Developer Feedback ?

Qu'est-ce que Integration ?

Voici mon deuxième passage. Quelques nouveaux ajouts/modifications. Ceux avec des points d'interrogation principaux pourraient être abandonnés s'ils ne sont pas utilisés :

Closed: Could not reproduce
Closed: Duplicate
Closed: Invalid
Closed: Out of scope
Closed: Won't Fix

Component: CSS
Component: docs.pods.io
Component: DFV
Component: Front-end Forms
Component: Multisite
Component: Pods Templates/Magic Tags
Component: REST API
Component: support.pods.io
Component: UI
Component: Unit Testing
Component: WP Admin

Focus: Accessibility
Focus: Backward Compatibility
Focus: Deprecation
Focus: Third-Party Compatibility
Focus: I18n
? Focus: Integration
Focus: Performance

? Keyword: Discussion
Keyword: Focus
Keyword: Forums
Keyword: Friends of Pods Priority
Keyword: Good First Issue
Keyword: Has Bounty
? Keyword: Patch: Manually Merged
? Keyword: Patch
Keyword: Plugin Material
Keyword: Puntable
Keyword: Release
Keyword: Support
? Keyword: Team Discussion
Keyword: Tools
Keyword: VIP

Needs: Developer Feedback
Needs: Research
Needs: Tasklist
Needs: Test(s)
Needs: User Feedback
Needs: Verification/Reproduction
Needs: Votes

Priority: Blocker

Type: Bug
Type: Code Standards
Type: Inline Documentation
Type: Enhancement
Type: Feature
Type: Refactor
? Type: Regression

Status: Fixed / Needs Testing
Status: Help Wanted
Status: Hold
Status: In progress
Status: Pulled for Review
Status: Ready for merge
Status: Ready for review
Status: Researched
Status: Unit Tested
Status: Verified/Reproduced

Quelle est la différence entre la discussion et la discussion en équipe ? Pourraient-ils être remplacés par Needs : Developer Feedback ?

Pas grand-chose, la discussion serait ouverte sur le monde et la discussion en équipe serait interne. Je ne pense pas que nous ayons besoin d'une étiquette de discussion aussi précise et générique (la duplication était probablement involontaire). Les commentaires des développeurs sont généralement utilisés comme statut, généralement un ticket qui était réservé aux commentaires des utilisateurs et qui a obtenu ces commentaires.

Qu'est-ce que l'intégration ?

Principalement des demandes de fonctionnalités impliquant l'intégration avec d'autres plugins, bibliothèques, thèmes, etc. Je suppose que les bogues sur l'intégration existante peuvent tomber sous ce parapluie, mais ils sont souvent plus appropriés en tant que "compatibilité" une fois que nous avons l'intégration. (donc l'intégration peut-être un type bien que cela ait peut-être plus de sens dans Focus comme vous l'avez fait)

Je ne suis pas sûr que la section « Besoins : » soit meilleure... J'ai aimé l'idée de ces éléments dans le cadre de « Statut : » car je pense que c'est souvent ainsi qu'ils sont utilisés.

Edit : tout a été réglé

~Je pense que les mots-clés suivants pourraient en fait être de type : version, support et outils.~

~Ceux-ci semblent être des types de billets qui ne sont pas bien décrits par les autres.~

Terminé

De plus, pour le plaisir de faire défiler, je me demande si nous devrions simplement garder la liste du message initial à jour plutôt que de publier de nouvelles versions au fur et à mesure?

Terminé.

J'aime l'idée de ceci :

Besoins : commentaires des développeurs
Besoins : Recherche
Besoins : liste des tâches
Besoins : Test(s)
Besoins : commentaires des utilisateurs
Besoins : Vérification/Reproduction
Besoins : Votes

Mais les « Retours d' utilisateurs » et « Vérification/Reproduction » sont vraiment « état/flux de travail » comme

Le workflow d'état devrait idéalement se réduire aux couloirs du projet. En regardant cette liste de labels, je n'avais AUCUNE idée que nous en avions autant, mais je suppose que vous en avez créé une poignée de plus.

support.pods.io et docs.pods.io ne devraient pas être du tout ici (nous avons des dépôts pour ces deux sites Web), à moins que nous prévoyions d'utiliser GitHub pour les mises à jour de support et de documentation. Si nous allons faire cela (ce pour quoi je suis TOUS), alors nous ajoutons un préfixe pour Docs: et Support: et créons deux projets dans GitHub dans ce référentiel pour le support et la documentation. Étant donné qu'un problème de support peut parfois se transformer en une amélioration/fonctionnalité de code ou une correction de bogue, il est logique que nous utilisions la même interface. Bien sûr, nous en aurons plus, mais nous veillerons également à obtenir exactement ce dont nous avons besoin pour les problèmes de support et les mises à jour de la documentation.

J'ai regardé ceci et j'aimerais voir les changements suivants :

• Type : Ajouter Support & Docs Update (retirer Support de Keyword )
• Composant : nous n'avons pas besoin de support.pods.i o ou de doc.pods.io dans Component . Ces deux dépôts ont leurs propres projets. Le composant doit être entièrement destiné au domaine d'intérêt Pods Core.
• Priorité : Déplacez Focus du mot-clé vers Priority . Blocker est bien tant que nous connaissons la raison, qui devrait provenir de Needs .

Donc, si je suis bien, tout devrait avoir un :
Type : Définit de quel type de ticket il s'agit.
Statut : Définit où il se trouve dans le Workflow. Petite discussion sur ce que le statut devrait être « Bloqué » ou « À faire » ou « En attente » si nous avons besoin des commentaires des utilisateurs ou d’une vérification/reproduction. Je ne sais pas quel serait le statut pour la demande de fonctionnalité/amélioration où les besoins sont des votes. Peut-être que ceux-ci suivent le même format pour un tableau Kanban typique et leur statut est BackLog jusqu'à ce qu'il soit activement travaillé. Le bloqueur indique qu'il ne peut pas être utilisé tant que les besoins ne sont pas traités.
Composant : détermine la zone de Pods Core pour la fonctionnalité/l'amélioration/le bogue
Le mot - focus sont juste pour des éclaircissements supplémentaires ?

J'ai supprimé WaffleBot afin que ces statuts ne soient plus ajoutés automatiquement.

Le bloqueur indique qu'il ne peut pas être utilisé tant que les besoins ne sont pas traités.

Voici un cas où nous n'utilisons pas une étiquette avec les mêmes intentions. J'ai toujours utilisé Blocker (et je pense que Scott également) pour les problèmes qui bloquent une version (ou peut-être un autre ticket) et doivent être résolus ; ne peut pas être botté.

Il n'y a aucune raison dans mon flux de travail pour que je marque quelque chose comme étant en attente de quelque chose via 'Blocker'... les étiquettes d'état actuelles devraient l'impliquer. Je n'ai pas besoin de "Besoin de commentaires d'utilisateurs" plus "Bloqueur", car le premier me dit déjà qu'il bloque et pourquoi.

Mon vote est que nous l'utilisons de cette façon et le gardons sous "Priorité : *" car c'est une description parfaite pour moi.

~Je pense que "Focus" devrait également passer de Mots-clés à Priorité.~ Laisser dans les mots-clés

J'aime l'idée de ceci :

Besoins : commentaires des développeurs
Besoins : Recherche
Besoins : liste des tâches
Besoins : Test(s)
Besoins : commentaires des utilisateurs
Besoins : Vérification/Reproduction
Besoins : Votes

Ce sont principalement des statuts de ticket pour moi, donc je propose de les garder là pour le moment. Si la longueur est le problème, nous pouvons en abréger certaines ("Status : Need Dev FB", "Status : Need Verification/Repro").

Je pense que la "liste des tâches des besoins" peut disparaître. Je ne pense pas que cela arrive assez pour justifier une étiquette. Je ne suis pas sûr de l'avoir déjà utilisé, rarement si c'est le cas. Probablement idem pour "Needs Tests". Les autres me conviennent parfaitement sous "Status : *".

De plus, la liste s'annonce bien pour moi, nous devrions probablement discuter de la palette de couleurs.

Quelques autres qui peuvent probablement être supprimés des statuts avec la « liste des tâches des besoins » :

• ~"Pulled for Review" n'est probablement qu'une duplication involontaire de "Ready for Review"~ Le laisser
• "Unité testée" n'est pas un statut (pas encore du moins), plus divers... donc probablement déplacé vers Mots-clés ?

Cela me laisse la liste des statuts en bon état.

« Pulled for Review » n'est probablement qu'une duplication involontaire de « Ready for Review »

Être en désaccord. Si je crée un PR, alors quand il est prêt, j'ajouterais Prêt pour la révision. Mais vous n'aurez peut-être pas le temps de faire cet examen plus tard - mais à ce moment-là, Scott ne sait pas si vous avez commencé l'examen ou non. En bref, ce sont deux groupes différents de personnes qui ajoutent Ready for Review et Pulled for Review.

Probablement idem pour "Needs Tests".

Par souci de vouloir plus de couverture de code (bien que je n'aie pas encore beaucoup examiné ce domaine personnellement), cette étiquette pourrait être pour dire que "le correctif est bon, mais nous aimerions voir les tests unitaires couvrir les bords / vérifier le correctif de bogue spécifique afin qu'aucune régression ne soit introduite".

Je pense que "Focus" devrait également passer de Mots-clés à Priorité.

Les priorités seraient généralement - faible, moyenne, élevée, critique, bloqueur - elles ont une sémantique différente (dans mon esprit du moins) de Focus. Une étiquette Keyword: Focus n'a aucune pertinence en soi, à moins qu'il n'y ait un jalon pour dire quelle version le problème est un focus _for_. Alors qu'une priorité est sans contexte, dans la mesure où elle s'applique à l'ensemble du projet. Je ne pense pas nécessairement que l'ajout des autres priorités soit une bonne idée, mais je ne pense pas non plus que Focus soit une priorité. Peut-être que ce que nous essayons de dire, c'est que "ce billet est un point culminant d'un jalon - un gros cadeau à crier lors de la prochaine sortie", et si c'est le cas, un mot différent de Focus peut être mieux pour signaler l'intention.

Le bloqueur indique qu'il ne peut pas être utilisé tant que les besoins ne sont pas traités.

Je suis d'accord avec Phil ici - j'ai compris que cela signifiait que le problème qui a cette étiquette est un bloqueur à un _release_. Peut-être que l'explication de Jim serait mieux adaptée à une étiquette Status: Is Blocked ou similaire, bien qu'une Needs: * indiquerait la même chose.

BTW, est-il possible de supprimer la liste provisoire ici : #5016 (commentaire) ?

@pglewis Allez-y et supprimez (ou cachez dans <details>...</details> pour référence historique) tout ce que vous voulez.

support.pods.io et docs.pods.io ne devraient pas être du tout ici

C'est moi qui les ai ajoutés en raison de l'incertitude concernant la balise "Docs Improve" existante (vs Docs: inline) - ils peuvent être supprimés s'ils sont traités ailleurs.

L'amélioration des documents pourrait être mieux écrite sous la forme « Docs : Inline » « Docs : Exemples » « Docs : Info-bulles » et ce genre de chose. À moins que nous ne traitions le flux de travail de la documentation (c'est-à-dire la documentation écrite sur le site Web docs.pods.io) dans GitHub, il n'y a aucune raison pour cela ici. Toute amélioration de la documentation à l'intérieur de notre code signifie que la documentation est _dans_ notre code ou gérée dans notre code ou comme le fichier readme qui est analysé et poussé vers le dépôt du plugin WordPress.org.

J'aime le Status: Is Blocked car c'est très informatif, mais si vous faites quelque chose de cette nature, cela nécessite également un Besoins :*

Comme je l'ai dit, tout obtient un Type et un Status . Jusqu'à ce que nous fassions une gestion de projet Agile complète avec GitHub, les priorités n'ont pas besoin d'être définies ici et sont en fait mieux représentées par les unités de travail nécessaires pour faire « l'histoire » faite. Nous avons toujours utilisé Focus pour différencier les éléments parmi les centaines de problèmes qui doivent être ciblés dans la prochaine version de maintenance.

Mes seules pensées concernent les étiquettes UI/CSS, car ce sont celles avec lesquelles je traite le plus... Je ne sais pas si vous avez des idées là-dessus, mais CSS est le résultat, pas la chose tangible qui doit être corrigée... si cela a du sens. L'interface utilisateur serait la chose tangible sur laquelle travailler ou améliorer, le CSS serait le résultat ou la façon dont il a été corrigé. Sinon j'aime bien

Mes seules pensées concernent les étiquettes UI/CSS, car ce sont celles avec lesquelles je traite le plus... Je ne sais pas si vous avez des idées là-dessus, mais CSS est le résultat, pas la chose tangible qui doit être corrigée... si cela a du sens. L'interface utilisateur serait la chose tangible sur laquelle travailler ou améliorer, le CSS serait le résultat ou la façon dont il a été corrigé.

Oui, il y a du raffinement à faire là-bas. J'ai principalement utilisé l'étiquette CSS comme signal Bat pour vous et/ou Jory sur lequel filtrer depuis que vous êtes les personnes de référence dans cette direction.

Je voterais pour laisser CSS et UI tels que proposés pour l'instant, mais nous pouvons certainement continuer à les affiner après la phase I.

RE : Nécessite des tests

Par souci de vouloir plus de couverture de code (bien que je n'aie pas encore beaucoup examiné ce domaine personnellement), cette étiquette pourrait être pour dire que "le correctif est bon, mais nous aimerions voir les tests unitaires couvrir les bords / vérifier le correctif de bogue spécifique afin qu'aucune régression ne soit introduite".

La réalité est que nous devons suivre les correctifs de maintenance, travailler sur une branche de publication, et la barrière à l'écriture de nouveaux tests est plutôt élevée, même pour des choses simples. Nous pouvons laisser l'étiquette là-bas, mais elle ne sera probablement pas beaucoup utilisée tant que beaucoup plus de refactorisation n'aura pas été effectuée, que nous introduisons de vrais tests unitaires et/ou que nous ayons plus de ressources à y consacrer.

Un « Type : Tests » serait un bon ajout, car pour le moment, les tests ajoutés sont probablement les meilleurs en tant que leurs propres paires problème/PR.

J'aime le statut : est bloqué car c'est très informatif, mais si vous faites quelque chose de cette nature, cela nécessite également un besoin :*

Je vais bien le laisser, mais je suis principalement celui qui suit les statuts et je n'ai jamais eu besoin de marquer quoi que ce soit "est bloqué" comme statut. Tout ce qui est vaguement dans cette direction que je rencontre est mieux couvert par "Holding".

Et au cas où cela aiderait à clarifier quelque chose, voici le flux de travail typique que j'utilise sur un bogue moyen :

• Triage : filtrer les invalides, le support, la fonctionnalité/l'amélioration ; définir le type sur bogue
• Normalement, le statut passe immédiatement à "besoin de vérifier/repro"
• Peut aller et venir entre « besoin des commentaires des utilisateurs » et « besoin des commentaires des développeurs » tout au long de la durée de vie
• Vérifié/Reproduit
• Besoin de recherche : maintenant que nous savons comment y parvenir, découvrez et comprenez pourquoi
• Recherche : je suis probablement le seul à l'utiliser. Signale qu'une plongée profonde a été effectuée à un moment donné et que j'ai probablement des détails internes stockés dans ma tête
• Correction / Nécessite des tests

Être en désaccord. Si je crée un PR, alors quand il est prêt, j'ajouterais Prêt pour la révision. Mais vous n'aurez peut-être pas le temps de faire cet examen plus tard - mais à ce moment-là, Scott ne sait pas si vous avez commencé l'examen ou non. En bref, ce sont deux groupes différents de personnes qui ajoutent Ready for Review et Pulled for Review.

Je pense que le label Hold a toujours été meilleur que Pulled for Review dans ces cas.

Pour info, dans le passé, j'ai utilisé Blocker pour indiquer un problème qui bloque une version.

Nous pouvons supprimer « Patch », j'ai commencé à l'utiliser lorsque GitHub avait une expérience utilisateur plus confuse entre les PR et les problèmes, il était plus facile de voir la vue « Release » avec les correctifs principalement pour revenir sur les éléments du journal des modifications. Nous n'en avons pas besoin.

La liste dans la description du problème d'origine est-elle à jour avec les changements dont nous avons tous discuté ?

La liste dans la description du problème d'origine est-elle à jour avec les changements dont nous avons tous discuté ?

Probablement pas complètement, n'hésitez pas à en affiner si vous le souhaitez. Je passerai en revue une fois que nous aurons le pouce levé et que nous passerons au peigne fin tout ce que nous avons décidé qui n'a pas été mis à jour.

Quoi que nous décidions ici, nous devons appliquer à tous nos autres dépôts de Pods à l'aide d'un outil tel que https://github.com/dwyl/labels pour les synchroniser.

Déplacement de « Régression » du type vers les mots-clés. Le bug est toujours le type de problèmes de régression.

Ceci est à peu près mis en œuvre maintenant. Quelques choses diverses que je viens de coller sous "Mots clés" pour l'instant.

Les couleurs sont la principale chose à travailler à ce stade.

?Fermé : invalide

Je suggérerais de garder au moins celui-ci, peut-être aussi le Won't Fix. Ce sont des résolutions assez standard sur d'autres trackers de bogues.

Les couleurs sont la principale chose à travailler à ce stade.

Les couleurs sont secondaires à ce stade - implémentez les étiquettes et décidez d'un schéma de couleurs plus tard.

Je suggérerais de garder au moins celui-ci [Invalid], peut-être aussi le Won't Fix. Ce sont des résolutions assez standard sur d'autres trackers de bogues.

J'ajouterai Invalide, je viens de le marquer comme rappel car nous ne l'avions pas déjà.

"Won't Fix" est l'un de ceux dont je déteste le ton. De plus, mon attitude est que nous devrions avoir une étiquette avec une meilleure raison spécifique pour ne pas réparer quelque chose que "Won't Fix".

Les couleurs sont secondaires à ce stade - implémentez les étiquettes et décidez d'un schéma de couleurs plus tard.

Les étiquettes sont à peu près implémentées.

Avons-nous besoin d'un "Type : GitHub" ou quelque chose de similaire ? Ce problème n'a pas de type.

Type: Project ?

Et si au lieu de « Won't Fix » nous utilisions « Laisser tel quel » ou quelque chose comme ça ?

Et si au lieu de « Won't Fix » nous utilisions « Laisser tel quel » ou quelque chose comme ça ?

C'est une situation rare donc nous l'avons fait si longtemps sans avoir besoin de quelque chose comme ça. Je vote pour attendre d'ajouter quoi que ce soit jusqu'à ce qu'un exemple spécifique se présente.

De plus, j'ai pris des décisions de couleur arbitraires pour certains des groupes. Rien n'y est gravé dans le marbre.

Je pense que nous pouvons probablement clore ce problème à ce stade et discuter de toute amélioration supplémentaire via Slack.

What if instead of "Won't Fix" we used "Leave as is" or something like that?

C'est une situation rare donc nous l'avons fait si longtemps sans avoir besoin de quelque chose comme ça. Je vote pour attendre d'ajouter quoi que ce soit jusqu'à ce qu'un exemple spécifique se présente.

Je suis d'accord. Tout ce que fait WordPress core n'a pas besoin d'être dupliqué

Je suis d'accord. Tout ce que fait WordPress core n'a pas besoin d'être dupliqué

C'est également l'un des libellés par défaut lors de la configuration d'un nouveau dépôt sur GH - voir https://github.com/GaryJones/daterange/labels qui contient les libellés par défaut.

I agree. Not everything that WordPress core does needs to be duplicated

C'est également l'un des libellés par défaut lors de la configuration d'un nouveau dépôt sur GH - voir https://github.com/GaryJones/daterange/labels qui contient les libellés par défaut.

Je ne me souviens pas quand c'est devenu une valeur par défaut pour GitHub, mais cela a toujours été une étiquette terrible à attacher à un ticket d'un contributeur bénévole. J'ai vu très peu de problèmes sur GitHub avec cette balise, mais dans le monde WordPress, la plupart des tickets non corrigés sont couverts par un autre problème, ont besoin de plus d'informations pour justifier un correctif, ou tout simplement en espérant que personne ne revienne se plaindre (souvent le cas) .

Je m'en tiendrai à mon aversion. Ma question immédiate sur « Won't Fix » est « Pourquoi refuserions-nous de réparer quelque chose ? » Et si quelqu'un me donne une bonne réponse concise à cela sur un ticket, je dirais _c'est ce que l'étiquette devrait lire plutôt que « ne réparera pas ».

Je pense que Out of Scope est une meilleure réponse de toute façon. Won't Fix implique et ne fournit « rien » à la personne qui ouvre le problème.

peut-être que cela pourrait aller dans le sens - n'hésitez pas à soumettre une "solution" mais l'équipe n'a pas assez de ressources pour le faire :D peut-être que quelqu'un a une idée d'abréviation courte pour cela ^^

Un cas d'utilisation peut être un bogue ou une violation de CS dans une fonctionnalité, qui est de toute façon en train d'être réécrit et publié dans la prochaine version.

N'hésitez pas à le laisser de côté cependant.