<div dir="ltr">On Sun, Jan 27, 2013 at 3:23 AM, conseo <span dir="ltr"><<a href="mailto:4consensus@web.de" target="_blank">4consensus@web.de</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hi Alex,<br> <br> ><br> > [alex]<br> > haha :-) That sounds funny.<br> > If I decide to apply a patch, then this could be interpreted as giving my<br> > vote.<br> > It isnt necessary to model the giving of votes in an explicit way, its<br> > given implicitly, right?<br> > At least that's how you sound<br> > [/alex]<br> You can cooperate in many ways. Still the concept of a vote is very distinct<br> in its formal expression of consent for some frame of reference. Patches don't<br> express consent, they merely show some exchange of ideas/valuable content.<br> Some distributed rcs would fit your needs then already. The problem is that it<br> lacks any form of necessary agreement (not even a central or trustable vote<br> count). While this can be expressed in the documents exchanged themselves,<br> this would be cumbersome and hacky to deal with (people have to manually pull<br> and push to update vote counts and a lot of cryptography has to ensure nobody<br> messes up the results. Still a trust-network would be desperately needed).<br> <br> ><br> > > (b) They need *generally agreeable* content in the variant draft.<br> > ><br> > > There's no other way to get the patch accepted by the pipe<br> > > minders downstream.<br> > ><br> > > (c) Win or lose, most of the members will eventually move on to<br> > ><br> > > other variants.<br> > ><br> > > (d) Groups are somewhat ad hoc. They don't always move as a unit,<br> > ><br> > > but may break up and reform in different combinations on<br> > > different variants, depending on personal interest.<br> ><br> > [alex]<br> > yes, this feels right<br> > [/alex]<br> ><br> > > So I'm thinking, maybe this is *also* how it starts? Differences at<br> > ><br> > > the earliest stage would be:<br> > > (s) Not many groups, ofc. Initially there's just a single group<br> > ><br> > > working on a single variant in one of the component branches.<br> > ><br> > > (t) Almost no patches have been accepted yet. The text is small.<br> > ><br> > > (u) Every patch is pretty much guaranteed to be accepted. NOT GOOD<br> > ><br> > > I think (t) is an advantage, because it makes the text accessible.<br> > > But (u) is a danger. It's unrealistic. We want a consensus that<br> > > everyone affected can agree to, not just one group. So maybe this is<br> > ><br> > > where we connect with forums? We use them to:<br> > > (f) Give us a quorum. We ask for an informal thumbs up/down on each<br> > ><br> > > patch relay. If the public doesn't like it, then we hold off.<br> > ><br> > > (g) Give us ideas for (b).<br> > ><br> > > Maybe this kind of "public consultation" would always be a good idea,<br> > > even when the canopy was buzzing with activity. It feels like the<br> > > right way to connect with a larger public. Of course, we might also<br> > > expect to attract new users from forums. But we'd never have to push<br> > > for that. All we'd really need is (f) and (g).<br> ><br> > [alex]<br> > by the way, your diagrams are hard to read, because somehow the font google<br> > mail uses often distorts them very much.<br> ><br> > reagarding (f) and (g), i dont understand who that should look like in<br> > practice and all the examples i can make up dont feel right<br> > [/alex]<br> Which examples? To me it makes some sense to raise patches in public forums<br> (fitting the issue) upfront in general, as this improves the reasoning and<br> quality of the proposals put forward. Note: This is only something like a best<br> practice, not in any way binding. You can still go on the wiki and put up your<br> own 10 pages position on X. One should just read the practices and at the same<br> time reflect the process imo and not just write something down individually,<br> but project that on potential supporters/voters.<br> What would you recommend as practice for raising an issue/position?<br></blockquote><div><br></div><div><br></div><div style>[alex]<br>I dont know, people talk a lot about stuff.<br>Embed an easy mechanism into their every day communication devises, that makes it easy for them to reference old said stuff while they are talking and add new said stuff to that already said stuff that was added earlier (thus patching it) :-)<br> So my pool of stuff grows slowly over time and sometimes i can "masturbate" by cleaning it up.<br><br>I catch myself collecting mem's i like. That might be famous quotes or short ways of communicating something in a nice way. My language changes over time by updating my personal pool of memes and my methods of disseminating them.<br> <br>It feels natural to talk to others and hopefully with tiny packet sizes instead of huge packet sizes. That might be a matter of taste, and some people read books all the time, so they seem to prefer huge packet sizes, but i prefer dialog with very small packet sizes, that means, i talk, other talks, i talk, other talks... and because i love tiny packet sizes, i often feel tempted to interrupt my partner before he could manage to finish what he wanted to say.<br> <br>I sometimes feel thats a shortcut, because i already think i know what he wants to say.<br>Frequent feedback can save time.</div><div style><br>The easier the frontend is or the more it is embedded in every day life, the less i feel pushed to put a lot of thought into what i write and format it to put it up somewhere. i just want to say something as quick as possible and publish it and i come back later to refine it.<br> <br>If the goal is to have very short commits, then make it easy to commit something all the time and make it easy to update, change, patch, whatever... that means, it should be doable by a 6 year old and by a 60 year old :-)<br> <br>its a lot about usability and embedding it in everyday communication systems.<br>[/alex]<br><br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <span class="HOEnZb"><font color="#888888"><br> conseo<br> _______________________________________________<br> Votorola mailing list<br> <a href="mailto:Votorola@zelea.com">Votorola@zelea.com</a><br> <a href="http://mail.zelea.com/mailman/listinfo/votorola" target="_blank">http://mail.zelea.com/mailman/listinfo/votorola</a><br> </font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif"><br>Best Regards / Mit freundlichen Grüßen</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif"> ***********************************************</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif">Alexander Praetorius</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif">Rappstraße 13</div> <div style="color:rgb(34,34,34);font-family:arial,sans-serif">D - 60318 Frankfurt am Main</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif">Germany</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif"> <b>[skype] </b>alexander.praetorius</div><div style="color:rgb(34,34,34);font-family:arial,sans-serif"><b>[mail] </b><a href="mailto:alexander.praetorius@serapath.de" target="_blank">citizen@serapath.de</a></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif"> <b>[web] </b><a href="http://wiki.piratenpartei.de/Benutzer:Serapath" target="_blank">http://wiki.piratenpartei.de/Benutzer:Serapath</a> </div><div style="color:rgb(34,34,34);font-family:arial,sans-serif">***********************************************</div> </div> </div></div>