desenvolvimento, poder e democracia (+- longo)

[Antonio Terceiro]

Oi Daniel,

On Tue, Mar 18, 2014 at 10:47:13PM -0300, Daniel Tygel wrote:
> Recapitulando (já não lembro a ordem, mas vai lá):
>
> Como deve funcionar o envio de novas funcionalidades do noosfero (este acordo
> estava consensuado):
>
> 1. Qualquer proposta de funcionalidade deve ter um AI correspondente
> 2. Se esta proposta não for bug, deve ser enviada para a lista como proposta
> (com alguma justificativa, caso quem enviou queira explicar para a comunidade
> sua ideia)
> 3. Se ninguém na lista reagir em uma semana, não há nada contra, então quem
> propôs pode ficar à vontade de implementá-la e submeter o merge-request
> 3.1 Caso contrário, se alguém for contra, deve justificar suas razões e
> apresentar sua contra-proposta, e aí ativa-se uma discussão, buscando um
> consenso
> 4. Caso não se chegue a um consenso, se tenta numa reunião síncrona de
> comunidade uma mediação, chegando ao ponto de votação no caso de não se
> conseguir um acordo entre as partes.

Eu não me lembro de haver consenso sobre se decidir coisas em votação
pura e simples.

Além disso, toda vez que alguém cria um AI, a lista já recebe uma
notificação automática. Quem estiver interessado pode simplesmente
clicar e ler o AI. Ainda que enviar na lista de novo explicitamente não
seja um problema, é redundante.

De qualquer forma, exceto a parte de votação, eu não tenho um grande
problema com esse processo em si, e acho que dentro do possível isso vem
sendo feito. Só não acho que se deva recusar contribuições que não
viarem do Jeitinho Certo™, nem tratar mudanças que não passaram
estritamente por esse processo como contrabando.

>    Era algo assim. Não tive paciência agora de procurar os e-mails. Mas
> tínhamos acordado isso, bem concretamente, e desde então a EITA tem seguido
> isso ao pé da letra: qualquer nova funcionalidade, enviamos à lista. Qualquer
> uma.
> 
>    Com relação ao processo de review e aprovação, também fizemos propostas
> bastante concretas, baseadas em procedimentos democráticos que permitam a
> participação de usuários, e não apenas meritocráticos que valorizam apenas o
> desenvolvedor. Ou seja, era uma proposta "user-centered" ao invés de
> "developer-centered", já que acreditamos que as implementações do Noosfero
> devem servir aos/às usuárias/os, e não ser apenas um prazer das/dos hackers.
> 
>    Esta proposta tinha um certo grau de consenso, mas não total. Vários
> desenvolvedores foram contra ela, pois ela ia numa lógica de poder
> compartilhado ao invés da lógica do poder meritocrático (onde a meritocracia
> era entendida como linhas de código enviada).

Na minha opinião "os desenvolvedores são contra uma lógica de poder
compartilhado" é um maniqueísmo que não acrescenta nada na discussão ...
toda a discussão sobre isso foi baseada em questões técnicas e práticas,
e eu me sinto um pouco ofendido quando você tenta pintar "nós
desenvolvedores" como tecnocratas opressores.

> Mas enfim, já que Terceiro pediu propostas concretas, segue também:
> 
> Proposta de como definir quais merge-requests serão priorizados na fila de
> reviews para cada release, já que não há pessoas suficientes fazendo review de
> tudo o que chega:
> 
> 1. A cada ciclo, o conjunto de merge-requests é analisado pela comunidade, em
> uma reunião síncrona (virtual, tipo hangout), e se busca consensuar quais devem
> ser priorizados no review.
> 2. Definida a ordem dos merge-requests do ciclo, cada ator diz quantos e quais
> dos merge-requests vai fazer review, como sua contribuição ao processo.
> 3. Os AIs revisados entram no ciclo, na ordem de priorização. Ou seja, mesmo
> que um AI menos importante tenha sido revisado, terá que esperar que um AI
> considerado mais importante democraticamente pela comunidade seja revisado.
> Isso é para impedir os fura-filas do ambiente competitivo de que "o AI que for
> revisado ganha precedência", o que acaba centralizando no desenvolvedor, e não
> no usuário final.

Eu não entendo porque isso precisa ser feito dessa forma. Todo mundo,
seja desenvolvedor ou não, já tem uma forma de priorizar merge-requests,
que é ir lá e revisar/testar/comentar!

Se você está "a favor dos usuários", você escolhe os merge-requests
"dos usuários", vai lá, revisa, e o merge-request entra. Se você
discorda de um merge-request, você vai lá, comenta, mostra com
argumentos objetivos porque aquele merge-request é um problema, e
espera-se que os envolvidos cheguem a um consenso.

Essa _é_ uma forma de votação. A diferença é que você vota com trabalho
(não apenas código), e não só com opinião.

Ao invés de primeiro definir prioridade pra depois dividir, a idéia toda
é que a divisão voluntária define a prioridade! Não faz nenhum sentido
escolher um merge-request porque ele é importante para "a comunidade", e
depois ninguém querer revisar, ou alguém "ser obrigado" a trabalhar em
algo sobre o que não tem qualquer interesse porque foi decidido "pela
comunidade".

Vamos ser realistas: cada ator tem as suas prioridades. Para a Colivre a
prioridade são as funcionalidades que interessam aos seus clientes, para
a EITA a prioridade são as funcionalidades que interessam ao CIRANDAS,
e assim por diante.

Isso não quer dizer que "os usuários" nunca serão priorizados. Nos
projetos da Colivre a gente sempre tentar incluir recursos para melhorar
usabilidade, e a EITA também tem feito um bom trabalho com relação a
isso; em ambos os casos porque nós vimos isso como prioridade. O ponto é
que isso é muito mais viável de baixo pra cima do que de cima pra baixo.

>     O debate democrático do item 1 seria em clima de busca de consenso e
> construção, olhando todos os merge-requests, a quantidade de "I cares", e
> levando-se em conta argumentos de cada uma das pessoas responsáveis por
> implementações do noosfero, sobre coisas que parecem ser importantes para cada
> plataforma.
> 
>     Esta segunda proposta, colocada acima, é concreta, plenamente factível e
> poderia encaixar dentro dos ciclos de desenvolvimento. Infelizmente também foi
> descartada, chegando ao ponto da EITA enviar uma mensagem aqui na lista dizendo
> que não nos envolveríamos em fazer reviews enquanto não se chegar a critérios
> claros, transparentes e democráticos de priorização do que entra ou não entra
> no core. Por isso não estamos revisando códigos de outros. Os critérios não são
> claros, e sempre acontece alguma "exceção" e de repente algo surpreendente
> aparece numa release.

Pois é, o problema é que você está vendo a coisa ao inverso. Os
critérios específicos não são claros e nunca vão ser; eu não conheço
nenhum projeto que tenha isso definido com essa precisão que você está
esperando, que você possa usar como um checklist aprova/não aprova.

Na minha forma de enxergar, o critério geral é que entra no core aquilo que:

  0) é útil pra alguém, e não atrapalha os outros

  1) tem interesse suficiente da comunidade para alguém escrever, e pra
  outros alguéns comentarem, revisarem, testarem etc.

  2) não pode ser feito como um plugin

Então se vocês estivessem revisando código dos outros, vocês estariam
participando do processo de priorização, e de decisão do que entra e do
que não entra.

>     Propostas não faltaram, e isso faz tempo. Dizer que estamos apenas jogando
> palavras ao ar, e não apresentando propostas concretas é um baita reducionismo.
> Havia um sonho de que poderíamos fazer um processo consorciado de tomada de
> decisão no noosfero, em clima de gestão coletiva. É daí que se originavam as
> propostas e o entusiasmo que tivemos com a resolução do FISL 2013 de realização
> de processos coletivos da comunidade.

Do meu ponto de vista os processos coletivos da comunidade estão aí, só
falta a comunidade. :)

Pra mim o grande problema é que vocês estão tendo dificuldade de lidar
com o fato de que as propostas de vocês, independente do mérito delas,
não foram consenso. Infelizmente isso faz com que a gente fique
discutindo isso de novo e de novo, em loop infinito.

E vocês estão tendo uma postura de dono da bola: se não for do meu jeito
ou eu não brinco. Isso é uma pena, porque na parte da brincadeira que
vocês escolheram participar, vocês estão dando uma boa contribuição.

Um abraço,

-- 
Antonio Terceiro <terceiro at colivre.coop.br>
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20140320/35e8129b/attachment.pgp>