web-dev-qa-db-fra.com

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

Je suis nouveau sur github et je cherche des conseils sur la gestion des problèmes. Je suis habitué à avoir la priorité et d'autres options de commande, mais je vois qu'aucune n'existe.

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

Merci d'avance.

49
djf

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

L'utilisation d'une telle convention de dénomination devrait faciliter la gestion des problèmes 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 ajouter encore plus à la lisibilité (j'utiliserais une couleur spécifique pour chaque groupe d'étiquettes). Mais comme vous devez toujours attribuer/annuler l'attribution manuelle de ces étiquettes aux problèmes, vous souhaiterez peut-être garder la liste globale des groupes/étiquettes petite.

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

groupe 'type de problème'

  • type: bug
  • type: fonction
  • type: idée
  • type: invalide
  • type: support
  • type: tâche

groupe "prioritaire"

  • prio: faible
  • prio: normal
  • prio: haut

groupe "état du problème"

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

  • statut: Confirmé
  • statut: différé
  • statut: corrigé par le correctif
  • statut: en cours
  • statut: incomplet
  • statut: rejeté
  • statut: résolu

groupe 'problème d'information'

  • info: besoin de commentaires
  • info: besoin d'aide
  • info: progress-25
  • info: progress-50
  • info: progress-75

groupe 'version tag'

  • ver: 1.x
  • ver: 1.1
52
Jonny Dee

Le tracker de problèmes GitHub est assez flexible. Il n'y a en effet ni priorité, ni commande. Il s'articule autour de trois piliers principaux: Affectations , étiquettes et jalons .

  • Vous pouvez "baliser" les problèmes avec les étiquettes que vous créez (de la même manière que les étiquettes Gmail). Par exemple: "bug", "feature-request", "todo", "question", ... Un problème peut être étiqueté avec différentes étiquettes.

  • Vous pouvez "regrouper" plusieurs problèmes dans un jalon . Un jalon est constitué d'un titre (un numéro de version par exemple) et d'une date de livraison optionnelle.

  • Chaque problème peut être attribué à un collaborateur (contributeur ou membre de l'organisation) du référentiel. Vous pouvez même invoquer un collaborateur dans un commentaire en utilisant un @ suivi de sa connexion GitHub.

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

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

22
nulltoken

J'utilise huboard.com pour représenter les problèmes de github à la manière d'un tableau Kanban, puis je les trie par glisser-déposer dans huboard. Cela fonctionne plutôt bien si vous ne souhaitez visualiser que la priorité et savoir quoi travailler ensuite.

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

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

Exemple d'utilisation de labels sur github pour gérer nos projets

Étiquettes de catégorie (pourrait également utiliser toutes les majuscules pour se séparer visuellement)

  • Tâche
  • Punaise
  • Fonctionnalité
  • Discussion

Étiquette de priorité

  • URGENT

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

Étiquettes d'état

  • révisé (le cessionnaire l'a lu)
  • en file d'attente (le cessionnaire y travaillera bientôt)
  • travaux en cours (le cessionnaire y travaille actuellement)
  • invalide (si le bogue n'est pas reproductible)
  • besoin de commentaires (signal de chauve-souris pour amener les gens à lire et commenter ou à fournir de l'aide)

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

Les Pull-Requests sont pour les révisions de code et la discussion des fonctionnalités si elles font partie d'une branche

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

5
Brian Boatright

En plus des solutions de marquage suggérées ci-dessus, nous avons blocking et blocked comme é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 d'autre de travailler sur quelque chose, elle doit être marquée comme blocking avec une ré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 "recherche" (sans critère de recherche saisi) et sur la page des résultats il y a un menu déroulant à gauche.

1
Dean Rather

Je choisis deux types d'étiquettes dans les problèmes de GH - le premier relatif au type de problème et le second relatif à la priorité:

  • punaise
  • fonctionnalité - (nouveau truc)
  • amélioration - (améliorer les choses existantes)
  • question/discussion - (discuter de choses)

Une question/discussion peut ne pas être nécessaire si vous utilisez bien le Wiki. Mais j'aime ça car cela me permet de diriger une question ou une idée vers une personne en particulier.

Ensuite, il y a trois étiquettes de priorité vraiment simples:

  • maintenant
  • bientôt
  • plus tard

Facile, non?

1
Ryan Kinal