Re: Processo de Decisão e Congelamento

Tue Mar 15 20:12:31 BRT 2016

De acordo Leandro, vamos colocar isso no development.md.

Vale apenas frizar que o cargo de RM não é o de cristo que carrega a cruz
do noosfero e não vejo ele tendo nenhuma obrigação além de qualquer outro
commiter de corrigir testes.
A obrigação de corrigir os testes é do commiter que clicou no Accept para
integrar o código.

Não gostaria de ver ninguém fazendo trabalho voluntário ou de maneira
forçada e sim que o fizesse tendo o devido tempo e recursos alocados,
sobretudo no caso do RM. Ou seja, o RM não tem nenhuma obrigação a mais de
integrar código se comparado com qualquer outro commiter.

Não queremos transformar o RM e a organização que o sustenta em burro de
carga.

Aliás, a última integração quebrou testes, Rafael está precisando de ajuda
para corrigí-los. Por favor reverter se tomar muito tempo.

abraços!
bráulio

On Tue, Mar 15, 2016 at 6:40 PM Leandro Nunes <leandronunes at gmail.com>
wrote:

> 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
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20160315/10c8e1ca/attachment-0001.html>