Manutenção das issues (quais fechar?)

[filipedeschamps]

Para não perdermos controle sobre a quantidade de issue aberta, proponho que já logo no início dessa Milestone a gente faça um fechamento da maioria das issues que ficaram stale. Isso não significa que o assunto foi encerrado, e muito menos que não pode ser repescado (inclusive, o que é importante geralmente é repescado naturalmente). Mas é muito de fazermos a manutenção do repositório aqui no Github, tanto quanto fazemos em código. Eu vejo que nem todas as issues valem a pena fechar, mas algumas valem 👍

[rodrigoKulb]

Concordo!
Alem dos 2 status das Inssues, poderia existir um "in coming" para conversar sobre assuntos futuros.
Mas se analisar com calma existem Inssues com assuntos duplicados que poderiam ser unificadas.

@filipedeschamps o que acha de criar uma Inssues chamada "in coming" colocando link para todas Inssues de propostas futuras, finalizando todas elas? Não sei se é a melhor forma sou novato no Github.

[geovani-brito]

Bom... acho que posso falar pela issue #27 que eu abri. Por mim, ela pode ser fechada e esse assunto pode ser retomado quando o sistema todo já estiver em produção e com usuários ativos. Vai ser a oportunidade de analisar melhor o comportamento das postagens.

Ou então, se usar a ideia do @rodrigoKulb ela pode ficar na "in coming".

Eu já me perguntava se essa issue poderia ficar na Milestone 7. Mas se entrar na milestone e ficar fechada, fica parecendo que ela já foi concluída. Talvez, fazendo uma sugestão, fosse uma boa hora para usar a guia Projects do Github com um quadro Kanban. Então as issues que serão pensadas depois, podem ficar em um backlog. Enquanto as tarefas efetivas podem ficar em um To Do.

Pode parecer meio redundante já que de certa forma as milestones estão aí para organizar o que será feito e em qual ordem. Porém, elas sinalizam mais os marcos históricos (com aquelas lives delicinhas rs) enquanto os quadros Kaban vão indicando o que precisa ser feito, o que está sendo feito e o que foi concluído.

São as minhas sugestões e, como sempre, estou aberto para todo tipo de ideias e críticas.

[rodrigoKulb]

@geovani-brito estava pesquisando aqui, acabei achando o Zube (curti a ferramenta) para organizar issues.
Só precisa entender como compartilhar o quadro:

[rodrigoKulb]

Outra possibilidade é abrir a aba Projects do Github já possui o tema Kanban.

[rhandrade]

@rodrigoKulb curti a ideia o "in coming"... Compartilho da mesma ideia do @geovani-brito, as vezes por ver que ele está fechada pode indicar que o assunto foi discutido e não será retomado mais.

Acredito que o Projects do Github ou mesmo a nova versão das issues que o Github lançou (não sei ela já está disponível) ficaria bem maneira no projeto, pois centraliza todos em um único lugar.

https://github.com/features/issues

[filipedeschamps]

Sensacional pessoal!!! Lendo o que vocês conversaram, tentei sintetizar duas trajetórias, e uma bônus:

1. Criar um board de trabalho com as colunas inspiradas pelo exemplo ali em cima:
   • RFC de "Request for Comments"
   • To do
   • Doing
   • Done
2. Marcar as issues estagnadas com uma label do tipo repescar e fechar elas, porque assim fica muito fácil de fato repescar elas.

A opção 2 é mais simples, pois resolve tudo na aba Issues. A opção 1 precisa de mais manutenção, mas talvez dê uma organizada melhor no que está sendo feito.

A ideia bônus, seria um board geral, onde cada coluna é uma Milestone, e uma coluna especial para RFC. As issues ficariam paradas em cada coluna, mas daria uma visão macro do projeto.

Algo me diz que, para a atual complexidade do projeto, a opção 2 é super viável e vai entregar o que queremos: manter sob controle a quantidade das issues, sem se perder onde estão aquelas que discutiram coisas valiosas, mas estagnaram pelo timing do projeto.

Talvez podemos tentar o mais simples e entender o que vai acontecer com nossa percepção, e se ficar ruim, vamos aumentando a sofisticação da solução. O que acham?

[rodrigoKulb]

Concordo com a opção 2, a manutenção da 1 será um novo problema para o projeto.

[geovani-brito]

Minha preocupação era mais com a ideia de fechar as issues que não foram concluídas. Mais adiante isso poderia criar uma certa confusão, principalmente para os próximos que podem entrar no projeto quando o repositório se tornar público. Por isso, eu também concordo que usar uma tag repescar da opção 2 parece a solução mais simples no momento.

[rhandrade]

Concordo com a opção 2 também.

[filipedeschamps]

Pessoal, se a minha memória não falha, a gente saiu de 18 issues abertas para 10 (que incluem as 6 issues da própria Milestone). Dado a isso, vou fechar essa issue e sempre poderemos fazer esse tipo de manutenção no repositório, inclusive colocar uma Action para auto-fechar issues que perderam tração por, por exemplo, 30 dias 🤝

Let's gooooo!!!!!!

[filipedeschamps]

Só para deixar documentado, o Github já fornece um bot para issues que ficaram stale: https://github.com/marketplace/stale