Re: [Talk-br] Lacuna no mapa - SC

[Paulo Carvalho]

A coisa é muito simples e funciona.  Darei dois exemplos de sucesso já
comprovado: software open-source e publicações científicas.

Muita gente acha que software de código aberto é inseguro, mas é justamente
o oposto.  Software livre é mais seguro do que as caixas pretas da
Microsoft, Google, Apple, IBM, etc. justamente porque o processo é
transparente.  Agora o que em última análise torna o open source seguro é
que as alterações propostas só são integradas depois que outros membros da
comunidade aprovam.  Esse processo chama-se *merge request*.  Quem trabalha
no projeto OSM/Carto lá no GitHub já conhece, pois nada passa para o estilo
de renderização após um escrutínio pelos demais membros da comunidade.

Publicações científicas seguem basicamente o mesmo processo.  Um artigo
científico só é publicado após outros membros fazerem a revisão e
aprovarem.  Esse processo chama-se *peer review.*

Ambos os processos são pautados no princípio do terceiro confiável.  O OSM
não aplica esse princípio, ou seja assume que uma das partes (no caso os
usuários) é confiável, e o resultado são as frustrações e as consequentes
perdas de tempo consertando que vemos com frequência.  Conclusão: o modelo
de colaboração do OSM é ineficiente.  A solução para essa ineficiência está
aí.  Não fazem porque não querem.

Os mapas do OSM existem em forma de XML, o que seria perfeito de se
sujeitar a um sistema de versionamento moderno como o Git e o Mercurial.

O ser humano é falho, seja por má intenção ou por descuido.  O peer review
e o merge request são mecanismos criados para justamente impedir tais
falhas de contaminem os respectivos produtos de forma que o reparo seja
muito custoso ou que traga consequências ruins.


Em 24 de dezembro de 2015 14:46, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> Paulo, eu ficaria muito grato se você explanasse sobre isso. Muito
> provavelmente eu não discordaria de você, ao menos no essencial. Na
> verdade, eu esforçar-me-ia para nada acrescentar. A razão: muito
> provavelmente as suas seriam palavras afins de algo que eu já disse. Mas eu
> quando eu disse (na intenção de construir), fiquei aparentemente sozinho.
>
> Alexandre Magno
>
> Em 24 de dezembro de 2015 10:02, Paulo Carvalho <
> paulo.r.m.carva...@gmail.com> escreveu:
>
>> A fragilidade do modelo de colaboração é uma das razões pelas quais
>> reduzi minha participação no OSM.  Também é a razão pela qual muitos
>> potenciais usuários do mapa não usam pela facilidade com que se quebra o
>> mapa, seja por má-fé ou negligência.  O modelo usado em software de código
>> aberto é deveras mais robusto.
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Estamos vivenciando uma experiência meritocrática?

[Alexandre Magno Brito de Medeiros]

José Carlos,

A computação de karma que você sugere já pressupõe poder nos definidores
das regras. Exigiria politização e legislação.

O que eu estou vendo é que seria melhor ter como "curtir" diversos tipos de
colaboração (internacionalmente):

   - Mensagens nos históricos das listas
   - Mensagens nos fóruns
   - Edições no wiki
   - Edições no mapa
   - *Commits*
   - *Pull requests*
   - etc.

Esperar que pessoas "curtam" outras (ou ao menos seus resultados), na minha
opinião, será a forma mais descentralizada de reconhecer o mérito. É
votação implícita, para o projeto global começar a constituir sua
democracia batedora de martelo.

Alexandre Magno.

Em 25 de dezembro de 2015 22:30, Jose Carlos Medeiros <
jcnascime...@gmail.com> escreveu:

> Boa noite,
>
> Eu acho o sistema de "Karma" utilizado pelo PHP e Debian muito bom. O nome
> bonito para a meritocracia nos projetos.
> No PHP existe um grupo de aprovadores de novas funcionalidades da
> linguagem, este grupo é composto de pessoas com X de karma. O karma é
> medido em commits e acho que alguns itens como participação em forum,
> traduções etc...
> Mas acho que isso tem que ser alinhado com o OSM, pois seria um grupo aqui
> que poderia fazer commit da base do Brasil todo, e não mais qualquer
> usuário, seguindo a ideia do Gerald. Será que eles aceitam isso?
> Outro problema são os sistemas envolvidos, tudo isso tem que ser meio
> automático, como contar os commits elegíveis a karma positivo, senão um
> usuário fica alterando a mesma coisa e vai ganhando karma, por outro lado,
> fiscalizar manualmente fica impossível.
>
> Att
> José Carlos
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Estamos vivenciando uma experiência meritocrática?

[Jose Carlos Medeiros]

Boa noite,

Eu acho o sistema de "Karma" utilizado pelo PHP e Debian muito bom. O nome
bonito para a meritocracia nos projetos.
No PHP existe um grupo de aprovadores de novas funcionalidades da
linguagem, este grupo é composto de pessoas com X de karma. O karma é
medido em commits e acho que alguns itens como participação em forum,
traduções etc...
Mas acho que isso tem que ser alinhado com o OSM, pois seria um grupo aqui
que poderia fazer commit da base do Brasil todo, e não mais qualquer
usuário, seguindo a ideia do Gerald. Será que eles aceitam isso?
Outro problema são os sistemas envolvidos, tudo isso tem que ser meio
automático, como contar os commits elegíveis a karma positivo, senão um
usuário fica alterando a mesma coisa e vai ganhando karma, por outro lado,
fiscalizar manualmente fica impossível.


Att
José Carlos

Em 25 de dezembro de 2015 21:22, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> *Era:"Re: [Talk-br] Lacuna no mapa - SC"*
>
> Gerald,
>
> Entendo que o Paulo nos pediu para olharmos com analogia o processo de *merge
> request* que dar-se em processos de desenvolvimento de software.
> Obviamente, não devemos esperar que os muitos mapeadores OpenStreetMap se
> adaptem a algo que tenha aparência com git + XML. Se não me engano, já
> existe gente lá fora, em projeto GSoC, trabalhando sistema web de monitoria
> e fiscalização para o OSM.
>
> Então vem a sua questão (em minhas palavras, permita-me):
>
> — Mas quem teria o poder nas mãos, para operar tais sistemas?
>
> Ingenuamente, até poucos dias atrás, *eu só pensava na necessidade de
> politização e legislação* dentro do projeto. Mas o Peter Krauss tem me
> mostrado que um sistema com princípios de qualificação pessoal "como"
> aqueles do StackOverflow pode ser de grande ajuda, para instituirmos (sem
> tirania) construção ou reconhecimento de autoridades na comunidade.
>
> Referência: Estamos vivenciando uma experiência meritocrática?
> 
>
> Com "princípios sociais" de "qualificação pessoal" como aqueles, as
> pessoas (cada um de nós) poderiam conquistar as autoridades necessárias
> para exercer os mais variados poderes dentro OSM.
>
> Na minha opinião, para início, o correto seria integrar uma *"máquina de
> computação de reputação*" a toda ferramenta de colaboração do projeto:
>
>- site principal (base de dados)
>- wiki
>- fórum
>- históricos das listas
>- etc.
>
> Toda colaboração teria de virtualmente servir para computar a reputação de
> alguém., baseando-se em critérios sociais do tipo: "gostei", "eu sigo",
> "isso está correto ou funcionou pra mim".
>
> Quem entendeu? Parece ser a única saída... para não impor nada.
>
> "O povo OSM decidiria quem nele teria poder, e quais poderes."
>
> Alexandre Magno
>
> Em 25 de dezembro de 2015 19:14, Gerald Weber 
> escreveu:
>
>> Oi Paulo,
>>
>> interessantes as suas colocações, mas tenho algumas observações a fazer
>>
>> 2015-12-25 14:37 GMT-02:00 Paulo Carvalho :
>>
>>> A coisa é muito simples e funciona.  Darei dois exemplos de sucesso já
>>> comprovado: software open-source e publicações científicas.
>>>
>>
>> Nenhum dos dois modelos involve leigos, mas pessoas altamente
>> especializadas. Ninguém contribui num projeto de software sem ao menos um
>> domínio básico das linguagens envolvidas. Ninguém publica em revistas
>> científicas sem muitos anos de especialização. Outro ponto é que o número
>> de pessoas envolvido num projeto de software é bastante restrito, assim
>> como o número de pessoas que estão envolvidas numa publicação caberiam numa
>> sala (exceto nas colaborações de física de partículas, exemplo LHC).
>>
>> Já o modelo do OSM envolve uma variedade de pessoas muito grandes, desde
>> especialistas em GIS até leigos totais em cartografia (como eu por
>> exemplo). Também o número de pessoas envolvido aqui é bem maior do que em
>> qualquer projeto de software típico.
>>
>>
>>> Ambos os processos são pautados no princípio do terceiro confiável.  O
>>> OSM não aplica esse princípio, ou seja assume que uma das partes (no caso
>>> os usuários) é confiável, e o resultado são as frustrações e as
>>> consequentes perdas de tempo consertando que vemos com frequência.
>>> Conclusão: o modelo de colaboração do OSM é ineficiente.  A solução para
>>> essa ineficiência está aí.  Não fazem porque não querem.
>>>
>>
>> Não sei como se poderia operacionalizar um modelo de validação eficiente
>> no OSM diante de um público tão heterogêneo. Qualquer que seja a solução
>> ela envolve gente para operacionalizar isto. A lógica dominante no OSM é
>> que tendo uma massa grande de mapeadores qualquer problema seja rapidamente
>> solucionado. O nosso problema aqui na América do Sul é que não temos essa
>> massa de gente e por isto a lógica que funciona na Europa não funciona para
>> nós.
>>
>>
>>>
>>> 

Re: [Talk-br] Estamos vivenciando uma experiência meritocrática?

[Alexandre Magno Brito de Medeiros]

Se o sistema que eu imagino estivesse no ar...

Digamos que eu, Alexandre Magno, como usuário de openstreetmap.org, com as
cédulas de votos (curtir) únicos que tenho, quisesse empoderar naoliv:

Eu entraria nesse sistema, com a minha conta de openstreetmap.org, e sairia
curtindo contribuições de naoliv. Só teria direito de curtir ou descurtir
cada uma uma vez; ou seja, um único voto para cada contribuição.
Contribuições feitas em fórum, wiki, e no próprio mapa, por exemplo. Para
prevenir abusos, todos os usuários do sistema poderiam estar a par de cada
curtida minha. Quem quisesse, poderia "descurtir" aquela contribuição de
naoliv, na tentativa de anular minha curtida.

Isso seria *um sistema de votação sempre aberto* e com escassez, que
tenderia a realmente destacar os que realmente merecem. Pois os que tem
problemas (ainda que apenas em âmbito de relacionamento interpessoal),
teriam curtidas anuladas com descurtidas.

Eu acredito que um sistema desses muito tenderia a ser justo!

Alexandre Magno

Em 25 de dezembro de 2015 23:09, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> José Carlos,
>
> A computação de karma que você sugere já pressupõe poder nos definidores
> das regras. Exigiria politização e legislação.
>
> O que eu estou vendo é que seria melhor ter como "curtir" diversos tipos
> de colaboração (internacionalmente):
>
>- Mensagens nos históricos das listas
>- Mensagens nos fóruns
>- Edições no wiki
>- Edições no mapa
>- *Commits*
>- *Pull requests*
>- etc.
>
> Esperar que pessoas "curtam" outras (ou ao menos seus resultados), na
> minha opinião, será a forma mais descentralizada de reconhecer o mérito. É
> votação implícita, para o projeto global começar a constituir sua
> democracia batedora de martelo.
>
> Alexandre Magno.
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

[Talk-br] Estamos vivenciando uma experiência meritocrática?

[Alexandre Magno Brito de Medeiros]

*Era:"Re: [Talk-br] Lacuna no mapa - SC"*

Gerald,

Entendo que o Paulo nos pediu para olharmos com analogia o processo de *merge
request* que dar-se em processos de desenvolvimento de software.
Obviamente, não devemos esperar que os muitos mapeadores OpenStreetMap se
adaptem a algo que tenha aparência com git + XML. Se não me engano, já
existe gente lá fora, em projeto GSoC, trabalhando sistema web de monitoria
e fiscalização para o OSM.

Então vem a sua questão (em minhas palavras, permita-me):

— Mas quem teria o poder nas mãos, para operar tais sistemas?

Ingenuamente, até poucos dias atrás, *eu só pensava na necessidade de
politização e legislação* dentro do projeto. Mas o Peter Krauss tem me
mostrado que um sistema com princípios de qualificação pessoal "como"
aqueles do StackOverflow pode ser de grande ajuda, para instituirmos (sem
tirania) construção ou reconhecimento de autoridades na comunidade.

Referência: Estamos vivenciando uma experiência meritocrática?


Com "princípios sociais" de "qualificação pessoal" como aqueles, as pessoas
(cada um de nós) poderiam conquistar as autoridades necessárias para
exercer os mais variados poderes dentro OSM.

Na minha opinião, para início, o correto seria integrar uma *"máquina de
computação de reputação*" a toda ferramenta de colaboração do projeto:

   - site principal (base de dados)
   - wiki
   - fórum
   - históricos das listas
   - etc.

Toda colaboração teria de virtualmente servir para computar a reputação de
alguém., baseando-se em critérios sociais do tipo: "gostei", "eu sigo",
"isso está correto ou funcionou pra mim".

Quem entendeu? Parece ser a única saída... para não impor nada.

"O povo OSM decidiria quem nele teria poder, e quais poderes."

Alexandre Magno

Em 25 de dezembro de 2015 19:14, Gerald Weber  escreveu:

> Oi Paulo,
>
> interessantes as suas colocações, mas tenho algumas observações a fazer
>
> 2015-12-25 14:37 GMT-02:00 Paulo Carvalho :
>
>> A coisa é muito simples e funciona.  Darei dois exemplos de sucesso já
>> comprovado: software open-source e publicações científicas.
>>
>
> Nenhum dos dois modelos involve leigos, mas pessoas altamente
> especializadas. Ninguém contribui num projeto de software sem ao menos um
> domínio básico das linguagens envolvidas. Ninguém publica em revistas
> científicas sem muitos anos de especialização. Outro ponto é que o número
> de pessoas envolvido num projeto de software é bastante restrito, assim
> como o número de pessoas que estão envolvidas numa publicação caberiam numa
> sala (exceto nas colaborações de física de partículas, exemplo LHC).
>
> Já o modelo do OSM envolve uma variedade de pessoas muito grandes, desde
> especialistas em GIS até leigos totais em cartografia (como eu por
> exemplo). Também o número de pessoas envolvido aqui é bem maior do que em
> qualquer projeto de software típico.
>
>
>> Ambos os processos são pautados no princípio do terceiro confiável.  O
>> OSM não aplica esse princípio, ou seja assume que uma das partes (no caso
>> os usuários) é confiável, e o resultado são as frustrações e as
>> consequentes perdas de tempo consertando que vemos com frequência.
>> Conclusão: o modelo de colaboração do OSM é ineficiente.  A solução para
>> essa ineficiência está aí.  Não fazem porque não querem.
>>
>
> Não sei como se poderia operacionalizar um modelo de validação eficiente
> no OSM diante de um público tão heterogêneo. Qualquer que seja a solução
> ela envolve gente para operacionalizar isto. A lógica dominante no OSM é
> que tendo uma massa grande de mapeadores qualquer problema seja rapidamente
> solucionado. O nosso problema aqui na América do Sul é que não temos essa
> massa de gente e por isto a lógica que funciona na Europa não funciona para
> nós.
>
>
>>
>> Os mapas do OSM existem em forma de XML, o que seria perfeito de se
>> sujeitar a um sistema de versionamento moderno como o Git e o Mercurial.
>>
>> O ser humano é falho, seja por má intenção ou por descuido.  O peer
>> review e o merge request são mecanismos criados para justamente impedir
>> tais falhas de contaminem os respectivos produtos de forma que o reparo
>> seja muito custoso ou que traga consequências ruins.
>>
>>
> Bom, eu trabalho com peer review diariamente e posso te contar cada
> história, mas isto é outra conversa ;)
>
> Agora, como o atual sistema funciona bem na Europa, eu percebo uma
> resistência muito grande em introduzir qualquer mecanismo que possa ser
> visto como uma barreira. A recente tentativa do Arlindo de solicitar um
> simples aviso no Id é bem emblemático disto, os desenvolvedores do Id nem
> deram papo e fecharam a requisição horas depois.
>
> Mas uma idéia que eu acho que podemos emprestar da área de software é
> trabalhar com versões beta e versões estáveis da base. Por exemplo, fazemos
> uma cópia local da base do 

Re: [Talk-br] Lacuna no mapa - SC

[Gerald Weber]

Oi Paulo,

interessantes as suas colocações, mas tenho algumas observações a fazer

2015-12-25 14:37 GMT-02:00 Paulo Carvalho :

> A coisa é muito simples e funciona.  Darei dois exemplos de sucesso já
> comprovado: software open-source e publicações científicas.
>

Nenhum dos dois modelos involve leigos, mas pessoas altamente
especializadas. Ninguém contribui num projeto de software sem ao menos um
domínio básico das linguagens envolvidas. Ninguém publica em revistas
científicas sem muitos anos de especialização. Outro ponto é que o número
de pessoas envolvido num projeto de software é bastante restrito, assim
como o número de pessoas que estão envolvidas numa publicação caberiam numa
sala (exceto nas colaborações de física de partículas, exemplo LHC).

Já o modelo do OSM envolve uma variedade de pessoas muito grandes, desde
especialistas em GIS até leigos totais em cartografia (como eu por
exemplo). Também o número de pessoas envolvido aqui é bem maior do que em
qualquer projeto de software típico.


> Ambos os processos são pautados no princípio do terceiro confiável.  O OSM
> não aplica esse princípio, ou seja assume que uma das partes (no caso os
> usuários) é confiável, e o resultado são as frustrações e as consequentes
> perdas de tempo consertando que vemos com frequência.  Conclusão: o modelo
> de colaboração do OSM é ineficiente.  A solução para essa ineficiência está
> aí.  Não fazem porque não querem.
>

Não sei como se poderia operacionalizar um modelo de validação eficiente no
OSM diante de um público tão heterogêneo. Qualquer que seja a solução ela
envolve gente para operacionalizar isto. A lógica dominante no OSM é que
tendo uma massa grande de mapeadores qualquer problema seja rapidamente
solucionado. O nosso problema aqui na América do Sul é que não temos essa
massa de gente e por isto a lógica que funciona na Europa não funciona para
nós.


>
> Os mapas do OSM existem em forma de XML, o que seria perfeito de se
> sujeitar a um sistema de versionamento moderno como o Git e o Mercurial.
>
> O ser humano é falho, seja por má intenção ou por descuido.  O peer review
> e o merge request são mecanismos criados para justamente impedir tais
> falhas de contaminem os respectivos produtos de forma que o reparo seja
> muito custoso ou que traga consequências ruins.
>
>
Bom, eu trabalho com peer review diariamente e posso te contar cada
história, mas isto é outra conversa ;)

Agora, como o atual sistema funciona bem na Europa, eu percebo uma
resistência muito grande em introduzir qualquer mecanismo que possa ser
visto como uma barreira. A recente tentativa do Arlindo de solicitar um
simples aviso no Id é bem emblemático disto, os desenvolvedores do Id nem
deram papo e fecharam a requisição horas depois.

Mas uma idéia que eu acho que podemos emprestar da área de software é
trabalhar com versões beta e versões estáveis da base. Por exemplo, fazemos
uma cópia local da base do OSM (digamos só do Brasil) da qual temos
razoável confiança de não ter nenhum problema maior e declaramos ela como
versão estável. A partir desta versão poderíamos produzir um índice de
qualidade calculado a partir de validações e testes. A versão estável só
seria substituída periódicamente por uma versão com índice de qualidade
maior, ou algo do gênero. A gente só usaria a versão estável para gerar
mapas para dispositivos ou quaisquer outros fins. A gente poderia até
eliminar localmente os changesets duvidoso da base estável, da mesma
maneira como bugs são corrigidos em versões estáveis de software. Bom, é só
uma idéia que precisa de amadurecer, mas se a gente conseguir por algo
assim para funcionar eu acho que a gente poderia conseguir a aceitação
disto de muita gente por aí que depende de maneira crítica da base.

abraço

Gerald
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br

Re: [Talk-br] Estamos vivenciando uma experiência meritocrática?

[Jose Carlos Medeiros]

A ideia é boa, mas precisa adaptar os canais existentes, como o Wiki, acho
que nem tem like nele, edição no mapa, seria por commit ou bloco?
Outra coisa, é ter bastante pessoas e que votem, senão fica tipo 5 ou 6
votos, já se seguir na linha de redes sociais, temos o pessoal que da like
em tudo.

Você já deve ter utilizado algum sistema de helpdesk, onde no final do
email tem uma forma de vc votar se gostou ou não, alguns com "sim, não" e
outros com "5 estrelas". Este acho até viável, acho que fácil de
implementar e ficaria padronizado, simples para entender e explicar.
Mas no mapa por exemplo é uma alteração boa, não sei se o pessoal do OSM
toparia alterar, fora os outros canais.

Em ambos os sistemas, basicamente você vai ter uma lista de pessoas que
poderiam criar as regras ou ter mais peso na comunidade, certo? Neste caso,
já não é uma espécie de legislação, já que eles vão decidir o que entra ou
não?



Att
José Carlos

Em 26 de dezembro de 2015 00:26, Alexandre Magno Brito de Medeiros <
alexandre@gmail.com> escreveu:

> Se o sistema que eu imagino estivesse no ar...
>
> Digamos que eu, Alexandre Magno, como usuário de openstreetmap.org, com
> as cédulas de votos (curtir) únicos que tenho, quisesse empoderar naoliv:
>
> Eu entraria nesse sistema, com a minha conta de openstreetmap.org, e
> sairia curtindo contribuições de naoliv. Só teria direito de curtir ou
> descurtir cada uma uma vez; ou seja, um único voto para cada contribuição.
> Contribuições feitas em fórum, wiki, e no próprio mapa, por exemplo. Para
> prevenir abusos, todos os usuários do sistema poderiam estar a par de cada
> curtida minha. Quem quisesse, poderia "descurtir" aquela contribuição de
> naoliv, na tentativa de anular minha curtida.
>
> Isso seria *um sistema de votação sempre aberto* e com escassez, que
> tenderia a realmente destacar os que realmente merecem. Pois os que tem
> problemas (ainda que apenas em âmbito de relacionamento interpessoal),
> teriam curtidas anuladas com descurtidas.
>
> Eu acredito que um sistema desses muito tenderia a ser justo!
>
> Alexandre Magno
>
> Em 25 de dezembro de 2015 23:09, Alexandre Magno Brito de Medeiros <
> alexandre@gmail.com> escreveu:
>
>> José Carlos,
>>
>> A computação de karma que você sugere já pressupõe poder nos definidores
>> das regras. Exigiria politização e legislação.
>>
>> O que eu estou vendo é que seria melhor ter como "curtir" diversos tipos
>> de colaboração (internacionalmente):
>>
>>- Mensagens nos históricos das listas
>>- Mensagens nos fóruns
>>- Edições no wiki
>>- Edições no mapa
>>- *Commits*
>>- *Pull requests*
>>- etc.
>>
>> Esperar que pessoas "curtam" outras (ou ao menos seus resultados), na
>> minha opinião, será a forma mais descentralizada de reconhecer o mérito. É
>> votação implícita, para o projeto global começar a constituir sua
>> democracia batedora de martelo.
>>
>> Alexandre Magno.
>>
>
> ___
> Talk-br mailing list
> Talk-br@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-br
>
>
___
Talk-br mailing list
Talk-br@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-br