Acho que não se trata de usar um "programa que o usuário está habituado e já possui acesso". Mas sim obrigar as pessoas a usar o GitHub. Pode ser que algumas já tenham contas lá e estejam acostumadas e felizes com ele, mas há pessoas que estão mais habituadas com GitLab, Gitorius, SourceForge, Bitbucket, Launchpad, etc, e há ainda pessoas (a maioria) que ainda não se cadastraram em nenhum desses serviços e podem vir a se cadastrar para poder participar da OK-Br. Se é para obrigar a usar algum serviço, que seja pelo menos um de código aberto.
Acho que o que o Raneire quis dizer com a analogia dele é para não nos deixarmos levar apenas pelo efeito rede, mas também por aquilo que a OK-Br defende: conhecimento aberto. Ou seja, concordo com o Luiz, é um motivo ideológico. Mas acredito que seguir motivos ideológicos é o que caracteriza uma organização que defende uma ideologia, afinal, não somos uma organização sem fins lucrativos à toa. > Sobre o motivo ideológico, que é o caso, não poderíamos ficar restritos a um > único caso. Se decidimos que não queremos usar serviços que não são totalmente > livres então não é só em relação ao GitHub que temos que pensar. Os serviços > de > Continuous Integration e Continuous Deployment que usamos em algum projeto são > 100% livres? Se não forem teremos que mudar também para manter a coerência. > Serviços de monitoramento? Armazenamento? Hospedagem? Algum deles usa código > proprietário? Então teremos que migrar. E assim por diante. Oba!!! =D Na minha opinião nós atualmente já não estamos sendo totalmente coerentes com o que defendemos. O que de certa forma é normal... tod@s têm suas contradições uma hora ou outra. É praticamente inevitável nos seres humanos e, consequentemente, nas organizações. Mas, acredito, as contradições precisam ser trabalhadas com o tempo. Adotando software livre nesse ponto seriamos, na minha opinião, um pouco menos contraditórios. Da última vez que tivemos uma discussão do tipo, sobre o GDocs, o fim foi meio "até curtimos software livre, mas não existe opção livre equivalente ao GDocs". Agora, "até curtimos software livre, mas no GitHub tem mais gente". Me pergunto que esforço a OK-Br está disposta a fazer para optar por software livre... Escolhê-lo quando é superior em todos os aspectos é fácil, mas é na situação contrária que a preferência se revela. Apesar de todo esse "blah, blah, blah", que o Tom chamaria de "masturbação mental", mas que acho importante para termos um momento de reflexão, no fim acho que isso vai ficar a cargo de cada projeto decidir, não? Como quase tudo na OK-Br (para o bem e para o mal). E, para eu mesmo não cair em mais uma contradição, o repositório do Cuidando 2.0 terá de ser no GitLab... Logo devo criar uma OK-Br em breve no GitLab para abrigar o projeto do Cuidando 2.0. Ah não ser que, dessa vez, decidam centralizar a decisão aqui e obrigar todos os projetos a usar o GitHub... Agora, mais especificamente sobre a integração "LabHub": Acho que o fato dela permitir o repositório aparecer na busca do GitHub já é algo bem bacana. Uma forma de permitir que o repositório seja mais facilmente encontrado, apresentar o GitLab para quem não conhece e advogar o uso de tecnologias abertas. Uma opção bem interessante. Mas, o que acontece se eu postar uma issue no GitHub do Noosfero? Ele vai parar no GitLab? E se eu fizer um pull request? Abraços! Quoting Luiz Armesto (2015-04-09 16:44:29) > Uma questão que quero levantar é: Há dois motivos para se decidir migrar de > serviço, um prático e outro ideológico. > > O prático é se as funcionalidades do serviço não atendem as espectativas ou se > o conteúdo que geramos fica preso ao serviço e não podemos levar junto se > quisermos sair, junto com a existencia de uma alternativa melhor. Neste caso > avalia-se serviço por serviço e escolhe-se o melhor. > > O ideológico é se apesar de na prática atender bem as necessidades existe > alguma característica, como no caso usar algum código proprietário, que é > contra os princípios do grupo. Nesse caso já se impõe um pré-requisito que > elimina automaticamentes vários serviços sem nem os avaliar. > > Em relação ao motivo prático não teriamos muito o que discutir nesse sentido. > Seria uma decisão bem mais objetiva e fácil de ser feita. > > Sobre o motivo ideológico, que é o caso, não poderíamos ficar restritos a um > único caso. Se decidimos que não queremos usar serviços que não são totalmente > livres então não é só em relação ao GitHub que temos que pensar. Os serviços > de > Continuous Integration e Continuous Deployment que usamos em algum projeto são > 100% livres? Se não forem teremos que mudar também para manter a coerência. > Serviços de monitoramento? Armazenamento? Hospedagem? Algum deles usa código > proprietário? Então teremos que migrar. E assim por diante. > > > Pessoalmente tendo a ser mais pragmático. O que produzimos é 100% livre? > Estimulamos que terceiros adotem a postura de liberar conteúdo de forma livre? > Esse tipo de mudança vai afetar, e se for será positiva ou negativamente, os > objetivos e princípios da OK? É uma mudança prioritária e relevante para o > atual momento? É isso que importa. > > Mas no final vai depender da visão geral do grupo, e o que for decidido ok. > > > []'s > > > 2015-04-09 16:17 GMT-03:00 Yasodara Cordova <[email protected]>: > > Outra observação crítica? > > Isso é realmente relevante agora? Nao seria melhor a gente cuidar dos > projetos e se isso decolar a gente pensa em mudar? Migrar do github nao eh > dificil. > > > Eu continuaria no github por hora, ja q ja estamos la. > > Frictionless, a la OK > > > > > ∞ w3c.br > ∞ ingraxa.eu > > > 2015-04-09 16:06 GMT-03:00 Diego Rabatone <[email protected]>: > > > Pergunta/reflexão: > > Mudar do github para o gitlab vai impedir algum novo(a) desenvolvedor > (a) de colaborar com o projeto, efetivamente falando? > Este é o "ponto-crítico" no processo de conseguir mais pessoas > colaborando? > > > -------------------------------- > Diego Rabatone Oliveira > diraol(arroba)diraol(ponto)eng(ponto)br > Identica: (@diraol) http://identi.ca/diraol > Twitter: @diraol > > Em 9 de abril de 2015 16:04, Thiago Gomes Veríssimo < > [email protected]> escreveu: > > Olá lista, > > É a primeira vez que escrevo nesta lista, mas a acompanho como > "ouvinte" há um tempo. > > Eu já me coloquei essa questão (github X gitorious (agora gitlab)) > muitas vezes. Acabei ficando com github (até o momento) pois lá > estão vários projetos não desenvolvidos por mim, mas que > eventualmente preciso enviar Pull Request. Assim por facilidade > estou no github. > > Acabei de fazer uma importação dos meus repositórios do github > para > o gitlab (usando a própria ferramenta de importação do gitlab.com) > e as issues foram importadas. Uma possível migração no futuro para > o gitlab não demandaria muito esforço. > > Portanto, dando minha contribuição, se a ideia é abarcar mais > desenvolvedores, acho que ficar no github é a melhor opção no > momento, mas que pode ser reconsiderada num outro momento. > > -- > Thiago Gomes Veríssimo > > > > Em 9 de abril de 2015 14:44, Luiz Armesto <[email protected]> > escreveu: > > Eu vejo mais como: > > A OKBr prefere > > (A) Que os dados orçamentários, que já são em CSV (livres), > sejam editados e visualizados em programas que o usuário está > habituado e já possui acesso. > > ou > > (B) que se troque o programa usado por uma alternativa livre, > fazendo com que todos que já editam esses dados ou quiserem > editar migrem. > > > Em ambas as alternativas os dados (dados orçamentários na > analogia, ou código fonte na discussão em si) já são abertos e > acessíveis. > > 2015-04-09 14:32 GMT-03:00 Raniere Silva <[email protected]>: > > > Ou seja, antes de pensar no "custo" de transferir ou > manter espelho, etc. > > do Github para outro lugar, há que se debater o dilema, > sobre o que a OKBr > > prefere, > > > > (A) aproveitar do "efeito de rede" já alcançado com o > uso > do Github. > > > > ou > > > > (B) usar uma solução mais livre e ideologicamente > compatível com a OKBr. > > Deixa eu escrever a pergunta de "outra forma". A OKBr > prefere, > > (A) que dados orçamentários sejam disponibilizados em PDF > porque todo mundo sabe abrir um PDF. > > ou > > (B) que dados orçamentários sejam disponibilizados em CSV > (ou algo similar) > porque é um formato mais livre que possibilita mais > pessoas utilizar > esse dado. > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: > https://lists.okfn.org/mailman/options/okfn-br > > > > > > -- > Luiz Armesto > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > > -- > Thiago Gomes Verissimo > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > _______________________________________________ > okfn-br mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/okfn-br > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > > -- > Luiz Armesto _______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
