Criar página com a demanda de projetos para fazer

[joepreludian]

Basicamente devemos criar um arquivo .md no repositório do comitê informando quais são os projetos que estão necessitando de desenvolvimento.

Também é interessante saber dos quais qual tem maior necessidade.
Pelo que vejo haverá vários crawlers/ferramentas e é interessante que haja um índice do projeto e do que ele se propõe a fazer.

[gartz]

Sim, eu até comecei a fazer algo assim, mas ainda não terminei, quero fazer arquivos pra explicar o que são dispostivos de backend, backend e frontend mais adequadamente, então ficará fácil de adicionar projetos que se qualifiquem nesses módulos conforme nossa necessidade.

[joepreludian]

Acredito que mais importante que estas definições, Gabriel, é que façamos
uma lista dos projetos que iniciarão/que estão em progresso e eleger um
líder pra cada, ou ao menos um responsável ou dois que cuidem daquele site
e que coordenem o padrão de qualidade de tal. O que acha?

Em 19 de maio de 2015 19:44, Gabriel Reitz Giannattasio <
notifications@github.com> escreveu:

Sim, eu até comecei a fazer algo assim, mas ainda não terminei, quero
fazer arquivos pra explicar o que são dispostivos de backend, backend e
frontend mais adequadamente, então ficará fácil de adicionar projetos que
se qualifiquem nesses módulos conforme nossa necessidade.

—
Reply to this email directly or view it on GitHub
#6 (comment).

Atenciosamente,

Jonhnatha J.R. Trigueiro
joepreludian@gmail.com
+55 84 8888 4224

[ozifrankly]

Acho interessante criar uma lista de e-mail ou slack da vida para que todos possam dar opiniões e discutir projetos. O que acham?

[joepreludian]

Vou te enviar um convite, parceiro.
On May 19, 2015 9:59 PM, "Ozifrankly Silva" notifications@github.com
wrote:

Acho interessante criar uma lista de e-mail ou slack da vida para que
todos possam dar opiniões e discutir projetos. O que acham?

—
Reply to this email directly or view it on GitHub
#6 (comment).

[cezarant]

Pessoal, queria elogiar a iniciativa de criar esse comitê e dizer que eu achei as sugestões técnicas aqui excelentes, principalmente na questão de pull requests e organização de projetos.

Só que há ainda, algumas questões de estratégia e filosofia por trás do trabalho da OPS, que ainda não ficaram claras para mim (e acredito que possivelmente para outros devs também).

Podem ser que já tenham sido discutidas, mas eu gostaria de dar algumas sugestões. Como o assunto é amplo, criei um vídeo e vou tentar agrupar a galera em alguma reunião para discutirmos o assunto.

O vídeo onde eu resumo minha impressões a respeito da filosofia atual da OPS é este aqui... https://youtu.be/HehBHedEPks

Abaixo segue o resumo do vídeo em algumas perguntas:

1 - Como são originadas a decisão de novas features? Sugestões do Lúcio? Consenso entre os devs? Verificando sugestões dos usuários?

2 - A barreira de entrada é muito baixa para novos desenvolvedores. Isso é o ideal, na opinião de todos? Não seria legal pensarmos em um fluxo de chegada, desses novos devs? Ao menos um "código de condulta" simples, em pdf? Desde já, aviso: odeio burocracia, mas acredito que nem todo mundo é alto-gerenciável.

3 - Usar o Trello, dividindo os devs por times, realmente é uma boa idéia na opinião de todo mundo? Eu particularmente, acho que só o controle de issues aqui do Github já funciona muito bem. (Pelo visto de alguns comentários no comitê, outras pessoas também acham isso). Como o mercado hoje obriga desenvolvedores a serem multi-disciplinares, penso que um time só de devs e um de designers já tava de bom tamanho. Mas é só uma opinião pessoal.

4 - Porque não forcamos em melhorar o engajamento dos usuários e interatividade dos usuários, com as aplicações que já existem, ao invés de pensarmos em desenvolver coisas novas e definir arquiteturas de novas aplicações? Eu mesmo me incluo nisso, fiquei um final de semana inteiro tentando refatorar o crawler de secretários de gabinete em nodejs, não avisei a ninguém que estava fazendo isso e quando percebi, já havia um outro membro da OPS que já o havia reescrito, quase totalmente. Fico pensando se o tempo que gastei neste sábado, apesar de achar que o crawler de secretários é extremamente importante para a OPS, se fosse gasto em atividades mais simples (as issues que estão no comitê por exemplo) acredito que seria muito mais bem aproveitado.

5 - Que tal pensarmos no seguinte fluxo padrão:

1 - Usuário conhece o trabalho da OPS nas redes sociais do Lúcio (YouTube, Facebook) e...
2 - Vai pro site para ver os resultados agregados, totalizações, ver informações em como ele pode contribuir (pesquisar nepotismo, investigar despesas e tirar fotos de empresas suspeitas) e caso ele se interesse...
3 - Direcionar ele pro app. Que teria o mínimo de detalhamento de informações. A idéia do aplicativo enxuto, poucos botões e de funcionamento simples, como já está app fiscalize me agrada bastante. E acredito que quanto menos informações no app, melhor pro desenvolvimento.

[VanderleiDenir]

Concordo com tudo o que você falou no videos e acima.
Alguns comentários em relação ao site:

• O principal foco é facilitar o trabalho do Lúcio e do Marcelo, visto que são os que mais utilizam o site, mas que o usuário leigo também possa visualizar/participar. Considero sempre as sugestões dos usuários no site.
• O processo descrito no comitê não esta sendo seguido. Talvez poderia ser simplificado para ser aplicado.
• Embora a a barreira de entrada seja bem baixa, quase nula. As tarefas não estão mapeadas e descritas nas issues do Github e disponível para a ajuda da comunidade. As poucas tarefas que existem são grandes e exigem muito trabalho e conhecimento em uma stack grande. Com isso também temos o problema de não saber o que o restante do time esta fazendo e fazer coisas que outras pessoas estão fazendo ou que ficaram obsoletas mesmo antes de serem utilizadas.
• Não vejo motivo para ainda utilizarmos o Trello, visto que é possível fazer a mesma coisa centralizada diretamente no GitHub. Mesma coisa com os grupos de DEV, onde existem os grupos no Slack, 2 grupos no Telegram e grupo no Skype, onde deveríamos definir apenas um e torna-lo publico aos interessados (como o grupo do serenata no Telegram e outros).
• Uma das deficiências da OPS é justamente o que falou no vídeo, o marketing nas redes sociais. Vejo como o marketing dos grupos serenata e/ou humilde congressista é simples, porem engaja muitos usuarios que passam a seguir e divulgar o trabalho.
• Uma identidade visual também ajudaria bastante, por exemplo, ao acessar os diversos meios de informação da OPS, parece que estamos em um lugar totalmente diferente.

Inventario de sistemas:
Site: http://ops.net.br

• Sistema de comentários: https://disqus.com/home/forum/ops-net-br
• Ideias, Feedback e report de erros: http://feedback.userreport.com/9cf4c59a-d438-48b0-aa5e-e16f549b9c8c
• Monitoramento de acessos e uso: Google Analitycs.

Blog: http://luciobig.com.br
Forum: https://groups.google.com/forum/embed/?place=forum%2Fcomo-salvar-o-brasil-educacao (link no site).
Grupo no facebook: https://www.facebook.com/operacaopoliticasupervisionada
YouTube: https://www.youtube.com/user/ldb1969
Aplicativo Fiscalize (Android, IOS e Windows Phone).
Resumo Fiscalize: http://104.131.229.175/fiscalize/pro/ (Resumo das notas mais marcadas como suspeitas, mesma lista que esta presente no site).
Landing Page Fiscalize: http://www.opsfiscalize.com.br/

[cezarant]

Algumas sugestões minhas pra torna o comitê mais convidativo:
1 - Todas as issues ficarem concentradas em um repositório central.
2 - Pra facilitar, sugiro a divisão de issues entre "Devs" quando houver e desenvolvimento "Não-Devs" para issues que envolvam UX, Design ou qualquer tarefa que não seja de desenvolvimento de software. Para estas tarefas, quando possível, sugerimos a criação de um vídeo explicando quais o requisitos envolvidos.
3 - Outras tags seriam "Up-for-grabs" para devs iniciantes ou recem-chegados, "Disponível" para issues em geral. "Em desenvolvimento" para quando fosse acordado que uma tarefa merece ser desenvolvida.
4 - Um desenvolvedor só poder pegar uma issue por vez. Dessa forma, se houver 2 desenvolvedores envolvidos no projeto, só podem haver 2 issues no status "em desenvolvimento".
5 - Toda issue precisa ter pelo menos dois participantes pra começar a ser desenvolvida, porém caso haja pelo menos 1 "pedido de vista" e o requerente apontar o motivo e outra issue mais simples a issue será colocada "em discussão" é caso em uma semana nada seja feito ela retorna pra condição de "disponível"
6 - Crawlers e transformações de dados em informações, sempre que possível, ter a opção de entregar os resultados em JSON.
7 - Crawlers, listagens e exibicao de informações, sempre que for possível, tentar respeitar o seguinte padrão de apresentação:

• Dados macro pra serem exibidos no app

• Meta Dados para serem exibidos no site

• Dados detalhados nos sites governamentais

8 - Todo desenvolvedor novo, só ter acesso a outros canais da OPS, (chat e Skype) após fazer um Pull Request de alguma issue de baixa complexidade.

[ ] Hierarquia para justificar novas features:

• Pedido do Lúcio

• Pedido do usuário, que seja relevante

• Mapeamento de comportamento do usuário através do Google Analytics

As motivações para as alterações acima são:
1 - O modelo atual, exige que um desenvolvedor fique muito dedicado. As tarefas são de longo prazo é bastante específicas
2 - O modelo atual, não é convidativo pra novos devs.
3 - Apesar da baixa barreira de entrada ser um dos grandes atrativos da OPS, acreditamos que há duas exigências que são necessárias pra que um developer possa integrar o time:

• Resolver ao menos uma issue simples

• Saber fazer um Pull Request utilizando GIT.

Esta decisão pode parecer autoritária e meritocrática, mas ela tem os seguintes objetivos:

• Fazer com que os novos desenvolvedores se sintam "acolhidos" ao projeto. No modelo atual, corre-se o risco de um Dev curioso ao projeto entrar , tentar resolver alguma tarefa complexa e durante o decorrer de desenvolvimento da mesma, precisar ir embora. O que traz frustração para os dois lados.
• Na motivação (totalmente aceitável é justificável) de querer implantar tecnologias modernas e que o mesmo tenha domínio, a OPS corre o risco de que contribuições simples que poderiam ser feitas por esse recem-chegado, fiquem de lado. Importante ressaltar que até aceitamos discussões e argumentações a respeito. mas como nosso tempo é escasso, precisamos que, novas idéias só possam ser agregadas ao projeto, após um mínimo de contribuição.

[VanderleiDenir]

Mudaria apenas o seguinte:
1 - As issues ficam separadas em seus respectivos projetos. Os Projetos recebem as tags informativas da stack utilizada, uma pagina explicativa com os objetivos e configurações necessárias para funcionamento local. Projetos descontinuados são explicitamente marcados ou excluídos.
8 - Existir apenas um grupo de comunicação, totalmente aberto a quem quiser participar, limitando os assuntos aos objetivos da organização. Mesmo os não desenvolvedores poderiam contribuir com ideias e opiniões nas discussões.

[cezarant]

Colocar no projetos, uma descrição do projeto , a Stack utilizada... eu até acho legal. Mas na questão das issues, você não gostaria de pelo menos a gente fazer um teste? Tipo... colocar todas as issues num lugar só?

Porquê da forma que está hoje eu acho muito trabalhosa, pra priorização. Tipo... ver todo o trabalho sabe?

Imagina um que saca de Android e de ASP.net? No modelo atual, o cara teria que entrar no diretório de issues do projeto do site , procurar alguma issue que lhe agrade e se não achar, ir no diretório de issues do app Android e procurar alguma issue pra fazer.

Além de achar que isso exige uma auto-motivacao que nem todo mundo tem, na minha opinião, corre-se o risco de acontecer algo que eu apontei no vídeo: desenvolvedor investindo tempo em issues de longo prazo, sendo que há outras mais simples e de curta duração, que talvez possam trazer mais engajamento e que ele poderia estar atendendo.

A restrição ou não dos canais de participação e um negócio polemico...rs..
Eu particularmente, acho que uma vez que o Lúcio já tem vários canais pra galera discutir ideias, propor sugestoes e tal...não seria ruim criarmos um canal só pra nós desenvolvedores e Não-Devs discutirmos sobre o que já está em desenvolvimento sabe?
E acho que nada mais justo, exigir uma contribuição mínima (resolver uma issue simples) pra entrar neste canal.
Seria uma pequena barreira de entrada, mas que eu acho que ajudaria muito pra dar fico ao canal.

Seria legal se mais devs opinassem neste caso.

[cezarant]

Pra não "paralizar o processo", vou começar a adiantar os pontos que concordamos e estes dois a gente discute quando puder se reunir.

[TexKiller]

Bom dia, galera.

Só pude assistir ao vídeo e ler os comentários agora, e concordo com muito do que foi dito.

Como eu comentei antes, estou viajando durante este mês, e estou com muito pouco tempo livre. Pretendo elaborar uma resposta maior em breve.

Tenho que sair agora, então só adianto que a única objeção minha é sobre a paralização do desenvolvimento do novo aplicativo enquanto melhoramos o site e o Fiscalize. O resto das sugestões me parece ótimo. Quando eu escrever minha resposta detalhada explicarei melhor meu ponto de vista. :)