Rótulos, projetos e roteiro de marcos

A equipe de documentação do .NET faz uso extensivo dos rótulos do GitHub para organizar nosso trabalho. Filtrando combinações de rótulos, podemos nos concentrar rapidamente em seções de interesse no site de documentação do .NET. Por exemplo, é possível filtrar todos os problemas em aberto nos guias de arquitetura com uma consulta em is:issue is:open label:"dotnet-architecture/prod".

Usamos projetos do GitHub para organizar sprints e outros epics orientados a metas. Também usamos marcos do GitHub para acompanhar o trabalho. O ideal é considerar os projetos para planejamento (problemas) e marcos para o trabalho (solicitações de pull).

Este roteiro explica como usar essas ferramentas organizacionais e tem links para filtros práticos que usamos para encontrar áreas de interesse.

Rótulos

Se esta for sua primeira experiência em colaborar com o dotnet/docs, comece com os problemas up-for-grabs. Esses são problemas que têm um escopo mais focado. Eles são uma ótima maneira de fazer sua primeira contribuição. Na exibição up-for-grabs, você pode filtrar ainda mais problemas com base em áreas e em prioridade. Identificamos bons problemas para iniciantes com good-first-issue se você desejar experimentar uma primeira contribuição menor.

Usamos rótulos para classificar problemas de várias maneiras diferentes:

Você pode combinar um rótulo de cada conjunto (guia, versão, prioridade) para criar um foco estreito para encontrar problemas nos quais deseja trabalhar.

Encontre problemas para um único guia do .NET

Usamos rótulos para cada um dos livros eletrônicos de arquitetura e para cada Guia do .NET. Todos os livros eletrônicos recebem o rótulo dotnet-architecture/prod. Cada livro tem um rótulo exclusivo que termina com /tech.

Cada guia do .NET recebe o sufixo /prod e tem uma tela de fundo cinza azulado. Veja os problemas atuais filtrados para cada um dos guias do .NET.

Outros rótulos de produtos são definidos para áreas que cruzam repositórios.

Encontrar problemas para uma seção de um guia

Os guias do .NET são grandes, portanto, esses rótulos limitam ainda mais o escopo por uma seção de um guia. Cada subárea do Guia do .NET recebe o sufixo /tech e tem uma tela de fundo azul-claro. Muitos desses rótulos se aplicam a vários guias, enquanto outros estão em apenas um. Após a filtragem em uma área, adicione um desses rótulos para limitar ainda mais o escopo dos problemas.

Versões

:checkered_flag: Release: on dark yellow

Os problemas marcados para uma versão específica recebem o prefixo :checkered_flag: Release: e têm uma tela de fundo amarelo escuro.

Prioridade

Os rótulos de prioridade são todos Pri seguidos por um único dígito. Números mais baixos têm maior prioridade:

  • Pri0 – Prioridade crítica

    Problema de segurança ou requisito legal para conformidade. Pausamos tudo para corrigir.

  • Pri1 – Prioridade alta

    Essencial para cenários comuns. Ou erro altamente visível no artigo com alta exibição de página. Resolvemos essa questão antes de P2 ou P3.

  • Pri2 – Prioridade média

    Útil para cenários comuns, mas não para bloqueios. Resolveremos a questão se for rápido ou fácil. Caso contrário, encaixaremos em outro momento durante a resolução de um problema de P1 no mesmo artigo.

  • Pri3 – Prioridade baixa

    Útil para casos de borda, correções triviais para cenários comuns, artigo com baixa exibição de página ou tecnologia preterida. Não vale a pena dedicar nosso tempo a isso, mas está disponível para contribuição da comunidade. Um problema de P3 poderá ser encerrado se não for resolvido após dois meses.

E os outros rótulos?

Há muitos outros rótulos usados pelas equipes de conteúdo para gerenciar diferentes classificações de problemas. Se você não estiver na equipe de conteúdo, poderá ignorar esses outros rótulos.

Projetos

Os projetos destinam-se a fins de planejamento, em que o trabalho priorizado é automatizado por meio de um quadro Kanban. Os projetos devem conter apenas problemas do GitHub, não solicitações de pull. Os projetos são diferentes dos marcos, pois estes contêm apenas solicitações de pull.

Usamos projetos de duas maneiras:

Marcos

Os marcos geralmente seguem a mesma convenção de nomenclatura de projetos Month YYYY, mas são diferentes dos projetos. Usamos marcos para acompanhar o trabalho concluído. Os marcos não devem conter problemas (trabalho potencial), mas conter exclusivamente solicitações de pull. O marco atual é aplicado automaticamente a novas solicitações de pull.