Planting a forest

[conseo]

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?

conseo