Planting a forest

[Alexander Praetorius]

On Sun, Jan 27, 2013 at 3:23 AM, conseo <4consensus at web.de> wrote:

> Hi Alex,
>
> >
> > [alex]
> > haha :-) That sounds funny.
> > If I decide to apply a patch, then this could be interpreted as giving my
> > vote.
> > It isnt necessary to model the giving of votes in an explicit way, its
> > given implicitly, right?
> > At least that's how you sound
> > [/alex]
> You can cooperate in many ways. Still the concept of a vote is very
> distinct
> in its formal expression of consent for some frame of reference. Patches
> don't
> express consent, they merely show some exchange of ideas/valuable content.
> Some distributed rcs would fit your needs then already. The problem is
> that it
> lacks any form of necessary agreement (not even a central or trustable vote
> count). While this can be expressed in the documents exchanged themselves,
> this would be cumbersome and hacky to deal with (people have to manually
> pull
> and push to update vote counts and a lot of cryptography has to ensure
> nobody
> messes up the results. Still a trust-network would be desperately needed).
>
> >
> > >   (b) They need *generally agreeable* content in the variant draft.
> > >
> > >       There's no other way to get the patch accepted by the pipe
> > >       minders downstream.
> > >
> > >   (c) Win or lose, most of the members will eventually move on to
> > >
> > >       other variants.
> > >
> > >   (d) Groups are somewhat ad hoc.  They don't always move as a unit,
> > >
> > >       but may break up and reform in different combinations on
> > >       different variants, depending on personal interest.
> >
> > [alex]
> > yes, this feels right
> > [/alex]
> >
> > > So I'm thinking, maybe this is *also* how it starts?  Differences at
> > >
> > > the earliest stage would be:
> > >   (s) Not many groups, ofc.  Initially there's just a single group
> > >
> > >       working on a single variant in one of the component branches.
> > >
> > >   (t) Almost no patches have been accepted yet.  The text is small.
> > >
> > >   (u) Every patch is pretty much guaranteed to be accepted.  NOT GOOD
> > >
> > > I think (t) is an advantage, because it makes the text accessible.
> > > But (u) is a danger.  It's unrealistic.  We want a consensus that
> > > everyone affected can agree to, not just one group.  So maybe this is
> > >
> > > where we connect with forums?  We use them to:
> > >   (f) Give us a quorum.  We ask for an informal thumbs up/down on each
> > >
> > >       patch relay.  If the public doesn't like it, then we hold off.
> > >
> > >   (g) Give us ideas for (b).
> > >
> > > Maybe this kind of "public consultation" would always be a good idea,
> > > even when the canopy was buzzing with activity.  It feels like the
> > > right way to connect with a larger public.  Of course, we might also
> > > expect to attract new users from forums.  But we'd never have to push
> > > for that.  All we'd really need is (f) and (g).
> >
> > [alex]
> > by the way, your diagrams are hard to read, because somehow the font
> google
> > mail uses often distorts them very much.
> >
> > reagarding (f) and (g), i dont understand who that should look like in
> > practice and all the examples i can make up dont feel right
> > [/alex]
> Which examples? To me it makes some sense to raise patches in public forums
> (fitting the issue) upfront in general, as this improves the reasoning and
> quality of the proposals put forward. Note: This is only something like a
> best
> practice, not in any way binding. You can still go on the wiki and put up
> your
> own 10 pages position on X. One should just read the practices and at the
> same
> time reflect the process imo and not just write something down
> individually,
> but project that on potential supporters/voters.
> What would you recommend as practice for raising an issue/position?
>


[alex]
I dont know, people talk a lot about stuff.
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) :-)
So my pool of stuff grows slowly over time and sometimes i can "masturbate"
by cleaning it up.

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.

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.

I sometimes feel thats a shortcut, because i already think i know what he
wants to say.
Frequent feedback can save time.

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.

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 :-)

its a lot about usability and embedding it in everyday communication
systems.
[/alex]




>
> conseo
> _______________________________________________
> Votorola mailing list
> Votorola at zelea.com
> http://mail.zelea.com/mailman/listinfo/votorola
>



-- 

Best Regards / Mit freundlichen Grüßen
***********************************************
Alexander Praetorius
Rappstraße 13
D - 60318 Frankfurt am Main
Germany
*[skype] *alexander.praetorius
*[mail] *citizen at serapath.de <alexander.praetorius at serapath.de>
*[web] *http://wiki.piratenpartei.de/Benutzer:Serapath
***********************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.zelea.com/list/votorola/attachments/20130127/2744dd63/attachment.html>