Software Público Brasileiro

Gente,

Eu e o Sergio tivemos uma conversa agora pra definir quais dados do
noosfero a gente quer indexar pra aparecerem na busca centralizada do
colab. Abaixo tem um primeiro rascunho; fiquem à vontade pra
complementar.

itens buscáveis (não-contribuições):
perfil (pessoa/comunidade)
identifier
name
description
dados de software, quando houver
campos de endereço (?)
ver outros campos interessantes
conteúdo (TextArticle)
titulo
corpo (pode ser HTML ou textile)
outros conteúdos (outras subclasses de Article)
contribuições
basicamente os itens que saem no feed de atividades ("mural")

a idéia é que a gente exporte isso num formato esperto que o colab possa
importar direto (JSON, provavelmente). Alguns campos são obrigatórios
para todos os itens, como um identificador e uma url. Sergio, pode
elaborar?

A gente precisa pensar numa forma de conseguir fornecer dados de forma
incremental, ou seja, o plugin de noosfero do colab guardaria o
timestamp da última importação de dados e passaria pro noosfero, que
então retornaria só os itens mais recentes do que aquele timestamp.

Vocês acham que a gente consegue começar a brincar com isso ainda nessa
sprint?

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

On Mon, Feb 02, 2015 at 12:08:22PM -0200, Antonio Terceiro wrote:

> a idéia é que a gente exporte isso num formato esperto que o colab possa
> importar direto (JSON, provavelmente). Alguns campos são obrigatórios
> para todos os itens, como um identificador e uma url. Sergio, pode
> elaborar?

tag title description url type username date
type eh o que usamos pra colocar o icone
na verdade definimos do nosso lado
terceiro: ^^
terceiro: o id pode ser importante dependendo da estrategia de importacao
terceiro: mas normalmente a data basta
terceiro: o id eh util pra garantirmos que nao vamos importar nada duplicado

--

Antonio Terceiro
http://softwarelivre.org/terceiro

Pessoal,

estamos andando com esse plugin de integração de dados com o Colab

Ficamos em dúvida se também iremos exportar as informações sobre as
relações entre perfis. Por exemplo:
- Nas informações de comunidade, trazer a lista de membros e admins,
sub-comunidades.
- Nas informações de pessoa, trazer a lista de amigos, comunidades e
softwares que ele participa.
- Já temos algo sobre instituição no plugin do SPB. Inserimos suas
informações também ou pensamos nisso no futuro quando for melhor utilizado?


att,
Arthur

Em 2 de fevereiro de 2015 12:21, Antonio Terceiro <
terceiro@softwarelivre.org> escreveu:

> On Mon, Feb 02, 2015 at 12:08:22PM -0200, Antonio Terceiro wrote:
> > a idéia é que a gente exporte isso num formato esperto que o colab possa
> > importar direto (JSON, provavelmente). Alguns campos são obrigatórios
> > para todos os itens, como um identificador e uma url. Sergio, pode
> > elaborar?
>
> tag title description url type username date
> type eh o que usamos pra colocar o icone
> na verdade definimos do nosso lado
> terceiro: ^^
> terceiro: o id pode ser importante dependendo da estrategia de
> importacao
> terceiro: mas normalmente a data basta
> terceiro: o id eh util pra garantirmos que nao vamos importar
> nada duplicado
>
> --
> 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
>
>

Terceiro e Sérgio,

Para um software também precisaremos da Finalidade e da Categoria para a busca. Também precisaremos da Data de cadastro e Quantidade de downloads para exibição dos resultados.

Rodrigo Maia
www.rodmaia.net

> Em 02/02/2015, à(s) 9:08AM, Antonio Terceiro escreveu:
>
> Gente,
>
> Eu e o Sergio tivemos uma conversa agora pra definir quais dados do
> noosfero a gente quer indexar pra aparecerem na busca centralizada do
> colab. Abaixo tem um primeiro rascunho; fiquem à vontade pra
> complementar.
>
> itens buscáveis (não-contribuições):
> perfil (pessoa/comunidade)
> identifier
> name
> description
> dados de software, quando houver
> campos de endereço (?)
> ver outros campos interessantes
> conteúdo (TextArticle)
> titulo
> corpo (pode ser HTML ou textile)
> outros conteúdos (outras subclasses de Article)
> contribuições
> basicamente os itens que saem no feed de atividades ("mural")
>
> a idéia é que a gente exporte isso num formato esperto que o colab possa
> importar direto (JSON, provavelmente). Alguns campos são obrigatórios
> para todos os itens, como um identificador e uma url. Sergio, pode
> elaborar?
>
> A gente precisa pensar numa forma de conseguir fornecer dados de forma
> incremental, ou seja, o plugin de noosfero do colab guardaria o
> timestamp da última importação de dados e passaria pro noosfero, que
> então retornaria só os itens mais recentes do que aquele timestamp.
>
> Vocês acham que a gente consegue começar a brincar com isso ainda nessa
> sprint?
>
> --
> 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

*Oi Rodrigo,*

A ideia é que coloquemos uma finalidade bem completa ou teremos que
pesquisar também no campo "requisitos Mínimos"?
Estou pensando aqui no usuário tentando buscar a palavra "java", por
exemplo.

Acho que podemos tentar marcar uma conversa para fazermos um mapeamento
desses campos mas acho que estamos indo no caminho certo. Já estamos
pensando no assunto por aqui também.



Marisa Souza
Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 3 de fevereiro de 2015 19:46, Rodrigo Maia escreveu:

> Terceiro e Sérgio,
>
> Para um software também precisaremos da Finalidade e da Categoria para a
> busca. Também precisaremos da Data de cadastro e Quantidade de downloads
> para exibição dos resultados.
>
> Rodrigo Maia
> www.rodmaia.net
>
> Em 02/02/2015, à(s) 9:08AM, Antonio Terceiro
> escreveu:
>
> Gente,
>
> Eu e o Sergio tivemos uma conversa agora pra definir quais dados do
> noosfero a gente quer indexar pra aparecerem na busca centralizada do
> colab. Abaixo tem um primeiro rascunho; fiquem à vontade pra
> complementar.
>
> itens buscáveis (não-contribuições):
> perfil (pessoa/comunidade)
> identifier
> name
> description
> dados de software, quando houver
> campos de endereço (?)
> ver outros campos interessantes
> conteúdo (TextArticle)
> titulo
> corpo (pode ser HTML ou textile)
> outros conteúdos (outras subclasses de Article)
> contribuições
> basicamente os itens que saem no feed de atividades ("mural")
>
> a idéia é que a gente exporte isso num formato esperto que o colab possa
> importar direto (JSON, provavelmente). Alguns campos são obrigatórios
> para todos os itens, como um identificador e uma url. Sergio, pode
> elaborar?
>
> A gente precisa pensar numa forma de conseguir fornecer dados de forma
> incremental, ou seja, o plugin de noosfero do colab guardaria o
> timestamp da última importação de dados e passaria pro noosfero, que
> então retornaria só os itens mais recentes do que aquele timestamp.
>
> Vocês acham que a gente consegue começar a brincar com isso ainda nessa
> sprint?
>
> --
> 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
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Oi Marisa,

A finalidade vai continuar aquele texto curto que temos hoje. Já a descrição pode ser mais longa e mais detalhada.
Estamos analisando do nosso lado a possibilidade de transformar a descrição em um campo no cadastro, ao invés de deixar como um artigo.

Preciso verificar com o pessoal, mas creio que em breve teremos uma posição mais concreta sobre isso e aí poderemos discutir com vocês.

Obrigado,

Rodrigo Maia

Designer de Experiência do Usuário (UX)

www.rodmaia.net

> Em 04/02/2015, à(s) 9:53AM, Marisa Souza escreveu:
>
> Oi Rodrigo,
>
> A ideia é que coloquemos uma finalidade bem completa ou teremos que pesquisar também no campo "requisitos Mínimos"?
> Estou pensando aqui no usuário tentando buscar a palavra "java", por exemplo.
>
> Acho que podemos tentar marcar uma conversa para fazermos um mapeamento desses campos mas acho que estamos indo no caminho certo. Já estamos pensando no assunto por aqui também.
>
>
>
> Marisa Souza
> Analista em Tecnologia da Informação
> Coordenação Geral de Sistemas de Informação - DGSI/MPOG
>
> Em 3 de fevereiro de 2015 19:46, Rodrigo Maia > escreveu:
> Terceiro e Sérgio,
>
> Para um software também precisaremos da Finalidade e da Categoria para a busca. Também precisaremos da Data de cadastro e Quantidade de downloads para exibição dos resultados.
>
> Rodrigo Maia
> www.rodmaia.net
>> Em 02/02/2015, à(s) 9:08AM, Antonio Terceiro > escreveu:
>>
>> Gente,
>>
>> Eu e o Sergio tivemos uma conversa agora pra definir quais dados do
>> noosfero a gente quer indexar pra aparecerem na busca centralizada do
>> colab. Abaixo tem um primeiro rascunho; fiquem à vontade pra
>> complementar.
>>
>> itens buscáveis (não-contribuições):
>> perfil (pessoa/comunidade)
>> identifier
>> name
>> description
>> dados de software, quando houver
>> campos de endereço (?)
>> ver outros campos interessantes
>> conteúdo (TextArticle)
>> titulo
>> corpo (pode ser HTML ou textile)
>> outros conteúdos (outras subclasses de Article)
>> contribuições
>> basicamente os itens que saem no feed de atividades ("mural")
>>
>> a idéia é que a gente exporte isso num formato esperto que o colab possa
>> importar direto (JSON, provavelmente). Alguns campos são obrigatórios
>> para todos os itens, como um identificador e uma url. Sergio, pode
>> elaborar?
>>
>> A gente precisa pensar numa forma de conseguir fornecer dados de forma
>> incremental, ou seja, o plugin de noosfero do colab guardaria o
>> timestamp da última importação de dados e passaria pro noosfero, que
>> então retornaria só os itens mais recentes do que aquele timestamp.
>>
>> Vocês acham que a gente consegue começar a brincar com isso ainda nessa
>> sprint?
>>
>> --
>> 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
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Em 5 de fevereiro de 2015 11:45, Rodrigo Maia escreveu:

> Oi Marisa,
>
> A *finalidade* vai continuar aquele texto curto que temos hoje. Já a
> *descrição* pode ser mais longa e mais detalhada.
> Estamos analisando do nosso lado a possibilidade de transformar a
> descrição em um campo no cadastro, ao invés de deixar como um artigo.
>
> Preciso verificar com o pessoal, mas creio que em breve teremos uma
> posição mais concreta sobre isso e aí poderemos discutir com vocês.
>

Arthur/Gabi,

Está em nosso backlog a ideia de termos um bloco que mostra o campo
"descrição" da comunidade?

att,
--

Paulo Meirelles
FGA-UnB (http://fga.unb.br)
CCSL-IME/USP (http://ccsl.ime.usp.br)

É no desenvolvimento desse bloco que venho trabalhando com o Dylan nessa
primeira semana da sprint,

provavelmente semana que vem farei o merge request dele para o core.

Att,
David Carlos.
On 05-02-2015 19:10, Paulo Meirelles wrote:

> Em 5 de fevereiro de 2015 11:45, Rodrigo Maia >> escreveu:
>
> Oi Marisa,
>
> A /finalidade/ vai continuar aquele texto curto que temos hoje. Já
> a /descrição/ pode ser mais longa e mais detalhada.
> Estamos analisando do nosso lado a possibilidade de transformar a
> descrição em um campo no cadastro, ao invés de deixar como um artigo.
>
> Preciso verificar com o pessoal, mas creio que em breve teremos
> uma posição mais concreta sobre isso e aí poderemos discutir com
> vocês.
>
>
> Arthur/Gabi,
>
> Está em nosso backlog a ideia de termos um bloco que mostra o campo
> "descrição" da comunidade?
>
> att,
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev

Só identificamos um pequeno problema técnico quando ao campo descrição...
ele é um settings_item =/. Isso vai gerar problemas para a busca.

Mas vamos inestigar melhor!

att
Arthur

Em 5 de fevereiro de 2015 20:01, david

escreveu:

> É no desenvolvimento desse bloco que venho trabalhando com o Dylan nessa
> primeira semana da sprint,
>
> provavelmente semana que vem farei o merge request dele para o core.
>
> Att,
> David Carlos.
>
> On 05-02-2015 19:10, Paulo Meirelles wrote:
>
> Em 5 de fevereiro de 2015 11:45, Rodrigo Maia
> escreveu:
>
>> Oi Marisa,
>>
>> A *finalidade* vai continuar aquele texto curto que temos hoje. Já a
>> *descrição* pode ser mais longa e mais detalhada.
>> Estamos analisando do nosso lado a possibilidade de transformar a
>> descrição em um campo no cadastro, ao invés de deixar como um artigo.
>>
>> Preciso verificar com o pessoal, mas creio que em breve teremos uma
>> posição mais concreta sobre isso e aí poderemos discutir com vocês.
>>
>
> Arthur/Gabi,
>
> Está em nosso backlog a ideia de termos um bloco que mostra o campo
> "descrição" da comunidade?
>
> att,
> --
> Paulo Meirelles
> FGA-UnB (http://fga.unb.br)
> CCSL-IME/USP (http://ccsl.ime.usp.br)
>
>
> _______________________________________________
> spb-dev mailing listspb-dev@listas.softwarepublico.gov.brhttp://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>
>
> _______________________________________________
> spb-dev mailing list
> spb-dev@listas.softwarepublico.gov.br
>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>
>

Tranquilo Rodrigo. Ficamos no aguardo então.
Obrigada.

Marisa Souza
Analista em Tecnologia da Informação
Coordenação Geral de Sistemas de Informação - DGSI/MPOG

Em 5 de fevereiro de 2015 11:45, Rodrigo Maia escreveu:

> Oi Marisa,
>
> A *finalidade* vai continuar aquele texto curto que temos hoje. Já a
> *descrição* pode ser mais longa e mais detalhada.
> Estamos analisando do nosso lado a possibilidade de transformar a
> descrição em um campo no cadastro, ao invés de deixar como um artigo.
>
> Preciso verificar com o pessoal, mas creio que em breve teremos uma
> posição mais concreta sobre isso e aí poderemos discutir com vocês.
>
> Obrigado,
>
> Rodrigo Maia
> Designer de Experiência do Usuário (UX)
> www.rodmaia.net
>
> Em 04/02/2015, à(s) 9:53AM, Marisa Souza escreveu:
>
> *Oi Rodrigo,*
>
> A ideia é que coloquemos uma finalidade bem completa ou teremos que
> pesquisar também no campo "requisitos Mínimos"?
> Estou pensando aqui no usuário tentando buscar a palavra "java", por
> exemplo.
>
> Acho que podemos tentar marcar uma conversa para fazermos um mapeamento
> desses campos mas acho que estamos indo no caminho certo. Já estamos
> pensando no assunto por aqui também.
>
>
>
> Marisa Souza
> Analista em Tecnologia da Informação
> Coordenação Geral de Sistemas de Informação - DGSI/MPOG
>
> Em 3 de fevereiro de 2015 19:46, Rodrigo Maia
> escreveu:
>
>> Terceiro e Sérgio,
>>
>> Para um software também precisaremos da Finalidade e da Categoria para a
>> busca. Também precisaremos da Data de cadastro e Quantidade de downloads
>> para exibição dos resultados.
>>
>> Rodrigo Maia
>> www.rodmaia.net
>>
>> Em 02/02/2015, à(s) 9:08AM, Antonio Terceiro
>> escreveu:
>>
>> Gente,
>>
>> Eu e o Sergio tivemos uma conversa agora pra definir quais dados do
>> noosfero a gente quer indexar pra aparecerem na busca centralizada do
>> colab. Abaixo tem um primeiro rascunho; fiquem à vontade pra
>> complementar.
>>
>> itens buscáveis (não-contribuições):
>> perfil (pessoa/comunidade)
>> identifier
>> name
>> description
>> dados de software, quando houver
>> campos de endereço (?)
>> ver outros campos interessantes
>> conteúdo (TextArticle)
>> titulo
>> corpo (pode ser HTML ou textile)
>> outros conteúdos (outras subclasses de Article)
>> contribuições
>> basicamente os itens que saem no feed de atividades ("mural")
>>
>> a idéia é que a gente exporte isso num formato esperto que o colab possa
>> importar direto (JSON, provavelmente). Alguns campos são obrigatórios
>> para todos os itens, como um identificador e uma url. Sergio, pode
>> elaborar?
>>
>> A gente precisa pensar numa forma de conseguir fornecer dados de forma
>> incremental, ou seja, o plugin de noosfero do colab guardaria o
>> timestamp da última importação de dados e passaria pro noosfero, que
>> então retornaria só os itens mais recentes do que aquele timestamp.
>>
>> Vocês acham que a gente consegue começar a brincar com isso ainda nessa
>> sprint?
>>
>> --
>> 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
>>
>>
>>
>> _______________________________________________
>> spb-dev mailing list
>> spb-dev@listas.softwarepublico.gov.br
>>http://listas.softwarepublico.gov.br/mailman/cgi-bin/listinfo/spb-dev
>>
>>
>
>