Helder Ribeiro - Latest Comments

Re: O Processo Legislativo Animado: chamada para designers

barraponto — Tue, 08 Dec 2009 20:29:45 -0000

to interessado, mas absolutamente sem tempo...

Re: O Processo Legislativo Animado: chamada para designers

Manoel — Tue, 01 Dec 2009 20:04:30 -0000

Dá uma olhada em:
congressoaberto.com.br

Re: Untangling licensing options to achieve better collaboration on free web software

helder — Sun, 22 Nov 2009 10:28:20 -0000

The conveying part is exactly what makes it possible for you not to release the source code for App 3 (GPL). That is, of course, as long as App3 is a web application, for which you will not distribute any executable code. "The terms of this License will continue to apply to the part which is the covered work" means that you'll have to give back changes you make to the code from App1 (AGPL). "But the work with which it is combined will remain governed by version 3 of the GNU General Public License", and the GPL doesn't require you to give the source code *unless* you also give executable code. Assuming App3 is a webapp, the executable is only on your server, so only your server has a right to the source code. That's how I understand it anyway, but I'm not a lawyer.

Re: Untangling licensing options to achieve better collaboration on free web software

pheonix — Thu, 19 Nov 2009 06:53:35 -0000

I've been reading section 13 of AGPL v3 license.

It is as under:

"Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the work with which it is combined will remain governed by version 3 of the GNU General Public License."

If I understand correctly, let there be an application App1 licensed as AGPLv3 and another Application App2 licensed under GPLv3. If I create another application App3 utilizing App1 and App2, then the part of App3 derived fro App2 are governed by GPL v3 and parts of App3 derived from App1 are governed by AGPL v3, only when we "convey the resulting work", i.e. convey App3. Now checking the description of "Convey" in terms and conditions section of AGPL v3 license it is stated as :

"To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying."

So the steps mentioned by you does not hold good. I beleive what section 13 of AGPL v3 implies is that we will have to provide source code for App3 as whole, but the reciever would have to treat the part of App3 derived from App2 as GPLed code whiel other parts of App3 as AGPLed code. But we cannot keep the source code of App3 derived from App2 closed.

Please comment....

Re: Wish: RSS Tab Creator

twitter-1676711 — Wed, 04 Nov 2009 11:31:45 -0000

that wouldn't be too hard to implement as a greasemonkey script for Google Reader (since it already keeps track of what you've already read) -- so it's only a matter of opening links, right?

too bad I'm not a JS developer, your idea is rad :(

Re: Code Review + Google Wave = Code Wave !

helder — Thu, 15 Oct 2009 11:13:52 -0000

Hi Mathieu! It's really cool to see a similar idea starting somewhere. I have recently become involved in a different project that's taking most of my time, so unfortunately I won't be able to help out with tweekers, but I'll watch closely to see what you guys come up with! Thanks for telling me about it and congrats for the initiative!

Re: Code Review + Google Wave = Code Wave !

openid-11999 — Wed, 14 Oct 2009 11:03:07 -0000

Hi
I have a started a project which contains similar features.
I'd like to build a Wave based application that would be able to retrieve source code from any Open Source project, and let the users discuss on the source code. The other major part of my project is the documentation.
I would like it very much if you joined the development team on Launchpad : https://launchpad.net/~tweekers-dev-team
You have bright ideas and I'm pretty sure that you could bring something of value in the project.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

Vinicius Alves Hax — Wed, 30 Sep 2009 12:25:47 -0000

Excelente texto e iniciativa mais legal ainda. Parabéns.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

heliopaz — Mon, 07 Sep 2009 14:31:26 -0000

Sou plenamente favorável à democracia líquida. Todavia, há uma série de variáveis imprescindíveis e inexoráveis que devem ser consideradas:

1) Em qualquer ideologia, faixa etária, profissão, escolaridade, religião, sexo, etc., o conservadorismo prevalece. Não há como mudar a sociedade de uma hora para a outra, nem mesmo com pesados investimentos em mídia de massa e educação. As coisas mudam, sim. Mas é preciso dourar a pílula. Do contrário, pode haver uma rejeição insuportável antes mesmo de as pessoas tomarem contato com a informação acerca das idéias;

2) A grandissíssima falha de todo e qualquer movimento social é ignorar o fato de que a legislação do país é feita não com base naquilo que seria mais justo para a maioria da população (que é pobre, possui pouco estudo, etc.) mas, sim, para manter o status quo. Do contrário, nas principais faculdades de Direito e nos concursos para os cargos mais cobiçados do Judiciário, não passariam prioritariamente aqueles de maior poder aquisitivo (herdeiros de bancários, empresários, latifundiários, políticos profissionais, etc.). Da mesma forma, até mesmo entre esses há pessoas de muita sabedoria, que são jogadas em uma vala comum junto aos clientelistas, oportunistas, corruptos e assassinos que advogam em causa própria;

3) Como as leis que regulam a comunicação social, a energia, as telecomunicações, a educação, a saúde, a infraestrutura e a economia são criadas e alteradas principalmente por essa categoria de cidadãos, dependemos de uma parcela minoritária que representa muito mais a seus patrocinadores do que aos eleitores em si. Isso posto, como a esmagadora maioria dos especialistas de alto nível provém desse substrato da população cuja ideologia conserva o patrimonialismo, a elitização e centraliza as decisões, a distinção entre a opinião especializada que é mais técnica do que política torna-se crucial, pois é muito subjetiva;

4) O judiciário, a lei eleitoral e o código civil precisam ser amplamente analisados. Toda mudança legal precisa ser altamente propositiva, com um discurso que vá direto ao ponto. A esquerda ortodoxa peca por ser partidarizada e sindicalizada ao extremo. Isso resulta em manifestações que a classe média urbana percebe como ignorantes, pois exigem demandas imediatas que não possuem contrapartida legal. Portanto, o desconhecimento das leis costuma fazer os movimentos sociais pagarem uma série de "micos" e não tem suas demandas assistidas;

5) A preocupação com a estética, com a funcionalidade, com a agilidade e com a qualidade da interação e do volume de informações existente nesse site deve ser algo único e extremamente seguro, com subdivisões setoriais a partir de tags e tudo definido com tecnologias da Web 2.0 como, por exemplo, o Ruby on Rails. Designers e desenvolvedores da comunidade do Software Livre precisam ser recrutados em grande quantidade. Mas as discussões e os protótipos não podem ser discutidos ad eternum. Alguém conhece a plataforma WISER de http://wiserearth.org ? A Wiser com um mashup que englobe blogs, YouTube, Twitter, Flickr, iTunes podcasts, etc... Enfim, fica como sugestão...

[]'s,
Hélio

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

1anonimo — Mon, 07 Sep 2009 01:35:29 -0000

Aloha,

Muito bom encontrar esse debate aqui, iniciei um projeto similar em meu blog, iniciei a extração das informações da câmara dos deputados.

Uma aplicação que já está evoluida é o nationbuilder.com, um sistema opensource, integrado com o twitter e o facebook. O interessante do sistema é a importancia para as prioridades. Votar propostas sem prioridade para o povo é uma estratégia utilizada pela democracia corrente.

Deixo aqui o meu contato para juntarmos forças e fortalecer a democracia.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

Daniel Veloso — Tue, 04 Aug 2009 23:32:16 -0000

Eu acho a idéia excelente, mas não vejo como resolver um problema: coronelismo.

Eu imagino aquele sultão do nordeste, com aquele sotaque carregado falando:
"vô butar aqui um cumputador pra modi cês votar cunforme meu apadrinhado que é ixpÉcialista em sociolugia."

Na medida em que se pode acessar o sistema de casa, acho que pode até surgir um novo tipo de coronelismo, um coronelismo urbano, que vai encontrar nichos maravilhosos em repartições públicas.

Talvez o sistema seja interessante pra comparar os votos do povo com os dos políticos, e ajudar a escolher políticos q tenham mais a ver com o eleitor.

Mas eu acho muito legal o conceito de parlamento digital. Infelizmente acho que não funciona. Será que isso tem solução?

Grande abraço!

Re: The Holy Grail of Kickass API Documentation

helder — Mon, 03 Aug 2009 12:52:57 -0000

Damn it. Now I have no excuse to offload this to you guys :P

Re: The Holy Grail of Kickass API Documentation

jeffrafter — Mon, 03 Aug 2009 12:49:38 -0000

Lots to digest here but I see where you are going. I think it will be hard to know which one will work better in practice until we try it :)

I get what you are saying about over-forking being a problem, and I see how rdoc.info could maintain its own forks (I suppose these would live in the github.com/docs account we have setup).

In terms of opensourcing... we did it from day one :) http://github.com/zapnap/rdocinfo. Fork away and implement this feature! ;)

Re: The Holy Grail of Kickass API Documentation

helder — Mon, 03 Aug 2009 11:22:41 -0000

Oh wait. I need to clarify the difference between the "no-hostages" thing with the "which version to display by default" thing.

When you go to the docs for a repository, you see the *latest possible version*, regardless where it came from. If that's the owner's latest commit, you see that. If it's a wiki edit after that latest owner commit, you see the wiki version. That's the "which version to display by default" thing.

The "no-hostages" thing is the opposite of what you thought. When the owner commits something, *that* becomes the latest version. The previous wiki edit is moved to the history, and the owner's version is displayed (which is the same as saying that, in the merge, all conflicts are resolved *in favor of the owner*.)

Of course that, for repositories that were put in rdoc.info by someone other than the owner, it would be frustrating for wiki editors to see their changes being clobbered by commits from the oblivious owner all the time (even though still recoverable from the history). That's why I suggested that wiki editing be opt-in by the owner.

One problem with the workflow you suggested is that it creates a multi-headed wiki, without a clear linear history. And if you don't show the latest edit immediately (instead waiting before the owner folds them in), there's a higher chance that people will step on each other's toes, fixing the same typo or editing the same line multiple times. The longer feedback cycle makes conflicts more likely and integration more difficult. Worse than that, the workflow is incompatible with the way rdoc.info tracks documentation.

Rdoc.info tracks documentation *per-fork*, independently. Take http://rdoc.info/projects/search?q=delayed_job, for example. I keep a fork of delayed_job because I have a feature there that is not present in other forks. According to your workflow, if I edit the docs for helder-delayed_job to describe my feature, collectiveidea and tobi are going to get pull requests for that change, which doesn't make sense. And if I want to edit *their* docs (maybe I found a typo in the docs for a feature they have and I don't), that change will be committed to *my* fork, which doesn't make sense either. Also, this workflow requires that a user have a github account and fork the repository just to make a simple edit. Unnecessary forking polutes the network and your fork list -- I'd rather have forks only for projects I'm doing significant contributions to.

What we need is one linear (centralized) doc history *per fork*. So you'd have separate doc histories for helder-delayed_job and tobi-delayed_job, etc, which everyone could individually edit without needing to fork it themselves, or without affecting their own fork in case they had one.

My original idea actually falls short here as well, as the rdoc.info user can't fork different repositories *of the same project*. So patch my idea with:
-Rdoc.info forks your repository and commits every wiki edit to that fork.
+Rdoc.info forks your repository (if it hasn't already), *creates a branch to track your fork* (named, say, "helder-docs") and commits every wiki edit to that branch.

So if I go to the docs for tobi-delayed_job, what I'm seeing and editing is always the head of the tobi-docs branch in rdoc.info's fork of delayed_job (github.com/docs/delayed_job/tree/tobi-docs).

If it's the docs for my own fork, edits go to helder/delayed_job/docs, which gets picked up by rdoc.info and merged back into docs/delayed_job/helder-docs.

I don't know if I made this sound too confusing, but it's actually quite simple :) We can schedule a skype talk if you want so I can explain this better (I'm obvio171).

Btw, do you guys consider opensourcing rdoc.info? ;)

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

RafaelReinehr — Mon, 03 Aug 2009 10:19:29 -0000

Glommer, conforme a discussão acima (e como libertário em essência), também não concordo que uma maioria numérica deva ser superior à consciência individual.

Porque oras bolas sou obrigado a enfiar meu filho em uma escola? Para ser doutrinado e ensinado a obedecer a um sistema criado por um grupo de pessoas que se esmera para perpetuar-se no poder?

Recentemente, o RS proibiu a existência de escolas dentro dos assentamentos do MST. Por que? Por que lhes era ensinado conforme os preceitos defendidos por Paulo Freire, com sua pedagogia libertária. Os alunos eram ensinados a questionar, a pensar, a serem livres.

Imagina uma turma de "revoltados" se formando? Se a nossa geração, ensinada e doutrinada dentro do sistema convencional já não se deixa enganar facilmente, imagine esta turminha que vem das escolas do MST...

Pois bem, estou aqui para ouvir e expressar. Por experiência própria, concordo com o que foi dito acima em relação ao nosso maior desafio: combater a inércia da população, que prefere ouvir gurus e manter-se no confortável hábito de seguir líderes do que mexer a bunda cada vez mais gorda (isso não é um insulto aos gordinhos, apenas uma observação estatística advinda do crescimento do sedentarismo) para tomar uma atitude em prol de si mesmo, de sua família e da comunidade.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

glommer — Mon, 03 Aug 2009 09:53:26 -0000

Eu tenho discutido muito esse assunto com o Helder, em várias oportunidades que temos. Depois de muito discutir, ele acabou me apontando um fato que eu havia deixado passar batido, mas que é de extrema importância: o projeto que ele propõe não contempla o voto-laranja!

Nesse sentido, ele se torna apenas um instrumento de informação e discussão, que não tem os perigos que tanto me preocupavam.

O que eu acharia bacana é o seguinte: Quando você dá o seu voto (que não é um voto para a camara se eu bem entendo, mas só para avaliar a força de cada idéia), você não tem a opção entre votar, e transferir seu voto a um acessor: você tem a opção entre votar, e transferir seu voto a um partido político.

Porém, os partidos políticos não são estáticos, e nem são os mesmos em cada discussão. São demarcados a medida que a discussão flui, provavelmente no início, até chegar a um ponto de equilíbrio. Exemplo simples, de escala municipal:

Discute-se o aumento de verbas para um grupo de escolas.
A medida que analisa-se o projeto, os próprios participantes definem um grupo de opiniões representativas sobre o projeto (se houver duvidas, posso explicar separadamente como é viável se fazer isso)
Elas podem ser, por exemplo:
* Aumentar incondicionalmente a verba dessas escolas
* Aumentar, condicionada ao evento A (decréscimo de impostos, por ex)
* Aumentar, condicionada ao evento B (que o aumento seja para pagar professores, por ex)
* Aumentar incondicionalmente, mas numa porcentagem menor que a proposta
* Não aumentar a verba dessas escolas

Temos nesse caso 5 "partidos políticos" para essa discussão, e eu posso me alinhar com o que eu achar que mais representa a minha opinião.

Isso confere uma fluidez ao sistema, que só é possível através do uso de uma tecnologia como a internet, aplicada em uma população representativa, e que é capaz de organizar a discussão de uma forma que as instituições formais não são capazes, devido a sua estrutura.

Torna a própria noção convencional de partido político obsoleta, a longo prazo. Uma pessoa qualquer, é um complexo emaranhado de opiniões distintas. Por mais que eu me filie a um partido político, isso não quer dizer que eu concorde com todas as posições que eles tem.
No Brasil não há, me tomando como exemplo, um só partido que represente bem o meu espectro de opiniões, apesar de em diferentes discussões, eu me alinhar mais com um, ou com outro.

A existência de uma ferramenta deste tipo faria esse projeto ganhar meu apoio incondicional.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

RafaelReinehr — Mon, 03 Aug 2009 09:37:14 -0000

Helder, foi feita uma tentativa com um vereador da minha cidade mas que, infelizmente não foi para frente por simples falta de condições tecnológicas. A equipe de desenvolvimento daqui não "entendeu" a ferramenta e a logística da câmara não permitiu que a ideia fosse implementada. Ou seja, o próprio sistema se protege, como seria de se esperar: os projetos de lei muitas vezes são apresentados horas antes de serem votados, não há pauta ou a pauta não é respeitada e por aí vai. Então, transparência zero.

O Voto Contínuo não foi debatido ou implementado como protótipo basicamente por falta de condições técnicas, eis o resumo. Coloco muita fé no grupo que está se formando no Parlamento Aberto e estarei presente diariamente no grupo, extremamente atento ao desenrolar das funções. Tenho uma série de artigos, alguns extremamente importantes sobre a questão do voto e democracia representativa/líquida/participativa que gostaria de compartilhar mas infelizmente estão arquivados em um notebook cujo processador foi para o espaço. Tão logo eu o recupere compartilho.

Meu maior interesse é deixar a cargo do grupo que está se formando o desenvolvimento deste software que, tenho certeza será fantástico, mas colocar-me à disposição para integrá-lo à ferramenta que estamos desenvolvendo, para não somente debater e votar mas também IMPLEMENTAR as mudanças que precisamos. É disso que trata a Coolmeia.

Gostaria muito de sua permissão para entrar em contato via telefone ou skype para que possamos falar mais detidamente. Por favor envie por mail algum destes contatos, se possível.

Re: The Holy Grail of Kickass API Documentation

jeffrafter — Sun, 02 Aug 2009 14:01:34 -0000

I think I am still a little confused on the "no-hostages" approach. Many of the projects hosted on rdoc.info were put there by people other than the project owner. It is likely that the owner will make a change after the wiki edit which will conflict. It seems like choosing the wiki version outright is dangerous... the owner may have changed the documentation because the implementation of a method changed... in which case you wouldn't want to save the wiki edit. It seems like the owner version needs to always be the one that shows.

In our version, instead of maintaining a separate branch you do exactly what github encourages you to do and maintain a separate fork (which is just an ad-hoc kind of branching). When you make a change, we should do the following:

(1) If you a committer on the project (or owner): automatically commit the change that you make to the wiki style interface. This is the easiest thing.

(2) If you not a committer: fork the repo, but not as the rdoc.info user... as the current user (we will need to connect the github user to the rdoc.info user). Then make the commit to that fork and redirect from the current docs view to the users new forked version of the docs (which we auto-generate). Send a pull request.

(3) Modify the interface to list related forks, revisions, and tags. This is planned already, but would become pretty important.

Does that workflow make sense?

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

Thiago Bastos — Sun, 02 Aug 2009 12:57:47 -0000

A idéia é muito boa e merece, no mínimo, que seja divulgada para o maior número possível de pessoas, Quanto a colaborar: a princípio, colaboro desde já divulgando a idéia e o site, até porque foi assim que tomei conhecimento. Abraço e vamos nessa!
Thiago Bastos
Rio de Janeiro-RJ
PS.: muito boas as discussões sobre 'ditadura da democracia', etc; debates construtivos são fundamentais

Re: The Holy Grail of Kickass API Documentation

helder — Sat, 01 Aug 2009 18:33:58 -0000

I see what you mean, but I think just letting visitors add notes and requiring that someone else adapt it to the documentation and commit it is still too much trouble. And even if it weren't, this model basically covers edits which would add _new_ stuff, like "hey, you forgot to mention this and that".

It still doesn't cover some classes of edits like correcting typos, grammar, reorganizing text to improve how it's structured, and rewriting parts to improve clarity. Notes basically add coverage, but don't improve quality.

Opensourcing APIdock is great news! I haven't been following it too closely, so I hadn't heard of this. The whole auto-fork thing needed to implement wiki editing is indeed not trivial, but I think it would be a great thing to have.

Re: The Holy Grail of Kickass API Documentation

helder — Sat, 01 Aug 2009 18:23:11 -0000

The model I mentioned for the edit history above takes care of this. For repositories that choose to allow wiki editing, the default commit shown wouldn't be the most recent from the owner, but the most recent wiki commit (which, by definition, would be ahead of the latest owner commit). The wiki history would be like:
edit - edit - merge from owner - edit - merge from owner - edit - edit

And new changes would be instantly visible. The latest owner version will still be reachable from the history, and you can make it somehow visible to the visitor if they're seeing a page with changes that weren't yet folded in, linking to the latest pristine copy.

Re: The Holy Grail of Kickass API Documentation

Otto Hilska — Sat, 01 Aug 2009 10:03:43 -0000

Hi, this is Otto from APIdock. I'm replying here instead of private e-mail.

When we were initially writing APIdock, having the wiki-style editing seemed like core functionality. However, after we had run the site for a while, it occured to me that wiki-editing doesn't actually solve the problem.

The #1 priority is to lower the barrier of contributing - and that's exactly what user-generated notes are good at. However, many of them are not directly ready to be used in official documentation.

So far it has been easier to pick the good stuff from notes and commit it to lifo's docrails Git repository. We're hoping to improve this in the future.

There are some plans about opensourcing APIdock, so theoretically it would be possible for anyone to add the wiki editing functionality. But still, I don't think it would be so much better than simply committing to docrails.

Re: The Holy Grail of Kickass API Documentation

jeffrafter — Sat, 01 Aug 2009 07:33:40 -0000

Reading through your post this is very similar to something nick and I
batted back and forth when we were making the site. In general we had
considered taking this even further by doing cross site commits and which would make use of github's already existing web-based commit system. This was more apparent when we made http://docs.github.com (the rdoc.info mirror on GitHub). Auto-forking is of course a much more in depth part of that. Also, keep in mind that we store docs for every revision of a project... so it is possible that the default commit (the most recent) may not show your changes until they are accepted and folded in. How would you handle that?

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

bruno de niz — Fri, 31 Jul 2009 04:22:53 -0000

Fala Helder

Parabens, cara, pelo texto, pela ideia e pela iniciativa.
Acho muito interessante e gostaria de participar também(acabo de me inscrever na lista).
Apesar de achar que o bom senso geralmente nao esta nas maos da maioria, acho que um sistema como esse poderia facilitar a participacao das pessoas nas tomadas de decisoes e quem sabe assim tornar-lhes mais conscientes.
Sobre as métricas de efetividade das leis, acho que nao convém quantificar tudo porque as leis em muitos casos têm resultados tacitos cujos efeitos subjetivos, humanos, etc nao podem ser quantificados simplesmente quem dira automaticamente.
Bom, é algo bastante complexo que tem muita coisa pra ser discutida.
Abraço.

Re: Democracia Líquida no Brasil: Uma Realide Possível (a curto prazo!)

helder — Thu, 30 Jul 2009 21:50:37 -0000

Nossa, que ótimo! Acho que esta ferramente terá um potencial educacional incrível! As crianças verão como o legislativo funciona de perto sem precisarem ir a Brasília, e se acostumarão desde cedo a achar normal terem a chance de votar elas mesmas. Pensa uma geração inteira crescendo assim!