Uso de labels do DemocracyOS e papel do zelador

[ppKrauss]

Em toda comunidade git são entendidos como auto-evidentes labels tais como "bug" ou "enhancement", que são coisas para a "to do list" da equipe. Já issues de "de comunicação com a comunidade" recebem labels mais diversos...

Essas duas finalidades são bem distintas e sinalizam para a esquipe do projeto comportamentos bem distintos. Por serem "sinalizações" os labels do projeto acabam compondo um pequeno vocabulário, que pede um "glossário"... É importante que todos da equipe e e todos da comunidade façam uso das mesmas convenções, ou seja, que esse glossário esteja definido em algum lugar, garantindo o uso consistente dos labels... Como ainda não existe na OKBr uma sugestão para isso, pode-se adotar os labels do projeto-pai: DemocracyOS/app/labels (reparar no uso consistente, todos com mais de zero issues).

Independente da convenção adotada, sempre é possível entender as issues, e portanto os seus labels, como itens de dois grandes grupos:

• Lista de tarefas da equipe (to-do-list): tipicamente issues aprovadas pela coordenação do projeto para que entrem na fila de trabalho da equipe de desenvolvimento. A equipe precisa ler/conhecer essas issues para poder discutir a agenda do projeto.
• Comunicação: todo o resto, que garante uma comunidade participativa e o bom acolhimento de potenciais colaboradores (!). Apesar de poderem surgir coisas interessantes, a equipe não precisa ler/conhecer essas issues. Pode-se esperar inclusive respostas/debates de pessoas que não são membros da equipe de desenvolvimento (ex. zelador ou outros membros da OKBr). Exemplos:
  • Aparentes bugs que são na verdade decorrentes de mal-uso (ex. não seguir o manual ou mensagens da interface). Em geral são fechados rapidamente, mas são bem-vindos, merecem resposta/diálogo pois a recorrência será indicativo, por exemplo, de falha da interface.
  • Duvidas: dúvida da comunidade de usuários ou mesmo "navegantes curiosos". Ver exemplos no label question.
  • Novas funções para um futuro distante: quando a sugestão faz sentido, pode ficar registrada como numa lista de e-mails, gerando mais comunicação, não precisa ser fechada. No final, os encarregados do business plan dos "investimentos futuros" poderão apreciar, fechando com um parecer mais amigável sobre o uso da ideia.
  • Discussões: solicitações de "conversa com o projeto", as mais variadas. Ver exemplos no label discussion.

NOTA: issues ainda não-rotuladas são aquelas a equipe não precisa perder tempo lendo.

O acolhimento aos colaborares é um valor da OKBr a ser preservado nos projetos-OKBr... Se o projeto está ativo, existem coordenador e zelador do projeto, portanto existem recursos para lidar com esse "custo de comunicação".

---

Sobre os papeis do zelador e do coordenador:

• O coordenador é a autoridade maior do projeto, inclusive no relacionamento com a comunidade. Cabe ao coordenador definir a to-do-list e intervir nas demais issues quando julgar necessário, em particular o fechamento da issue.
• O zelador não deixa de ser um colaborador, podendo ajudar a gerenciar/mediar a comunicação com a comunidade... Por isso é importante que o zelador tenha direito de rotular issues (o quanto antes para não tomar tempo do coordenador) como
  discussion (ou "far future") ou question, ou memso declined.

Suposições sobre os objetivos do Github/issues.
Os objetivos das issues em um projeto aberto à interação com a comunidade e à colaboração, são mais amplos que issue tracking system em contexto empresarial, por isso foram agrupados em to-do-list e comunicação.