Proposta de Modelo de Gestão com Dois Boards no GitHub

[cleytonbiffe]

Introdução

A fim de otimizar a organização e a comunicação no projeto "Você na Facul", proponho uma estrutura de gestão que utiliza dois boards no GitHub Projects: um board privado para a equipe interna e um board público para os colaboradores externos. O objetivo é melhorar o fluxo de trabalho, minimizar o retrabalho e garantir que as tarefas sejam bem distribuídas, com visibilidade clara para todos os membros envolvidos, sem sobrecarregar a gestão do projeto.

Além disso, propomos o uso do GitHub Actions para automatizar a sincronização entre os boards e facilitar a gestão de tarefas.

Estrutura dos Boards

1. Board Privado (Interno)

Este board será utilizado para gestão interna e atividades que envolvem planejamento, estratégia e coordenação das equipes. Ele será acessível apenas aos membros internos do projeto e terá as mesmas características atuais.

• Objetivo: Garantir o controle e a gestão das atividades mais estratégicas e as tarefas que exigem interação contínua entre a equipe interna.

2. Board Público (Externo)

Este board será acessível a todos os colaboradores externos do projeto (desenvolvedores, designers e outros membros externos) e será utilizado para tarefas específicas que podem ser realizadas por essas equipes. Ele terá as seguintes características:

• Colunas:

  • Backlog: Tarefas para serem avaliadas e atribuídas à equipe externa.
  • Em Andamento: Tarefas atualmente em execução pela equipe externa.
  • Concluídas: Tarefas finalizadas pela equipe externa, aguardando revisão ou feedback da equipe interna.

• Labels:

  • Design: Tarefas relacionadas ao design de telas e novos recursos que precisam de implementação visual.
  • Desenvolvimento: Tarefas relacionadas ao desenvolvimento de código, ajustes em features ou resolução de bugs específicos.

• Objetivo: Prover visibilidade e colaboração para a equipe externa, permitindo que eles vejam as tarefas que precisam ser feitas sem sobrecarregar o board interno com tarefas que não exigem interação da equipe interna.

Fluxo de Trabalho Entre os Boards

1. Criação de Tarefas no Board Privado (Interno)

• As tarefas iniciais, como planejamento, definição de funcionalidades e revisões estratégicas, serão criadas no board privado.
• A equipe interna atribui prioridades e começa a trabalhar na execução dessas tarefas.

2. Transferência para o Board Público (Externo)

• Quando uma tarefa estiver pronta para ser executada pela equipe externa, ela será movida para o board público.
• As tarefas podem ser transferidas quando estiverem na fase de design ou desenvolvimento e a equipe externa tiver a capacidade de trabalhar nelas.

3. Execução e Conclusão no Board Público

• A equipe externa assume a execução da tarefa e marca o progresso no board público.
• Após a conclusão, a tarefa será marcada como "Concluída" no board público.

4. Retorno ao Board Privado (Interno)

• Tarefas concluídas pela equipe externa serão transferidas de volta para o board privado, onde a equipe interna fará a revisão final e integrará as entregas ao projeto principal.

Automação com GitHub Actions

Para reduzir a carga manual da gestão dos boards e tornar o fluxo de trabalho mais eficiente, utilizaremos GitHub Actions para automatizar as seguintes etapas:

1. Movimentação de Issues entre Boards

   • Quando uma tarefa for aprovada para execução pela equipe externa, uma ação automatizada criará automaticamente uma issue correspondente no board público, mantendo um link de referência para rastreamento.
   • Quando uma tarefa for concluída no board público, a ação moverá automaticamente essa issue para revisão no board privado.

2. Atribuição Automática de Tarefas

   • Labels serão usadas para definir a categoria da tarefa (Design, Desenvolvimento, Manutenção, etc.).
   • Baseado nessas labels, um GitHub Action pode automaticamente atribuir a issue a um mantenedor responsável ou definir um grupo de reviewers para acompanhamento.

3. Notificações e Atualizações Automáticas

   • Envio de notificações no GitHub Discussions ou em um canal do Slack/Discord sempre que uma tarefa for movida entre os boards, garantindo que todos estejam informados das mudanças no fluxo de trabalho.
   • Atualização automática da descrição da issue com status atual, responsáveis e prazos definidos.

4. Revisão Automatizada de Pull Requests

   • Quando um pull request for criado e vinculado a uma issue do board público, o GitHub Actions pode automaticamente solicitar revisão dos mantenedores responsáveis antes da integração ao código principal.

Benefícios Esperados

• Visibilidade e Transparência: As equipes externas terão acesso às informações de forma clara e atualizada, aumentando a transparência do progresso do projeto.
• Redução de Entradas Manuais: Com a transferência automatizada de tarefas entre os boards via GitHub Actions, a equipe interna economiza tempo e evita a duplicação

[RafaelFantinel]

Uma alternativa interessante à utilização de boards no GitHub Projects é estruturar a gestão do projeto utilizando milestones, issues e labels. Essa abordagem pode simplificar o fluxo de trabalho e reduzir a necessidade de movimentação manual ou automatizada de tarefas entre diferentes boards.

Proposta de Estrutura sem Boards

1. Uso de Milestones para Organização do Projeto
   • Cada grande etapa do projeto (exemplo: "Lançamento da Feature X do cursinho", "Nova Funcionalidade X") pode ser organizada como um milestone.
   • As issues são associadas a milestones para que o progresso seja acompanhado de forma mais clara.

Exemplo:

2. Gestão de Tarefas com Issues
   • Todas as tarefas são registradas como issues, com descrições detalhadas sobre o que precisa ser feito.
   • Labels são utilizadas para categorizar as issues, como:
     • Design
     • Desenvolvimento
     • Bug
     • Discussão

Exemplos:

3. Automação com GitHub Actions

   • As issues podem ser automaticamente atribuídas a membros da equipe com base nas labels.
   • Quando uma issue é fechada, ela atualiza automaticamente o progresso do milestone.
   • Notificações podem ser enviadas no Discord para manter todos informados sobre mudanças importantes.

4. Fluxo de Trabalho Simplificado

   • Em vez de mover tarefas entre boards, basta atualizar o status da issue (aberta/em progresso/fechada).
   • A equipe pode visualizar facilmente o progresso do projeto acessando a aba de milestones.

[cleytonbiffe]

Ótima ideia Rafael!

[cleytonbiffe]

Outro ponto que surgiu em uma das discussões sobre o assunto que também tem relação com essa organização e com a atuação de colaboradores externos do projeto:
Considerando a nova organização das Branchs (Main, Release e Dev), estávamos pautando tudo sobre PRs feitas entre branchs dentro da organização.
Quando utilizamos um usuário que não é membro da organização (é um colaborador é externo), este usuário não consegue abrir uma nova branch na organização. Provavelmente por este motivo que costumam realizar um Fork do projeto e depois abrir um PR deste Fork para a Branch em questão. O que pode gerar uma quantidade maior de Diff que gostaríamos de ter como mantenedores para realizar um CR e garantir que entendemos as mudanças que realmente foram feitas.
Alguém já pensou nisso e/ou saberia alguma alternativa para minimizarmos os esforços em relação a isso?

• Teria alguma maneira de liberar para as pessoas entrarem na organização por conta própria (sem a gente ter que adicionar) com alguma permissão minimizada?
• Teria alguma maneira de minimizar a quantidade de Diffs identificadas quando um PR é feito de um Fork?

[cleytonbiffe]

@RafaelFantinel @danielhssouza @FernandoAlmeidaPinto

[FernandoAlmeidaPinto]

O que planejei é um documento de contribuição bem explicito de como funciona um processo de contribuição.
Se a pessoa realizou um demanda nossa, não seguindo o processo corretamente e sumiu, não vejo outra alternativa pegar alguém (mantenedor) para assumir e conseguir trazer as info corretamente para QA e a release (não vejo como fugir dessa situação)

Se a pessoa propôs ela mesmo uma melhoria e fez um PR não seguindo os padrões -> neste caso precisamos avaliar se vale a pena ou não seguir com o PR (esse caso é o que teríamos no documento de contribuição que nem todo PR é aceito, mas isso faz parte da cultura de contribuição open source).

O que devemos brigar é que as pessoas tentem ao máximo seguir nosso fluxo de contribuição.

Além disso proposta é criar team de revisores e colocar nas permissões de aprovação de PR o team.