Importância de reunião síncrona

Tue Oct 8 17:26:51 BRT 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/08/2013 03:22 PM, daniel tygel wrote:
> Uma pergunta, só para saber:
> 
> O que é mérito? linhas de código?

Conhecimento técnico. É subjetivo? Sim.
Suponha que você vai construir uma casa. Quem vai dizer quantos
andares ela poderá ter com base no terreno e qual o tamanho da base?
Uma sociedade equalitária é onde todos tenham espaço para discussão ou
onde todos tenham o mesmo poder de voto mesmo em coisas estritamente
técnicas?
Se uma equipe pequena de responsáveis técnicos abrirem espaço para
todos decidirem, até quem tiver passando por ali, vão querer botar 20
andares num terreno sem estrutura. Totalmente equalitário, mas vai cair.
O mesmo vale para uma cirurgia, onde não vão discutir sobre o quanto
vão enfiar um bisturi em você ou ao projetar o freio de um caminhão.

Existem discussões que são inerentemente técnicas, que demandam
conhecimento específico e experiência, além de conhecimento do projeto.

Um engenheiro não vai chegar pra outro fazendo um arranha-céu, dar uma
olhadinha nele e dizer: você vai botar uma piscina em formato de
esfera lá no topo. Primeiro: ele não tem conhecimento do projeto pra
saber se é possível. Segundo: não é ele quem vai sofrer se desabar
(supondo que desabe durante a construção e ninguém fique ferido).

> Gosto destas linhas no wikipedia
> (http://en.wikipedia.org/wiki/Meritocracy):

> /By definition, the principle of meritocracy could not be effective
> in a non-competitive society or environment.//^[44] 
> <http://en.wikipedia.org/wiki/Meritocracy#cite_note-44> /
> 
> 
> Estamos num ambiente de concorrência entre nós ou de construção 
> coletiva? Onde tem construção coletiva, e não concorrência, é
> melhor a democracia. Funciona.

Os projetos que eu mencionei e os que estão listados aí na página da
wikipedia que você postou são democráticos. Porém ao mesmo tempo as
decisões técnicas são feitas por pessoas com mérito.

Se eu fizer um projeto individual, quem define o mérito serei eu, por
exemplo. De início, só eu. Posteriormente, em quem eu confiar. Se o
barco afundar, serei eu o responsável.
Com maior grau de maturidade do projeto, os contribuidores (por linhas
de código, revisões de código, conhecimento demonstrado em discussões,
novas funcionalidades, respeito às regras) ganham confiança e a
tendência é que o projeto tenha pernas suficientes para resistirem à
saída de pessoas dele. A partir desse momento o projeto ganha uma vida
própria e um gerenciamento mais descentralizado.

Porém ver alguém destruir a casa que você ajudou a construir ou
impedi-la de mudar vai agradá-lo? Não necessariamente.

Voltando ao software, que construção coletiva para software há do que
todos colocarem as mãos nele e efetivamente fazerem algo?

Se o problema reportado por você fosse abordado de maneira
colaborativa, de construção coletiva, ele não seria exposto da forma
que você fez.
Num ambiente colaborativo todos são responsáveis por todos as falhas.
Ou seja, vocês poderiam testar o master com frequência e prever o
conflito.
Reuniões são suficientes para evitar esse tipo de problema: não, não
são. As coisas que podem fazer cada ambiente quebrar são obscuras,
difíceis de encontrar, de prever ou até mesmo de entender.
Como lidar com isso? Fazendo testes automatizados, cobrindo o que é
importante e, pós-alteração, verificando as falhas nos testes
decorrentes disso e abortando.
Outra forma é ter pessoas experientes revisando o código, que terão
maior experiência e entendimento sobre o que pode dar errado ou melhorar.

É assim em todo projeto de software livre minimamente organizado, que
não demore 2 ou 3 anos para lançar cada versão e que não tenha
centenas de usuários para testar. A Mozilla e o OpenOffice num passado
não muito distante dependiam de pessoas testando extensivamente o
produto antes de cada lançamento porque não tinham bons testes
automatizados.
Ambos melhoraram muito nos últimos anos a qualidade dos lançamentos e
a eficiência justamente por investirem em testes automatizados, nunca
deixando de lado a figura do revisor de código, porque fatores de
qualidade internos dependem dele (e os testes garantem os fatores de
qualidade externo).

Os fatores de interação com o usuário e funcionalidades base são
tratados nos AI. Eles podem ser discutidos em reuniões síncronas mesmo
sem a participação de todos porque uma decisão vital para o projeto
vai obrigatoriamente passar por toda a comunidade. Ou seja, é mais
democrático, colaborativo e inclusivo permitir que todos tenham espaço
para falar e discutir, de maneira equalitária.
As reuniões presenciais não suportam isso, porque uma ausência
significaria perda de poder de fala, de voto, de participação.

Fazendo um paralelo com a casa, é seguro delegar a discussão das cores
das paredes, até certo limite da posição das paredes, encanamentos e
tomadas. Mas estruturalmente não é.
Por exemplo, é melhor ficar no lado nascente que no poente. Já
imaginou se todos fazem os apartamentos num prédio no lado poente, o
nascente fique vazio, ele incline com o peso e caia?

Lembrando que atualmente a Colivre investe na revisão. Seria mais
democrático se todo mundo investisse, não?
A maioria dos revisores dos projetos open source de médio a grande são
pagos. Ou uma empresa faz isso como colaboração com o projeto, ou
usuários doam para ele.
Então, caso a Colivre precise investir num merge request necessário
para que ela ganhe dinheiro (e tenha dinheiro pra investir no
projeto), isso deve ser levado a votação?

Isso mostra, como Terceiro já mencionou também, que o nível de
maturidade do projeto e colaboração externa não estão altos o
suficiente para que seja possível a comunidade andar com as próprias
pernas.

Como lidar com isso? Com reuniões para discutir sobre onde aplicar o
pouco recurso disponível ou ajudando onde for possível?
A ajuda pode ser em melhoria de experiência do usuário, envolvendo
aplicação de teste A/B por exemplo. Corrigindo bugs, testando o
master, trabalhando efetivamente para corrigir os problemas que
ocorram, se comunicando.

Nada que precise de poder decisório em reuniões síncronas, do meu
ponto de vista. O que falta por aqui é mais mão na massa mesmo, mas se
não puderem e quiserem doar, por exemplo ;).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.21 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSVGqLAAoJEMzgGcmGlt4BoSgP/17Ko3n30vICrYXgwbWGRY8w
BxLPSRzxjwjyynpJ21XzeGU/ccvEk4BxHYFgPgPpWmhvCiu3n9ZJ484Kq6TAjC03
MFCFuxaJq/FlUdAHibgrVg92yUjNAYyyJIWu0OAs90i+K3f8hoFZ062uxjRlXK6a
mnHYxF8nwS8go3dETgWA+AGbxMpNzVToJiptjErcK37QWsNkRV16XS6Lx/+EZKv4
tvYF3Vdq8NlUsgS/BmMr5u5PQ0sIcc9a9h3nUw5JyaEV01jE37opsuK2DHVF2TFt
laTe50tEbHSz6SffuKgiHGZL861DfASEa4kTJMy7H+//jbATEizy8aw+WsMQ8lFh
1OK/hr6lf7xaSu0Cxd1JhC14aCe2kKLYgCoycReXS7mM2IQmUWcz7DDcuAbVC8Si
d0O8kCrpV43LT5AiPDPKcWnu+L1ZTpH2KxEs4qzK+RdgrRs4+IWlfF8NNvuCmWIA
wXdISDPfy7gcg44DmKU6+0Qm8yjfiHlC8buAbgp0vqLHexR4xzwncSSvdpsjNWQ5
ljEjc0tgG+Qx3owIOzTXkCL9hl8zR4Cw1Y9spXhDGsVYmz7NMvx1A48evY/RXSrO
kF8YObK1gK7ygHHSsxWu/dxwtusict5sTRliysAOgv6kOEtfFMs39dGAbhD7v9cA
1zbfg5X9MFNmOABe1+hO
=0UrS
-----END PGP SIGNATURE-----