Software Público Brasileiro

presentes: Arthur, Melissa, Peter, Daniela, Rodrigo, Terceiro

decisões arquiteturais
-----------------------------------------------------------------------

- novo frontend será desenvolvido como um `rails engine`, totalmente
independente do frontend atual
- para iniciar o serviço com o frontend novo, usaremos uma varíavel de ambiente,
algo como
NOOSFERO_FRONTEND=frontend ./script/production start
- novo frontend será mantido na master, em paralelo ao frontend atual
- vamos precisar refatorar models e talvez helpers para servir aos dois
frontends ao mesmo tempo, de forma que não quebre o frontend antigo.
- toda refatoração tem que ser feita no master
- este trabalho vai ser feito com base no branch rails4, assumindo que ele será
a base para o noosfero 1.4 (plano)
- vamos investir um esforço inicial em estabilizar este branch
- o tema default precisa ser neutro, e precisa ser super fácil de pra
fazer personalizações básicas como
- escolher/criar um esquema de cores
- adicionar um logo
- precisamos documentar claramente quais as consequências da mudançá para o
novo frontend para que os usuários percebam a mudança como justificável:
- quais os benefícios do novo frontend
- quais os contras, e.g. quais funcionalidades/plugins não funcionam etc

riscos que estamos assumindo
-----------------------------------------------------------------------

- plugins poderão não funcionar
- novas funcionalidades poderão ser implementadas no frontend novo e não no
antigo (e vice versa)
- restante da comunidade pode não querer/poder colaborar com esse esforço
- vai levar um tempo para que esse novo frontend esteja maduro o suficiente
para substituir o frontend atual
- enquanto os dois frontends existirem em paralelo, vamos ter que dividir os
nossos esforços em função dos dois, e.g.
- não vamos poder esperar o frontend novo ficar pronto para novas
funcionalidades que precisam ser desenvolvidas "rápido".

referências
-----------------------------------------------------------------------

- http://trailblazerb.org/
nós não podemos detonar os models do noosfero porque o frontend antigo
precisa continuar funcionando, mas podemos tentar fazer um melhor projeto OO
no novo frontend apesar disso.

- http://getbootstrap.com/


encaminhamentos
-----------------------------------------------------------------------

esses foram os encaminhamentos iniciais que tiramos, com minha sugestão
de responsáveis:

- Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4
- Terceiro: empacotar as dependências para o debian
- quero alguém pra parear comigo nisso
- Terceiro: construir backend para suportar frontends alternativos via engines
- quero alguém pra parear comigo nisso
- Peter, Melissa: construir um conceito de frontend ("design")
- Terceiro: comunicar a comunidade que estamos iniciando este processo
- quero alguém pra parear comigo nisso
- talvez seja melhor esperar ter algo além de vapor (?) pra fazer isso

por favor confirmem que vocês podem/querem ficar responsáveis por estas
tarefas.

próximo encontro
-----------------------------------------------------------------------

11/08, 10h (i.e. daqui 1 semana)

--
Antonio Terceiro
http://softwarelivre.org/terceiro

>
> - Terceiro: empacotar as dependências para o debian
> - quero alguém pra parear comigo nisso

Pode contar comigo se precisar o/


Em 4 de agosto de 2015 16:08, Antonio Terceiro
escreveu:

> presentes: Arthur, Melissa, Peter, Daniela, Rodrigo, Terceiro
>
> decisões arquiteturais
> -----------------------------------------------------------------------
>
> - novo frontend será desenvolvido como um `rails engine`, totalmente
> independente do frontend atual
> - para iniciar o serviço com o frontend novo, usaremos uma varíavel de
> ambiente,
> algo como
> NOOSFERO_FRONTEND=frontend ./script/production start
> - novo frontend será mantido na master, em paralelo ao frontend atual
> - vamos precisar refatorar models e talvez helpers para servir aos dois
> frontends ao mesmo tempo, de forma que não quebre o frontend antigo.
> - toda refatoração tem que ser feita no master
> - este trabalho vai ser feito com base no branch rails4, assumindo que ele
> será
> a base para o noosfero 1.4 (plano)
> - vamos investir um esforço inicial em estabilizar este branch
> - o tema default precisa ser neutro, e precisa ser super fácil de pra
> fazer personalizações básicas como
> - escolher/criar um esquema de cores
> - adicionar um logo
> - precisamos documentar claramente quais as consequências da mudançá para o
> novo frontend para que os usuários percebam a mudança como justificável:
> - quais os benefícios do novo frontend
> - quais os contras, e.g. quais funcionalidades/plugins não funcionam etc
>
> riscos que estamos assumindo
> -----------------------------------------------------------------------
>
> - plugins poderão não funcionar
> - novas funcionalidades poderão ser implementadas no frontend novo e não no
> antigo (e vice versa)
> - restante da comunidade pode não querer/poder colaborar com esse esforço
> - vai levar um tempo para que esse novo frontend esteja maduro o suficiente
> para substituir o frontend atual
> - enquanto os dois frontends existirem em paralelo, vamos ter que dividir
> os
> nossos esforços em função dos dois, e.g.
> - não vamos poder esperar o frontend novo ficar pronto para novas
> funcionalidades que precisam ser desenvolvidas "rápido".
>
> referências
> -----------------------------------------------------------------------
>
> - http://trailblazerb.org/
> nós não podemos detonar os models do noosfero porque o frontend antigo
> precisa continuar funcionando, mas podemos tentar fazer um melhor
> projeto OO
> no novo frontend apesar disso.
>
> - http://getbootstrap.com/
>
>
> encaminhamentos
> -----------------------------------------------------------------------
>
> esses foram os encaminhamentos iniciais que tiramos, com minha sugestão
> de responsáveis:
>
> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4
> - Terceiro: empacotar as dependências para o debian
> - quero alguém pra parear comigo nisso
> - Terceiro: construir backend para suportar frontends alternativos via
> engines
> - quero alguém pra parear comigo nisso
> - Peter, Melissa: construir um conceito de frontend ("design")
> - Terceiro: comunicar a comunidade que estamos iniciando este processo
> - quero alguém pra parear comigo nisso
> - talvez seja melhor esperar ter algo além de vapor (?) pra fazer isso
>
> por favor confirmem que vocês podem/querem ficar responsáveis por estas
> tarefas.
>
> próximo encontro
> -----------------------------------------------------------------------
>
> 11/08, 10h (i.e. daqui 1 semana)
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Antonio Terceiro escreveu isso ai:

> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4

De boa.

> - Terceiro: construir backend para suportar frontends alternativos via engines
> - quero alguém pra parear comigo nisso

Se rolar, quero colar nisso tb.

--
Rodrigo Souto :: 55 71 8131-7714
Colivre - Cooperativa de Tecnologias Livres
http://www.colivre.coop.br/

On Tue, Aug 04, 2015 at 04:08:11PM -0300, Antonio Terceiro wrote:

> presentes: Arthur, Melissa, Peter, Daniela, Rodrigo, Terceiro
>
> decisões arquiteturais
> -----------------------------------------------------------------------
>
> - novo frontend será desenvolvido como um `rails engine`, totalmente
> independente do frontend atual
> - para iniciar o serviço com o frontend novo, usaremos uma varíavel de ambiente,
> algo como
> NOOSFERO_FRONTEND=frontend ./script/production start
> - novo frontend será mantido na master, em paralelo ao frontend atual
> - vamos precisar refatorar models e talvez helpers para servir aos dois
> frontends ao mesmo tempo, de forma que não quebre o frontend antigo.
> - toda refatoração tem que ser feita no master
> - este trabalho vai ser feito com base no branch rails4, assumindo que ele será
> a base para o noosfero 1.4 (plano)
> - vamos investir um esforço inicial em estabilizar este branch
> - o tema default precisa ser neutro, e precisa ser super fácil de pra
> fazer personalizações básicas como
> - escolher/criar um esquema de cores
> - adicionar um logo
> - precisamos documentar claramente quais as consequências da mudançá para o
> novo frontend para que os usuários percebam a mudança como justificável:
> - quais os benefícios do novo frontend
> - quais os contras, e.g. quais funcionalidades/plugins não funcionam etc
>
> riscos que estamos assumindo
> -----------------------------------------------------------------------
>
> - plugins poderão não funcionar
> - novas funcionalidades poderão ser implementadas no frontend novo e não no
> antigo (e vice versa)
> - restante da comunidade pode não querer/poder colaborar com esse esforço
> - vai levar um tempo para que esse novo frontend esteja maduro o suficiente
> para substituir o frontend atual
> - enquanto os dois frontends existirem em paralelo, vamos ter que dividir os
> nossos esforços em função dos dois, e.g.
> - não vamos poder esperar o frontend novo ficar pronto para novas
> funcionalidades que precisam ser desenvolvidas "rápido".
>
> referências
> -----------------------------------------------------------------------
>
> - http://trailblazerb.org/
> nós não podemos detonar os models do noosfero porque o frontend antigo
> precisa continuar funcionando, mas podemos tentar fazer um melhor projeto OO
> no novo frontend apesar disso.
>
> - http://getbootstrap.com/
>
>
> encaminhamentos
> -----------------------------------------------------------------------
>
> esses foram os encaminhamentos iniciais que tiramos, com minha sugestão
> de responsáveis:
>
> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4

Se possível gostaria de ajudar na tarefa de empacotamento.

> - Terceiro: empacotar as dependências para o debian
> - quero alguém pra parear comigo nisso
> - Terceiro: construir backend para suportar frontends alternativos via engines
> - quero alguém pra parear comigo nisso
> - Peter, Melissa: construir um conceito de frontend ("design")
> - Terceiro: comunicar a comunidade que estamos iniciando este processo
> - quero alguém pra parear comigo nisso
> - talvez seja melhor esperar ter algo além de vapor (?) pra fazer isso
>
> por favor confirmem que vocês podem/querem ficar responsáveis por estas
> tarefas.
>
> próximo encontro
> -----------------------------------------------------------------------
>
> 11/08, 10h (i.e. daqui 1 semana)
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>



> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev

Oi,

ok! Vamos assumir a tarefa do conceito de front-end.

Abraços

Melissa Wen
Em 04/08/2015 16:08, "Antonio Terceiro"

escreveu:

> presentes: Arthur, Melissa, Peter, Daniela, Rodrigo, Terceiro
>
> decisões arquiteturais
> -----------------------------------------------------------------------
>
> - novo frontend será desenvolvido como um `rails engine`, totalmente
> independente do frontend atual
> - para iniciar o serviço com o frontend novo, usaremos uma varíavel de
> ambiente,
> algo como
> NOOSFERO_FRONTEND=frontend ./script/production start
> - novo frontend será mantido na master, em paralelo ao frontend atual
> - vamos precisar refatorar models e talvez helpers para servir aos dois
> frontends ao mesmo tempo, de forma que não quebre o frontend antigo.
> - toda refatoração tem que ser feita no master
> - este trabalho vai ser feito com base no branch rails4, assumindo que ele
> será
> a base para o noosfero 1.4 (plano)
> - vamos investir um esforço inicial em estabilizar este branch
> - o tema default precisa ser neutro, e precisa ser super fácil de pra
> fazer personalizações básicas como
> - escolher/criar um esquema de cores
> - adicionar um logo
> - precisamos documentar claramente quais as consequências da mudançá para o
> novo frontend para que os usuários percebam a mudança como justificável:
> - quais os benefícios do novo frontend
> - quais os contras, e.g. quais funcionalidades/plugins não funcionam etc
>
> riscos que estamos assumindo
> -----------------------------------------------------------------------
>
> - plugins poderão não funcionar
> - novas funcionalidades poderão ser implementadas no frontend novo e não no
> antigo (e vice versa)
> - restante da comunidade pode não querer/poder colaborar com esse esforço
> - vai levar um tempo para que esse novo frontend esteja maduro o suficiente
> para substituir o frontend atual
> - enquanto os dois frontends existirem em paralelo, vamos ter que dividir
> os
> nossos esforços em função dos dois, e.g.
> - não vamos poder esperar o frontend novo ficar pronto para novas
> funcionalidades que precisam ser desenvolvidas "rápido".
>
> referências
> -----------------------------------------------------------------------
>
> - http://trailblazerb.org/
> nós não podemos detonar os models do noosfero porque o frontend antigo
> precisa continuar funcionando, mas podemos tentar fazer um melhor
> projeto OO
> no novo frontend apesar disso.
>
> - http://getbootstrap.com/
>
>
> encaminhamentos
> -----------------------------------------------------------------------
>
> esses foram os encaminhamentos iniciais que tiramos, com minha sugestão
> de responsáveis:
>
> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4
> - Terceiro: empacotar as dependências para o debian
> - quero alguém pra parear comigo nisso
> - Terceiro: construir backend para suportar frontends alternativos via
> engines
> - quero alguém pra parear comigo nisso
> - Peter, Melissa: construir um conceito de frontend ("design")
> - Terceiro: comunicar a comunidade que estamos iniciando este processo
> - quero alguém pra parear comigo nisso
> - talvez seja melhor esperar ter algo além de vapor (?) pra fazer isso
>
> por favor confirmem que vocês podem/querem ficar responsáveis por estas
> tarefas.
>
> próximo encontro
> -----------------------------------------------------------------------
>
> 11/08, 10h (i.e. daqui 1 semana)
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Estou alinhando com a resposta da Melissa.


Abraços,

Em 4 de agosto de 2015 20:01, Melissa Wen escreveu:

> Oi,
>
> ok! Vamos assumir a tarefa do conceito de front-end.
>
> Abraços
>
> Melissa Wen
> Em 04/08/2015 16:08, "Antonio Terceiro"
> escreveu:
>
>> presentes: Arthur, Melissa, Peter, Daniela, Rodrigo, Terceiro
>>
>> decisões arquiteturais
>> -----------------------------------------------------------------------
>>
>> - novo frontend será desenvolvido como um `rails engine`, totalmente
>> independente do frontend atual
>> - para iniciar o serviço com o frontend novo, usaremos uma varíavel de
>> ambiente,
>> algo como
>> NOOSFERO_FRONTEND=frontend ./script/production start
>> - novo frontend será mantido na master, em paralelo ao frontend atual
>> - vamos precisar refatorar models e talvez helpers para servir aos dois
>> frontends ao mesmo tempo, de forma que não quebre o frontend antigo.
>> - toda refatoração tem que ser feita no master
>> - este trabalho vai ser feito com base no branch rails4, assumindo que
>> ele será
>> a base para o noosfero 1.4 (plano)
>> - vamos investir um esforço inicial em estabilizar este branch
>> - o tema default precisa ser neutro, e precisa ser super fácil de pra
>> fazer personalizações básicas como
>> - escolher/criar um esquema de cores
>> - adicionar um logo
>> - precisamos documentar claramente quais as consequências da mudançá para
>> o
>> novo frontend para que os usuários percebam a mudança como justificável:
>> - quais os benefícios do novo frontend
>> - quais os contras, e.g. quais funcionalidades/plugins não funcionam etc
>>
>> riscos que estamos assumindo
>> -----------------------------------------------------------------------
>>
>> - plugins poderão não funcionar
>> - novas funcionalidades poderão ser implementadas no frontend novo e não
>> no
>> antigo (e vice versa)
>> - restante da comunidade pode não querer/poder colaborar com esse esforço
>> - vai levar um tempo para que esse novo frontend esteja maduro o
>> suficiente
>> para substituir o frontend atual
>> - enquanto os dois frontends existirem em paralelo, vamos ter que dividir
>> os
>> nossos esforços em função dos dois, e.g.
>> - não vamos poder esperar o frontend novo ficar pronto para novas
>> funcionalidades que precisam ser desenvolvidas "rápido".
>>
>> referências
>> -----------------------------------------------------------------------
>>
>> - http://trailblazerb.org/
>> nós não podemos detonar os models do noosfero porque o frontend antigo
>> precisa continuar funcionando, mas podemos tentar fazer um melhor
>> projeto OO
>> no novo frontend apesar disso.
>>
>> - http://getbootstrap.com/
>>
>>
>> encaminhamentos
>> -----------------------------------------------------------------------
>>
>> esses foram os encaminhamentos iniciais que tiramos, com minha sugestão
>> de responsáveis:
>>
>> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch rails4
>> - Terceiro: empacotar as dependências para o debian
>> - quero alguém pra parear comigo nisso
>> - Terceiro: construir backend para suportar frontends alternativos via
>> engines
>> - quero alguém pra parear comigo nisso
>> - Peter, Melissa: construir um conceito de frontend ("design")
>> - Terceiro: comunicar a comunidade que estamos iniciando este processo
>> - quero alguém pra parear comigo nisso
>> - talvez seja melhor esperar ter algo além de vapor (?) pra fazer isso
>>
>> por favor confirmem que vocês podem/querem ficar responsáveis por estas
>> tarefas.
>>
>> próximo encontro
>> -----------------------------------------------------------------------
>>
>> 11/08, 10h (i.e. daqui 1 semana)
>>
>> --
>> Antonio Terceiro
>>http://softwarelivre.org/terceiro
>>
>>
>>
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>


--

Peter Lima
61 8430 2893
www.peterlima.com.br

Oi,

On 04-08-2015 16:08, Antonio Terceiro wrote:

> - Arthur, Dani, Rodrigo: testar e ajudar a estabilizar o branch
> rails4

Confirmo!

> - Terceiro: empacotar as dependências para o debian - quero alguém
> pra parear comigo nisso - Terceiro: construir backend para suportar
> frontends alternativos via engines - quero alguém pra parear comigo
> nisso

Quero parear nisso :)

> - Peter, Melissa: construir um conceito de frontend ("design") -
> Terceiro: comunicar a comunidade que estamos iniciando este
> processo - quero alguém pra parear comigo nisso - talvez seja
> melhor esperar ter algo além de vapor (?) pra fazer isso

Acho bom esperar ter mais alguma coisa antes disso.

Abraços,
Daniela


--

Daniela Soares Feitosa

Colivre - Cooperativa de Tecnologias Livres

http://www.Colivre.coop.br/
55 71 3331-2299/ 55 71 8165-1685

On Tue, 4 Aug 2015 16:08:11 -0300
Antonio Terceiro wrote:

> - Terceiro: empacotar as dependências para o debian
> - quero alguém pra parear comigo nisso

Já tem bastante gente querendo ajudar nessa task, mas se precisar to dentro :)

Abraços,
--

Lucas Kanashiro

On Tue, Aug 04, 2015 at 04:08:11PM -0300, Antonio Terceiro wrote:
> próximo encontro
> -----------------------------------------------------------------------
>
> 11/08, 10h (i.e. daqui 1 semana)

lembrete. se agendem aí para amanhã.

--

Antonio Terceiro
http://softwarelivre.org/terceiro

Antonio, boa tarde.

Trabalho na prefeitura de São Jose em Santa Catarina. O SIPREV não esta
mais disponivel no site? Como faço para acessar.

Abraços

Cláudio



Em 10 de agosto de 2015 11:19, Antonio Terceiro

escreveu:

> On Tue, Aug 04, 2015 at 04:08:11PM -0300, Antonio Terceiro wrote:
> > próximo encontro
> > -----------------------------------------------------------------------
> >
> > 11/08, 10h (i.e. daqui 1 semana)
>
> lembrete. se agendem aí para amanhã.
>
> --
> Antonio Terceiro
>http://softwarelivre.org/terceiro
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>https://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>


--
-------

Cláudio Rodrigues