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? > <http://meta.pt.stackoverflow.com/questions/1825/estamos-vivenciando-uma-experi%C3%AAncia-meritocr%C3%A1tica> > > 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 <gwebe...@gmail.com> > 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 <paulo.r.m.carva...@gmail.com>: >> >>> 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 > >
_______________________________________________ Talk-br mailing list Talk-br@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-br
