Processo de Decisão e Congelamento

[Leandro Nunes]

Olá pessoal,

Na última sexta-feira dia (11/03/2015) boa parte da comunidade de
desenvolvedores do Noosfero (Leandro, Victor, Joenio, Daniela e Rodrigo )
teve a oportunidade de se encontrar e nós aproveitamos este momento para
realizar algumas discussões sobre o andamento do projeto Noosfero, mais
especificamente sobre o processo de congelamento de código e também sobre o
processo de tomada de decisão da comunidade.

A discussão foi bastante rica e proveitosa e ao final nós chegamos a alguns
consensos sobre estes dois pontos:

  1 - Processo de Congelamento de Versão (freeze)

O objetivo maior do freeze era direcionar toda a comunidade para se
esforçar para que o lançamento saísse o mais rápido possível. Apesar da
motivação ser muito boa ao longo da história dos releases o fato de existir
o congelamento do master não foi determinante para que o lançamento
ocorresse mais rápido.

Nós notamos também que o fator que mais impactava na demora do lançamento
da versão era que o código tinha bastante teste falhando e o RM acabava
tendo muito trabalho para ajeitar todos os testes e lançar a versão. Apesar
desta não ser a obrigação somente do RM ele acabava tendo este encargo.

Depois de muito tempo conseguimos ter novamente uma versão lançada com 100%
dos testes passando e vamos nos esforçar para que essa situação não mude e
isso é o pressuposto básico para que a proposta aqui apresentada funcione.

Pode parecer redundante, mas a ideia é que a partir da aprovação destas
ideias pela comunidade todos os commiters passem a ser responsáveis por
manter todos os testes sempre passando então um commiter só deve aceitar um
MR caso ele não quebre nenhum teste. É também fortemente recomendável que o
commiter não faça mais commits diretamente no master por mais simples que
seja a modificação. A ideia é utilizarmos os runners do gitlab ao nosso
favor e para os casos mais simples utilizar a opção de fazer merge
automaticamente quando a build for construída com sucesso. A ideia é que
qualquer commit feito diretamente para o master que quebre um teste seja
revertido por qualquer um dos commiters.

Uma vez garantido este procedimento nós teremos o master sempre rodando com
todos os testes passando (em tese pronto para produção a qualquer momento)
então isso não será mais um blocker para o lançamento de uma versão.

Chegamos a um consenso de que iríamos experimentar ter o período de freeze,
mas isso não significaria mais congelar o master. O master continuaria
tendo atualização no período de freeze e seria criada uma nova branch para
a versão que será congelada. Neste período todos os commiters continuarão
sendo fortemente encorajados a auxiliar o lançamento mais rápido possível
da versão, mas novas funcionalidades poderiam ser incorporadas no master
normalmente. As correções de bugs que por ventura venham a existir na
versão congelada serão primeiro incorporadas no master depois do branch
estável da mesma forma que é hoje. Será responsabilidade do commiter que
corrige o bug garantir que este procedimento ocorra desta forma e ele será
cobrado pela comunidade para tal.

  2 - Processo de tomada de decisão

Nós concordamos que em alguns momentos nós entramos em deadlock numa
discussão e em alguns momentos algumas coisas precisam ser decididas, mas
não são.
Neste ponto não chegamos a fechar uma proposta, mas levantamos que não
deveríamos burocratizar muito o processo, mas ao mesmo tempo precisamos
garantir uma maturidade mínima nas discussões para não tomar decisões de
forma açodada.
Diante disso a minha proposta é a seguinte:
Quando algum membro (developer, commiter, RM etc..) da comunidade sentir a
necessidade de discutir algum assunto que seja pertinente a todos os
membros da comunidade e necessite de uma decisão este deverá abrir uma
issue no gitlab com label 'discussion' para que todos os membros possam
discutir. Cada commiter possui o poder de 1 voto para aprovar (+1) ou
rejeitar (-1) tal proposta. A proposta será considerada aprovada caso esta
tenha a maioria dos votos dos commiters considerando o quorum de votação
mínimo de 50% dos commiters. Quem tem interesse na aprovação da proposta
deve provocar os commiters (@nikcname na issue do gitlab que trata do
assunto) a se posicionarem sobre o tema discutido. Uma vez passado o prazo
de 1 semana e no mínimo 50% dos commiters já tenham explicitamente votado a
issue será fechada e a discussão sobre o assunto será encerrada.

Eu preferi primeiro passar essas informações aqui na lista para depois
fazer as adaptações necessárias no arquivo "DEVELOPMENT.md"

Caso alguém tenha alguma consideração a feita sinta-se à vontade para
fazê-la.

Abraços,

-- 
Dois Axé!!!

-----
"Comece fazendo o que é necessário, depois o que é possível e de repente
você estará fazendo o impossível."
                                   São Francisco de Assis
Leandro Nunes
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20160315/20afa31d/attachment.html>