Software Público Brasileiro

@leandronunes @vfcosta o que vocês acham de trazermos alguns destes plugins para a árvore oficial do noosfero?

@joenio meu jovem os plugins que desenvolvemos estão aqui: https://softwarepublico.gov.br/gitlab/groups/noosfero-plugins

Conceitualmente não concordamos que os plugins devam fazer parte da arvore oficial do noosfero. Na verdade acreditamos que vários plugins não deveriam fazer parte da árvore do noosfero.

@leandronunes eu sei que estão em https://softwarepublico.gov.br/gitlab/groups/noosfero-plugins e sei também que conceitualmente vocês preferem outra abordagem, mas creio que você leu o que escrevi na issue e percebeu que estou sugerindo migrar alguns plugins, pontuei algumas vantagens em fazer isso. você poderia pontuar quais desvantagens impedem vocês de seguir esta sugestão?

a comunidade noosfero tem adotado a abordagem de manter na árvore oficial do noosfero, seria interessante que vocês flexibilizem isso para que pudéssemos ter um ganho geral maior. fazendo isso nós vamos contribuir revisando, refatorando e incorporando o código de vocês ao repositório oficial do noosfero, isto trará um ganho principalmente na distribuição destes plugins para outras instâncias de noosfero.

@ricardopoppi é interessante você participar deste debate aqui.

a principio me parece uma boa que a arvore oficial do noosfero reflita o código mais atual dos plugins mantidos atualmente pelo serpro. @leandronunes qual seria o(s) ponto(s) negativo(s) disso?

@ricardopoppi @joenio a maioria destes plugins só são utilizados por nós mesmos (participa, juventude, etc.).

O principal ponto negativo de colocar isso na árvore principal é que isso traz uma burocracia a meu ver desnecessária para manter e evoluir os plugins, uma vez que a maioria da equipe não teria permissão para modificar diretamente o código (ficaríamos dependente de merge requests).

Além disso, me parece artificial colocar coisas de uso específico em um repositório que deveria conter o núcleo do sistema. Isso aumenta o trabalho de manutenção da equipe responsável pelo core e não me parece um modelo escalável de desenvolvimento (imagina se tivéssemos centenas de plugins?). Já passamos por problemas desse tipo em migrações de plataforma e algumas vezes adotamos a solução de desabilitar os testes de alguns plugins para que a build seja gerada com todos os testes passando.

É comum em diversos sistemas que os seus plugins sejam geridos de forma separada ao core. Acredito que a responsabilidade de mante-los deve ser distribuída entre as equipes interessadas nos seus plugins e o noosfero deveria dar um suporte oficial a instalação de plugins externos ao core e que não sejam de uso comum.

Concluindo, eu sou a favor do movimento contrário: retirar plugins que são de uso específico da árvore principal e delega-los as suas respectivas partes interessadas. Isso não invalida que, caso sejam de interesse geral da comunidade, eles possam ser incorporados.

@vfcosta uma das principais metas deste projeto com a Presidência é tornar o Participa.br uma plataforma facilmente replicável por outros estados, municípios, empresas ou pessoas. Onde for possível, devemos também tornar estes plugins específicos do Participa, Juventude ou Dialoga em plugins de uso geral para qualquer interessado em subir plataformas de consulta pública e participação social. Isto deve ser possível sem necessidade de esforço em desenvolvimento/adaptação de plugins específicos.

Entendo que traz alguns pontos negativos, mas também traz alguns pontos positivos como mencionei anteriormente, sim, conheço projetos que usam a abordagem que você sugere, também conheço projetos que sugerem e adotam a abordagem que a comunidade noosfero tem usado, um exemplo é o kernel linux, onde é incentivado que os módulos (drivers, etc) fiquem no repositório central.

De fato, plugins específicos não devem ficar junto ao repositório central/core, não estou sugerindo migrar todos, ao menos os que trazem funcionalidades imprescindíveis, eu não conheço todos que estão lá, mas pelo nome deles me parece interessante migrar os seguintes:

• gamification
• proposals_discussion
• community_hub
• pairwise
• comment-paragraph (creio que este ficou obsoleto em relação ao proposals_discussion, certo?)

Bem, não acho válido continuar discutindo as vantagens ou desvantagens entre manter os plugins juntos ou separados, esta é uma questão bastante subjetiva e cada um vai ter uma opinião diferente. Precisamos apenas ter uma resposta final de vocês/Serpro se será possível trazer alguns destes plugins para o repositório oficial do noosfero, isto vai definir se iremos ou não revisar o código destes plugins, refatorar e torná-los mais genérico.

Vocês já sinalizaram que não gostariam de fazer isso, peço que vocês confirmem aqui se a decisão é esta mesmo. Valeu!

@joenio @vfcosta valeu pela discussão, ela não só aprimorou meus conhecimentos sobre modus operandis dos projetos de SL como deixa uma boa documentação sobre pŕos e cons dessa decisão aqui na plataforma pública de desenvolvimento de software (softwarepublico.gov.br).

sobre o nosso caso concreto, acho que o caminho é priorizar para estar junto ao core os plugins que qualificam o noosfero como plataforma de participação social, e que ao mesmo tempo não sejam específicos do Participa. O que acham?

@joenio decidindo por aí, o que exatamente o serpro precisaria dispor para esse nossa estratégia?

@ricardopoppi o Serpro não precisa dispor nada, apenas dar sinal verde.

@joenio não precisa pedir nossa permissão para isso meu jovem :) O código é livre se alguém quiser pegar e incorporar não há problema algum. Conceitualmente somos contra, mas a comunidade noosfero HOJE faz desta forma. Ser contra significa que não nos esforçaremos para que o código vá para o core, mas não podemos impedir que outras pessoas o façam. Inclusive o comment-paragraph foi um plugin que braulio incorporou "sem a nossa autorização". O que pode acontecer é que se ficar burocrático para nós manter a versão do comment-paragraph no core evoluiremos o plugin independente da comunidade. Não quer dizer que isso esteja acontecendo hoje, mas isso "em tese" pode acontecer. Ainda vamos levantar essa discussão na comunidade para saber se esta ainda é a visão da comunidade, mas no momento essa é a nossa posição. Outra coisa comment-paragraph não tem nada a ver com o proposal_discussion. Inclusive o comment-paragraph já está no core como mencionei acima. O proposal_discussion precisa melhorar o plugin, pois ao longo do tempo várias coisas específicas para o dialoga foram feitas que serão bizarras de ter no core do noosfero. o comment-paragraph é o plugin utilizado nas consultas públicas. Uma coisa que quero deixar clara para todos que em alguns momentos tenho a impressão de que isso não está claro é o seguinte: A equipe do Serpro quer desenvolver "SL de verdade" inclusive já mandamos patches para upstream de outros projetos ( ex: gitlab), mas nem sempre a conjuntura política nos permite realizar o trabalho do jeito ideal e temos que fazer o possível (EX: este é o motivo não seguirmos o core do noosfero integralmente, mas pretendemos seguir ou ao menos minimizar essa diferença ). E também ao mesmo tempo nós do Serpro (por unanimidade) temos o sentimento que a comunidade não está aberta a discutir conceitualmente alguns assuntos, então como estes assuntos são vistos por nós como "dogmas" e nós não concordamos com os "dogmas postos a forma que nós encontramos de ainda interagir com a comunidade do Noosfero é tomar algumas atitudes de forma unilateral que permita ainda conviver com os temas tratados com a comunidade (a decisão dos plugins é um exemplo). Resumindo não precisamos dar sinal verde. Joguem duro ;)

@leandronunes não iremos criar um fork destes plugins, é exatamente este tipo de ação que causa o problema que estamos trabalhando para minimizar aqui! Acredito, fortemente, que você entendeu o que eu quis dizer com 'sinal verde'.

Não vejo dogma algum, ninguém impede você de iniciar qualquer discussão, portanto, não entendo a afirmação "comunidade não está aberta".

O que significa "ficar burocrático" para vocês? Creio que você está se referindo ao processo de revisão de código e controle de qualidade feito antes de incorporar código ao repositório oficial, se for isso mesmo, não vejo como fugir disso em um projeto de software livre, a maioria dos que conheço tem processos semelhantes.

Status changed to closed

Acredito então que o caminho será manter os plugins do Serpro em seus próprios repositórios, ou seja, fora da árvore oficial do Noosfero. Manter uma cópia desses plugins no repositório do Noosfero ao mesmo tempo que o Serpro evolui eles criará uma divergência entre os plugins, e é bem possível que os plugins no repositório do Noosfero fiquem desatualizados, já que o Serpro é o upstream e tem constantemente investido esforço no desenvolvimento deles.

Vamos precisar então testar esses plugins e garantir que eles funcionam com o master do Noosfero limpo.

Vamos dar continuidade à isto na issue #144.