Comment gérer les problèmes de github pour (priorité, etc.)? [fermé]

49

Je suis nouveau sur github et je cherche des conseils sur la façon de gérer les problèmes. Je suis habitué à avoir la priorité et d'autres options de commande mais vois qu'il n'en existe aucune.

Comment les autres gèrent-ils les problèmes durant le cycle de vie d'un bogue / d'une fonctionnalité?

Merci d'avance.

project-management github issue-tracking

— djf
source

1

D'après les réponses, cela ne semble pas être trop basé sur l'opinion - les deux premiers couvrent à peu près les mêmes détails (avec un troisième plus de réponses qui couvrent également ces mêmes détails - quelques trucs et astuces post - et une publication pour un service tiers qui pourrait ajouter plus des fonctionnalités manquantes). - On dirait que c'est un très bon choix pour le format de questions-réponses de SO, ce n'est pas du tout basé sur des opinions, mais simplement "où est la fonctionnalité X", et les gens ont répondu. - J'espère que cette question sera ré-ouverte afin que quelqu'un puisse obtenir le crédit du répondeur.

— BrainSlugs83 le

52

Vous pouvez définir différents groupes d'étiquettes comme types d'émission , les priorités d'émission , les statuts d'émission , les étiquettes de version , et peut - être plus. Pour pouvoir voir instantanément à quel groupe une étiquette appartient, vous pouvez utiliser une convention de dénomination telle que <label-group>:<label-name>.

L'utilisation d'une telle convention de nommage devrait faciliter la gestion des problèmes de Github et aider les autres à "comprendre" les problèmes beaucoup plus rapidement. Notez que vous pouvez également attribuer des couleurs aux étiquettes, ce qui peut améliorer encore la lisibilité (j'utiliserais une couleur spécifique pour chaque groupe d'étiquettes). Mais comme vous devez toujours attribuer / désattribuer manuellement ces étiquettes aux problèmes, vous pouvez garder la liste globale des groupes / étiquettes réduite.

Selon le schéma suggéré ci-dessus, vous pouvez définir les groupes et les étiquettes correspondantes comme suit.

groupe 'type d'émission'

type: bug
type: caractéristique
type: idée
type: invalide
type: support
type: tâche

groupe 'priorité'

prio: faible
prio: normal
prio: élevé

groupe 'état des problèmes'

(Ces étiquettes décrivent l'état d'un problème dans un flux de travail défini.)

Statut: Confirmé
statut: différé
statut: corrigé
statut: en cours
statut: incomplet
statut: rejeté
statut: résolu

groupe 'émission d'informations'

info: commentaires nécessaires
info: besoin d'aide
info: progrès-25
info: progrès-50
info: progrès-75

groupe 'version tag'

ver: 1.x
ver: 1.1

— Jonny Dee
source

2

Mais cela ne résout pas le tri, n'est-ce pas?

— Pavel S.

4

Bonjour, je viens de remarquer votre question sur MSO. La question a été automatiquement supprimée car il s'agissait d'une migration rejetée. Toutefois, la copie originale de Stack Overflow ayant également été supprimée, il ne restait aucune copie de la question ni de ses réponses. Je ne vois aucune raison de ne pas en avoir au moins une copie, même fermée, et j'ai donc supprimé celle-ci. La prochaine fois que vous voudriez discuter d'un problème spécifique aux programmeurs, merci de le signaler aux méta-programmeurs , il m'est arrivé de voir votre question MSO par accident.

— Yannis

@YannisRizos: Vous êtes absolument génial (+1). Merci beaucoup pour votre réponse rapide, pour sa suppression, et aussi pour vos éclaircissements :)

— Jonny Dee

Je voudrais juste ajouter qu'avoir info: progress-X est excessif. Je suis d’accord avec une info: en cours mais quantifier les progrès est un peu exagéré. J'ai eu quelques problèmes que je pensais avoir terminés à 90%, puis j'ai vu quelque chose et je savais que je n'avais terminé qu'à 50%. Maintenant, avoir ceci sur github serait juste une perte de temps à mon avis.

— AntonioCS

22

Le suivi des problèmes GitHub est assez flexible. Il n'y a en effet pas de priorité, ni de commande. Il s'articule autour de trois grands piliers: affectations , libellés et jalons .

Vous pouvez "baliser" les problèmes avec les étiquettes que vous créez (de manière similaire aux étiquettes de Gmail). Par exemple: "bogue", "demande de fonctionnalité", "tâche", "question", ... Un problème peut être étiqueté avec des étiquettes différentes.
Vous pouvez "regrouper" plusieurs problèmes dans un jalon . Un jalon est composé d'un titre (un numéro de version, par exemple) et d'une date de livraison facultative.
Chaque problème peut être attribué à un collaborateur (contributeur ou membre d'organisation) du référentiel. Vous pouvez même appeler un collaborateur dans un commentaire en utilisant un @suivi de son identifiant GitHub.

Finalement, grâce à la barre latérale, vous pouvez "filtrer" la liste des problèmes pour vous aider à le gérer.

Un article de blog complet "Issues 2.0" sur ce sujet vous donnera une vue plus détaillée des fonctionnalités.

— nulltoken
source

1

Très utile, merci. Il me semble que je devrai désapprendre ma «vieille» méthode de gestion des problèmes. Abandonnez-vous simplement la notion de priorisation? Normalement, je passerais en revue une liste de bogues, assignerais des priorités qui seraient ensuite assignées aux développeurs. Comment modifier ma pensée en tant que manager? Il me semble que je vais devoir passer plus de temps à examiner les problèmes que j'ai déjà examinés et mis à terre dans les priorités. Des suggestions ou peut-être un pointeur vers des exemples seront appréciés.

— djf

1

@djf comme dans la réponse de Johnny Dee, vous pouvez utiliser des étiquettes pour attribuer une priorité.

— David Brown

8

J'utilise huboard.com pour représenter les problèmes de github sous forme de tableau Kanban, puis je les trie en les faisant glisser au sein de huboard. Cela fonctionne plutôt bien si vous souhaitez uniquement visualiser la priorité et savoir quoi travailler ensuite.

En fait, il stocke la priorité dans le problème lui-même, sous forme de commentaire HTML:

Your normal issue text here...
<!---
@huboard:{"order":465.0}
-->

— joseph.hainline
source

J'utilise maintenant waffle.io à cette fin. C'est un peu mieux.

— joseph.hainline

5

Exemple d'utilisation des étiquettes sur github pour gérer nos projets

Étiquettes de catégorie (peuvent également utiliser des majuscules pour séparer visuellement)

Tâche
Punaise
Fonctionnalité
Discussion

Label prioritaire

URGENT

Nous considérons que tout a une priorité normale et ne voyons pas vraiment le besoin de "faible". Cela ne laisse donc qu'une étiquette pour marquer les choses qui nécessitent une attention immédiate.

Étiquettes d'état

examiné (le cessionnaire l'a lu)
en file d'attente (le cessionnaire y travaillera bientôt)
travail en cours (le cessionnaire travaille dessus maintenant)
invalide (si bug ce n'est pas reproductible)
besoin de feedback (signal de chauve-souris pour amener les gens à lire et à commenter ou à fournir de l'aide)

Nous conservons toute la documentation dans un wiki, y compris les procédures, l'architecture, l'infrastructure, les études de cas, la planification et les exigences.

Les demandes d'extraction sont destinées à la révision du code et à la discussion des fonctionnalités si elles font partie d'une branche.

Avec une utilisation créative du filtrage, nous pouvons trouver le travail que nous devons faire pour la journée. "Task + URGENT" ou "Bug + URGENT" examine toujours les problèmes identifiés comme "besoin d'un commentaire" et laisse un commentaire même si tu n'as rien à ajouter. Bien sûr, cela fonctionne avec notre équipe de cinq personnes, mais probablement pas beaucoup plus que cela.

— Brian Boatright
source

1

Je choisis deux types d’étiquettes pour les problèmes de GH: le premier concerne le type de problème et le second la priorité:

punaise
feature - (nouveauté)
amélioration - (amélioration des éléments existants)
question / discussion - (discuter de choses)

Une question / discussion peut ne pas être nécessaire si vous utilisez bien le wiki. Mais j'aime bien parce que cela me permet de poser une question ou une idée à une personne en particulier.

Ensuite, il y a trois étiquettes de priorité très simples:

maintenant
bientôt
plus tard

Facile, non?

— Ryan Kinal
source

1

En plus des solutions de marquage suggérées ci-dessus, nous avons blockinget blockedcomme étiquettes.

Un problème doit d'abord être attribué à la bonne personne, mais si cette personne est incapable de travailler sur le problème jusqu'à ce qu'un autre problème soit terminé, le problème est marqué comme blocked. Et l'autre problème est référencé à l'aide d'une balise de hachage.

De même, si une tâche empêche quelqu'un de travailler sur quelque chose, elle doit être marquée comme faisant blockingréférence à l'autre problème.

J'ai trouvé un peu difficile de comprendre comment répertorier les éléments attribués à une personne en particulier;

La solution consiste à cliquer sur l'icône de recherche (sans indiquer de critère de recherche). Sur la page de résultats, un menu déroulant se trouve à gauche.

— Dean plutôt
source