Como gerenciar problemas do github para (prioridade, etc)? [fechadas]

Eu sou novo no github e estou procurando conselhos sobre como gerenciar problemas. Estou acostumado a ter prioridade e outras opções de pedidos, mas vejo que não existem.

Como outras pessoas gerenciam problemas durante o ciclo de vida de um bug / recurso?

Desde já, obrigado.

Você pode definir diferentes grupos de rótulos como tipos de emissão , as prioridades temáticas , estados das tarefas , marcas de versão , e talvez mais. Para poder ver instantaneamente a qual grupo um rótulo pertence, você pode usar uma convenção de nomenclatura <label-group>:<label-name>.

O uso de uma convenção de nomenclatura deve facilitar o gerenciamento dos problemas do Github e ajudar outras pessoas a "entender" os problemas muito mais rapidamente. Observe que você também pode atribuir cores às etiquetas, o que pode adicionar ainda mais legibilidade (eu usaria uma cor específica para cada grupo de etiquetas). Mas como você ainda precisa atribuir / remover a atribuição desses marcadores para / de problemas manualmente, convém manter pequena a lista geral de grupos / marcadores.

De acordo com o esquema sugerido acima, você pode definir grupos e rótulos correspondentes da seguinte maneira.

grupo 'tipo de problema'

• tipo: bug
• type: feature
• tipo: ideia
• tipo: inválido
• tipo: suporte
• tipo: tarefa

grupo 'prioridade da questão'

• prio: baixo
• prio: normal
• prio: high

grupo 'status da questão'

(Esses rótulos descrevem o estado de um problema em um fluxo de trabalho definido.)

• Status: Confirmado
• status: adiado
• status: consertado
• status: em andamento
• status: incompleto
• status: rejeitado
• status: resolvido

grupo 'emitir informações'

• informação: feedback necessário
• informação: ajuda necessária
• informação: progress-25
• informação: progress-50
• informação: progress-75

grupo 'tag de versão'

• ver: 1.x
• ver: 1.1

O rastreador de problemas do GitHub é bastante flexível. De fato, não há prioridade nem ordem. Ele gira em torno de três pilares principais: atribuições , rótulos e marcos .

• Você pode "marcar" problemas com os marcadores criados (de maneira semelhante aos marcadores do Gmail). Por exemplo: "bug", "feature-request", "todo", "question", ... Um problema pode ser marcado com rótulos diferentes.

• Você pode "empacotar" vários problemas em um marco . Um marco é constituído por um título (um número de versão, por exemplo) e uma data de entrega opcional.

• Cada problema pode ser atribuído a um colaborador (colaborador ou membro da organização) do repositório. Você pode até convocar um colaborador em um comentário usando um @seguido por seu login no GitHub.

Eventualmente, graças à barra lateral, você pode "filtrar" a lista de problemas para ajudá-lo a gerenciá-lo.

Uma postagem completa do blog "Edições 2.0" sobre esse assunto fornecerá uma visão mais detalhada dos recursos.

Eu uso o huboard.com para representar os problemas do github da maneira Kanban e depois os classifico arrastando e soltando no huboard. Funciona muito bem se você estiver interessado apenas em visualizar a prioridade e em saber o que trabalhar a seguir.

Na verdade, ele armazena a prioridade no próprio problema, como um comentário em HTML:

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

Exemplo de como usamos rótulos no github para gerenciar nossos projetos

Rótulos de categoria (também podem usar todas as letras maiúsculas para separar visualmente)

• Tarefa
• Erro
• Característica
• Discussão

Etiqueta de prioridade

• URGENTE

Consideramos que tudo tem prioridade normal e não vemos realmente a necessidade de "baixo". Portanto, isso deixa apenas um rótulo para marcar as coisas que precisam de atenção imediata.

Etiquetas de status

• revisado (o responsável leu)
• na fila (o responsável trabalhará nele em breve)
• trabalho em andamento (o responsável está trabalhando agora)
• inválido (se o bug não for reproduzível)
• precisa de feedback (sinal de bastão para levar as pessoas a ler e comentar ou fornecer ajuda)

Mantemos toda a documentação em um wiki que inclui instruções, arquitetura, infraestrutura, estudos de caso, planejamento e requisitos.

As solicitações pull são para revisões de código e discussão de recursos, se fizer parte de uma filial

Com algum uso criativo da filtragem, podemos encontrar o trabalho que precisamos fazer para o dia. "Task + URGENT" ou "Bug + URGENT" sempre analisa os problemas marcados como "precisa de feedback" e deixe um comentário mesmo se você não tiver nada a acrescentar. Claro que isso funciona com nossa equipe de cinco, mas provavelmente não muito mais do que isso.

Eu escolho dois tipos de etiquetas nas questões de GH - a primeira relacionada ao tipo de questão e a segunda relacionada à prioridade:

• erro
• recurso - (novidades)
• aprimoramento - (melhorando o material existente)
• pergunta / discussão - (discutindo coisas)

Perguntas / discussões podem não ser necessárias, se você usar bem o Wiki. Mas eu gosto disso porque me permite direcionar uma pergunta ou uma idéia para uma pessoa em particular.

Existem três rótulos de prioridade realmente simples:

• agora
• em breve
• mais tarde

Fácil né?

Além das soluções de marcação sugeridas acima, temos blockinge blockedcomo rótulos.

Um problema deve ser atribuído primeiro à pessoa correta, mas se essa pessoa não puder trabalhar no problema até que outro problema seja concluído, o problema será marcado como blocked. E o outro problema é mencionado usando uma tag de hash.

Da mesma forma, se uma tarefa está impedindo que outra pessoa trabalhe em algo, ela deve ser marcada como blockinguma referência ao outro problema.

Achei um pouco complicado descobrir como listar itens atribuídos a uma pessoa em particular;

A solução é clicar no ícone 'pesquisar' (sem nenhum critério de pesquisa digitado) e, na página de resultados, há um menu suspenso à esquerda.