[okfn-br] grande ajuda nos projetos OKBr: vote na issue!

Quinta Abril 16 01:57:16 UTC 2015

2015-04-15 10:25 GMT-03:00 Peter Krauss <ppkrauss em gmail.com>:

>
>> From: Luiz Armesto <luiz.armesto em gmail.com>
>>
>> Sobre centralizar tudo no github, não acho uma ideia tão boa. Em geral os
>> projetos open source possuem alguns canais de comunicação: wiki, lista(s)
>> de discussão, issue tracker e canal IRC.
>>
>>
> Não se trata de "centralizar tudo": precisamos evitar distorções sobre a
> proposta (senão sai todo mundo correndo), pois não é essa.
> Se trata de especializar, como tudo: se não houver fórum especifico para
> debater o projeto e questões altamente chatinhas e especificas do projeto,
> vai apenas poluir a lista geral e fazer as pessoas debandarem da lista,
> pois toma tempo filtrar emails relevantes... E poderia ser uma outra lista,
> mas não precisa: o git envia email avisando que tem posts novos no /issues.
>

Também não acho que tenha que ser na lista geral da OKBr. Sou da opinião de
usar listas específicas caso haja demanda. Veja que já há várias listas
específicas [0] e funciona muito bem.

Do mesmo modo que discutir tudo na lista geral seria ruim, e daria trabalho
para filtrar, discutir tudo *relacionado a um projeto* no issue tracker
dele também demandaria trabalho de filtragem. Esse é o ponto central da
minha colocação.

[0] https://lists.okfn.org/mailman/listinfo/

> Hum... Mas existe algum IRC da OKBr?  Alguém está usando?
>

Não sei se existe um canal da OKBr, acho que não (provavelmente por não ter
tido necessidade), mas a ideia seria de ter canal de projetos que
necessitem de uma comunicação mais imediata, não necessáriamente um geral.

Sei que tem canal da OK, tem canais separados para vários projetos da OK (e
pelo menos um de projeto da OKBr). Se não existir e for algo que ajude
(também não acho que tenha que criar só por criar, tem que ser algo que
melhore a comunicação) é só criar um canal para o projeto e usá-lo

>
>
>>
>> A lista de discussão pode ser única ou separada em "geral" e
>> "desenvolvimento". Na geral normalmente se discute os objetivos do projeto,
>> caminhos a se seguir, popõe-se alterações ou melhorias em um nível mais
>> abstrato, tira-se dúvidas não urgentes (ou mesmo urgentes quando não for
>> possível no canal IRC), dar e pedir opiniões, conversar sobre assuntos
>> diversos relacionados ao projeto, fazer anúncios. Na de desenvolvimento se
>> discute coisas parecidas mas com foco mais técnico, sobre tecnologias
>> usadas, arquitetura, detalhes de implementação, problemas ou dúvidas sobre
>> o código para os quais ainda não se tem decidido como solucionar, etc.
>>
>
> Extato, precisaria no mínimo dessa separação de "geral" e "o resto".. Mas
> justamente "o resto" não é apenas desenvolvimento, e o mundo evoluiu depois
> da invenção das listas, o github/issues tem as duas vantagens:
>

Quando me referia a "geral", não era geral da OKBr, mas geral do projeto.
Então não existe uma "resto", a princípio tudo é discutido na "geral (do
projeto)", se tiver necessidade cria-se outras. Normalmente criam uma de
"dev", mas também podem criar de "i18n" (internacionalização), "design",
"marketing", "volunteers". Vai dependendo da demanda.

>
> * é específico e intimamente amarrado ao projeto
>

Assim como listas.

>
> * é um recurso sofisticado, muito superior a uma lista, que abrange também
> papel de bugtracking e geração de tickets, ou seja, contempla requisitos de
> "governança do projeto" que tanto falam (e pouco fazem) no Conselho da OKBr.
>
>

Particularmente prefiro ferramentas simples que resolvam bem o que se
propões do que ferramentas "sofisticadas" com as quais tentamos solucionar
várias coisa mas acaba que nada sai 100% a contento.

>
>
>> As issues servem em geral para criar tarefas para implementar aspectos do
>> projeto que já foram discutidos (nas listas de discussão preferencialmente
>> ou em reuniões presenciais) e já são consenso, reportar erros ou mesmo para
>> fazer perguntas e dar algumas sugestões para os desenvolvedores (em geral
>> usado por pessoas que estão tento um primeiro contato, para a comunidade é
>> preferível usar as listas de discussão).
>>
>>
> Sim, há que se ter um "filtro", uma "curadoria" sobre o que se posta nas
> issues, e essa é a tarefa do coordenador do projeto (e sua equipe)
>
[...]
> Devo lembrar que (no Github) cada issue recebe um label, e o label
> caracteriza o tipo de discussão e o tipo de comunidade.
> label "bug" = apenas equipe de desenvolvimento tem interesse em estudar, e
> a comunidade usuária de saber que já foi registrado.
> label "new issue" = a equipe de desenvolvimento tem interesse em estudar e
> precisa dar um parecer, mas a comunide participa, não pode ser muito
> técnico.
> label "discussion" = todos participam, e quando a equipe desenvolvedora
> está sem tempo, pode ignorar.
> label ... = seria legal a OKBr padronizar alguns rótulos para sinalizar
> mais claramente quem consultar as listagens de /issues.
>
>

Certo, mas as notificações por email de novas "issues" e comentários são
enviados independentemente da curadoria e do "label" associado. Continua
afetando na possibilidade de se concentrar em determinados tipos de
discussão em momentos diferentes. A possibilidade de deixar passar algo
urgente no meio de discussões mais abstratas continua existendo com ou sem
"labels".

>
>> Então quando estou escrevendo código, pensando em implementação, testando
>> algo e recebo uma notificação que uma issue foi criada ou alguém comentou
>> algo, e não tem alguem responsável por fazer a triagem (apenas projetos
>> muito grande costumam ter), eu paro o que estou fazendo e vou ver o que é,
>> esperando que seja algo diretamente relacionado ao desenvolvimento.
>> Normalmente é por alí que vou ficar sabendo se alguém achou algum erro
>> crítico que precisa de atenção imediata, quais tarefas eu vou me dedicar no
>> dia, o que cada um vai fazer ou está fazendo. Se começar a aparecer muitas
>> notificações sobre discussões gerais a consequencia natural é a principio
>> perder o foco durante o desenvolvimento e em seguida começar a ignorar as
>> notificações, deixando passar algoque seria importante para o "modo
>> developer".
>>
>
> Não concordo com tudo: num projeto grande e "assediado" como o Gastos
> Abertos é fundamental a figura do coordenador ou daquele que for delegado a
> avaliar e rotulas as coisas com devidos *labels*. Antes de receber um
> label a issue pode ser ignorada por toda a equipe, depois de receber um
> label, cada membro da equipe pode ou não "estar sendo chamado" pela issue.
>

A equipe não é grande o suficiente para sempre ter alguém fazendo triagem
para classificar o tipo de conteúdo (uma atividade bem burocrática que, na
minha visão, é dispensável na maioria dos projetos) nem que seria vantajoso
correr o risco de ignorar problemas mais urgentes, que seriam ignorados
mesmo tendo gente trabalhando no projeto naquele momento, porque não está
no horário do responsável pela triagem se dedicar ao projeto.

>
>
>> Isso sem contar a possibilidade de um projeto poder ter N repositórios, o
>> que bagunçaria ainda mais. Alguns acabariam usando a estrutura de um
>> repositório, outros de outro. Teria coisas relacionadas ao que é
>> implementado no repositório A sendo discutida no repositório B. Na hora de
>> procurar algo que foi dito teria-se que visitar todos. Bem caótico.
>>
>
> Novamente é caso simplíssimo (!) de *estabelecer regras/convenções*.
> Regra de nomenclatura de repositórios: apenas um deles (e pode ser um mero
> README e só) recebe o nome do projeto, o resto receberia alem do nome um
> sufixo. As discussões e issues gerais seriam todas levadas para esse
> "repositório mestre".
>

Utilizando listas de discussão (que já é uma convenção) para assuntos mais
gerais, ou mesmo específicos porém abstratos, não temos um novo problema
(em qual repositório discutir) nem necessitamos criar novas convenções
(repositórios tem que ter tal formato de nome e deve-se postar em tal
repositório) ;)

[]'s
-- 
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150415/7ffe5d94/attachment-0005.html>