Come gestire i problemi di github per (priorità, ecc.)? [chiuso]

Sono nuovo di Github e cerco consigli su come gestire i problemi. Sono abituato ad avere priorità e altre opzioni di ordinamento, ma vedo che nessuna esiste.

In che modo gli altri gestiscono i problemi durante il ciclo di vita di un bug / funzionalità?

Grazie in anticipo.

Si potrebbe definire diversi gruppi di etichette come tipo di emissione , le priorità di emissione , emissione stati , tag di versione , e forse di più. Per poter vedere immediatamente a quale gruppo appartiene un'etichetta, puoi usare una convenzione di denominazione simile <label-group>:<label-name>.

L'uso di una tale convenzione di denominazione dovrebbe rendere la gestione dei problemi di Github molto più semplice e aiutare gli altri a "capire" i problemi molto più velocemente. Nota che puoi anche assegnare colori alle etichette che possono aggiungere ancora di più alla leggibilità (userei un colore specifico per ogni gruppo di etichette). Tuttavia, poiché è necessario assegnare / annullare l'assegnazione manuale di tali etichette a / da problemi, è possibile che si desideri mantenere un elenco ridotto di gruppi / etichette.

Secondo lo schema suggerito sopra, è possibile definire i gruppi e le etichette corrispondenti come segue.

gruppo "tipo di problema"

• Tipo: bug
• Tipo: caratteristica
• digitare: idea
• Tipo: non valida
• Tipo: Supporto
• Tipo: operazione

gruppo "priorità di emissione"

• PRIO: basso
• PRIO: normale
• PRIO: alta

gruppo "stato problema"

(Queste etichette descrivono lo stato di un problema in un flusso di lavoro definito).

• stato: confermato
• Stato: differito
• Stato: fix-impegnato
• Stato: in corso
• Stato: incompleta
• Stato: respinto
• Stato: risolto

gruppo "informazioni di rilascio"

• Info: il feedback necessaria
• info: help necessaria
• info: progress-25
• info: progress-50
• info: progress-75

gruppo "tag versione"

• ver: 1.x
• ver: 1.1

Il tracker dei problemi di GitHub è abbastanza flessibile. Non vi è alcuna priorità né ordine. Gira intorno a tre pilastri principali: incarichi , etichette e pietre miliari .

• Puoi "taggare" i problemi con le etichette che crei (in modo simile alle etichette di Gmail). Ad esempio: "bug", "feature-request", "todo", "question", ... Un problema può essere taggato con etichette diverse.

• Puoi "impacchettare" diversi problemi in una pietra miliare . Una pietra miliare è costituita da un titolo (ad esempio un numero di versione) e una data di consegna opzionale.

• Ogni numero può essere assegnato a un collaboratore (collaboratore o membro dell'organizzazione) del repository. Puoi anche convocare un collaboratore in un commento usando a @seguito dal suo login GitHub.

Alla fine, grazie alla barra laterale, puoi "filtrare" l'elenco dei problemi per aiutarti a gestirlo.

Un post completo sul blog "Issues 2.0" su questo argomento ti darà una visione più dettagliata delle funzionalità.

Uso huboard.com per rappresentare i problemi di github in modo kanban, quindi li ordino trascinandoli all'interno di huboard. Funziona abbastanza bene se ti interessa solo visualizzare la priorità e sapere cosa lavorare dopo.

In realtà memorizza la priorità all'interno del problema stesso, come un commento HTML:

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

Esempio di come utilizziamo le etichette su github per gestire i nostri progetti

Etichette di categoria (potrebbe anche usare tutti i tappi per separare visivamente)

• Compito
• insetto
• caratteristica
• Discussione

Etichetta prioritaria

• URGENTE

Consideriamo che tutto abbia una priorità normale e non vediamo davvero la necessità di "basso". In modo che lasci solo un'etichetta per contrassegnare le cose che richiedono attenzione immediata.

Etichette di stato

• rivisto (l'assegnatario l'ha letto)
• in coda (l'assegnatario ci lavorerà presto)
• lavori in corso (l'assegnatario ci sta lavorando ora)
• non valido (se il bug non è riproducibile)
• bisogno di feedback (segnale bat per convincere le persone a leggere e commentare o fornire aiuto)

Conserviamo tutta la documentazione in un wiki che include istruzioni, architettura, infrastruttura, case study, pianificazione e requisiti.

Le richieste pull sono per la revisione del codice e la discussione delle funzionalità se fa parte di un ramo

Con un uso creativo del filtro possiamo trovare tutto il lavoro che dobbiamo fare per il giorno. "Task + URGENT" o "Bug + URGENT" esaminano sempre i problemi contrassegnati come "bisogno di feedback" e lasciano un commento anche se non hai nulla da aggiungere. Naturalmente questo funziona con il nostro team di cinque persone, ma probabilmente non molto di più.

Vado per due tipi di etichette nelle emissioni di GH: la prima relativa al tipo di problema e la seconda relativa alla priorità:

• insetto
• caratteristica - (novità)
• miglioramento - (migliorare le cose esistenti)
• domanda / discussione - (discutere cose)

Domanda / discussione potrebbe non essere necessaria, se si utilizza bene il Wiki. Ma mi piace perché mi permette di indirizzare una domanda o un'idea a una persona in particolare.

Quindi ci sono tre etichette prioritarie davvero semplici:

• adesso
• presto
• dopo

Facile vero?

Oltre alle soluzioni di tagging suggerite sopra, abbiamo blockinge blockedcome etichette.

Un problema deve essere prima assegnato alla persona corretta, ma se quella persona non è in grado di lavorare sul problema fino a quando non viene terminato qualche altro problema, il problema è contrassegnato come blocked. E l'altro problema viene indicato utilizzando un tag hash.

Allo stesso modo se un'attività sta impedendo a qualcun altro di lavorare su qualcosa, dovrebbe essere contrassegnata come blockingcon un riferimento all'altro problema.

Ho trovato un po 'complicato capire come elencare gli elementi assegnati a una determinata persona;

La soluzione è fare clic sull'icona "Cerca" (senza digitare criteri di ricerca) e nella pagina dei risultati è presente un menu a discesa a sinistra.