> Nos últimos dias tenho feito um exercício mental para chegar a uma
> conclusão sobre o que faria com que eu, enquanto desenvolvedor de
> software livre, usasse o softwarepublico para os meus projetos. Esta
> mensagem tem o objetivo de sumarizar as minhas idéias, após uma
> discussão com uma parte da equipe Noosfero do LAPPIS hoje pela manhã.
>
> Este relato está dividido em 2 partes: um plano conceitual, que é
> basicamente a resposta para a pergunta original, e um plano técnico, que
> descreve as mudanças que na minha opinião vamos precisar fazer na
> implementação atual no Noosfero.
>
> # Plano conceitual
>
> Eu usaria o softwarepublico para os meus projetos se:
>
> - ele me proporcionar a conveniência e as features do GitHub
>
> - ele permitir que eu simplesmente use a plataforma, sem muita exigência
> de preenchimento de formulários e fornecimento de informações (i.e.
> pouca burocracia)
>
> - pra mim está OK se eu precisar passar por um processo "mais
> chatinho" pra que o meu projeto possa ter os benefícios
> (visibilidade, preferência na contratação por órgãos públicos etc)
> de um projeto certificado como software público, desde que isso seja
> opcional, e possa ser feito depois que a plataforma já esteja me
> ajudando com o desenvolvimento em si.
>
> Além disso, na minha opinião, algumas features serão necessárias pra que
> a gente consiga formar uma massa crítica. Abaixo uma lista inicial em
> que eu pensei, que está mais ou menos em ordem de prioridade:
>
> - integração entre as ferramantas, para que o setup de um projeto seja o
> mais simples e direto possível. Basicamente eu como usuário gostaria
> de poder ignorar o fato de que o softwarepublico consiste da junção do
> colab, gitlab e noosfero.
>
> - quando uma comunidade for criada no noosfero, o grupo correspondente
> no gitlab deve ser criado automaticamente.
> - a gente provavelmente vai querer desligar a criação de grupos
> diretamente pelo gitlab.
>
> - quando uma comunidade for criada no noosfero, uma lista de discussão
> correspondente deve ser criada automaticamente.
>
> - o admin da comunidade deveria poder criar outras listas depois,
> restritas a nomes que usem o nome da comunidade como prefixo.
>
> - quando um cadastro de software for criado numa comunidade, criar
> automaticamente um repositório no gitlab (se não já existir).
>
> - quando um repositório no gitlab for criado, criar automaticamente um
> cadastro de software na comunidade correspondente.
>
> - mirroring de repositório. Fundamental para projetos que já têm o seu
> repositório em outro lugar, mas que querem estar também no
> softwarepublico.
>
> - hospedagem de sites estáticos. Essa é uma feature *muito* usada do
> github que eu considero bastante útil.
>
> - integração contínua, integrada ao gitlab.
>
> - build service, para geração automática de pacotes.
>
> Eu _acho_ que até o final do ano a gente consegue fazer as primeiras
> duas (integração e mirroring de repositório), que são essenciais. As
> podem vir "depois".
>
> # Plano técnico
>
> Sobre o projeto conceitual das informações armazenadas e sua
> implementação no plugin Noosfero em desenvolvimento:
>
> - ao invés de um software possuir uma comunidade (relação 1 pra 1), uma
> comunidade pode um ou mais de um software (i.e. relação 1 comunidade
> para N softwares)
>
> - isso reflete o modelo que se tornou um padrão de fato na comunidade
> de software livre: GitHub e Gitlab utilizam esta lógica.
>
> - ainda assim, reconhecemos que o caso mais simples vai ser uma
> comunidade possuir apenas um software. Para esse caso, podemos
> manter a opção "criar software" no painel de controle do usuário,
> que funcionará como funciona hoje:
>
> - cria comunidade
> - cria uma instância de SoftwareInfo para aquela comunidade
>
> - haverá 1 template que poderá ser utilizada pelas comunidades 'de
> software', que conterá a "página padrão" de software que estamos
> discutindo.
>
> - há de se notar que, como qualquer outro perfil no noosfero, o admin
> da comundidade do software poderá depois modificar praticamente
> tudo, então a nossa página padrão é na prática uma sugestão, que
> pode ou não ser seguida à risca pelas comunidades.
>
> - esse template provavelmente demandará a implementação de alguns
> novos tipos de blocos no Noosfero, como por exemplo um bloco que
> apresenta informações do projeto.
>
> - instituição passa a ser um tipo de organização, ou de comunidade (ou
> seja vamos simplificar o design e reusar o máximo do que o noosfero já
> tem pra evitar código desnecessário que a gente precise manter
> sozinho)
>
> - a criação de instituições pode ser realizada da mesma forma que se
> cria comunidades, através do painel de controle, "meus grupos".
>
> - associação da uma pessoa a uma instituição deve funcionar da mesma
> forma como funciona para outros tipos de organização no Noosfero: o
> usuário visita o perfil da instituição e clica em "Entrar" (podemos
> modificar a terminologia para por exemplo "Faço parte desta
> instituição" ou algo que o valha).
>
> Isso permite que por exemplo uma instituição possa ter um
> administrador que vai aprovar a "entrada" de usuários como membros
> daquela instituição.
>
> - vamos precisar delimitar o escopo e a viabilidade das funcionalidades
> que eu elenquei na parte conceitual.
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>
Antonio Terceiro
Arthur Esposte