--- Log opened Fri Sep 16 00:00:15 2011
15:24 < conseo> mcallan: have you read my rough summary?
16:19 < mcallan> conseo: i ran out of time yesterday (blasted toolbar alignment was tricky) but am reading now...
16:35 < mcallan> it records your thoughts on the account/superaccount design, documented here: http://zelea.com/w/Category:Account
16:35 < conseo> yes
16:35 < conseo> is it wrong?
16:37 < mcallan> i don't know, it's just your thoughts.  is there a problem you are trying to solve?  at one point you speak of defining "resource targets" (a problem), but that seems to get lost in the general text
16:39 < conseo> the problem is that superaccounts are difficult to handle imho
16:39 < conseo> i have tried to find questions about the design which need to be addressed first
16:40 < conseo> i know that this is not documentation, it is rather a first attempt to structure the problem
16:40 < mcallan> what's the main problem? where should i look? in here? http://zelea.com/w/User:4consensus_WebDe/Resource_management#Disadvantages_2
16:41 < conseo> yes
16:43 < mcallan> so it's a critique of the current design.  ok, that's welcome
16:44 < mcallan> i would post just a single problem (misassignment of pledge) to the list for discussion (only you and i would discuss ofc)
16:44 < conseo> i have to get my terminology straight, so we know what we argue about. is there any further documentation of yours not linked on my page?
16:45 < mcallan> is it likely to occur, i would ask?
16:45 < conseo> e.g. some post on the list, where you documented it
16:45 < mcallan> mostly just what's in the wiki, it should be able to stand on its own
16:45 < conseo> ok
16:46 < conseo> yes it only happened that during drafting my picture the routing idea popped into my mind, so we can focus on that for now
16:47 < conseo> have i understood the superaccount model of yours correctly? (just in general, we discuss the rest on the list then)
16:48 < mcallan> i think so.  but i don't actually see the routing problem as likely to occur
16:48 < conseo> ok
16:49 < conseo> the problem is for example overflows of pledges. that way you can split and define the distribution of accounts
16:49 < conseo> but ok, i can post this to the list
16:49 < mcallan> this is a second problem?
16:50 < mcallan> 5? http://zelea.com/w/User:4consensus_WebDe/Resource_management#General_design_questions
16:51 < conseo> no it is whole lot of problems i can imagine. they can all be solved manually by changing accounts and pledges, but if we program the flow than pathologies can happen
16:51 < conseo> yes 5
16:52 < conseo> but maybe i am only seeing spectres
16:52 < mcallan> no, it's always ok to discuss.  i don't understand what "overflow" is
16:52 < conseo> people pledge too much
16:53 < mcallan> how is that a problem?
16:53 < conseo> they might want to pledge to whole account then, to fill gaps
16:54 < conseo> i mean to the whole plan
16:54 < conseo> what can superaccounts be?
16:54 < conseo> can they be defined by purpose or rather by type?
16:55 < mcallan> they can be anything the designer defines them to be, i guess
16:56 < conseo> overflow is not that critical if you have money pool where all the money for the plan is unified, but rather for labour types, or more narrow forms of contribution
16:56 < mcallan> my own definition: "A superaccount is a collection of accounts that share the same poll/issue, counting method and account name."
16:56 < conseo> yes i read that
16:57 < conseo> that is pretty tight
16:57 < conseo> so every poll has its own superaccounts
16:57 < mcallan> yes
16:57 < conseo> or are they possibly shared in definition
16:57 < mcallan> no
16:57 < conseo> ?
16:57 < conseo> ok
16:58 < conseo> so they can be defined by purpose
16:58 < mcallan> no
16:58 < mcallan> only by "poll/issue,  counting method and account name
16:58 < conseo> but the account name could be the purpose instead of type (like US$)
16:58 < conseo> ?
16:59 < mcallan> you mean change the design, yes that's always possible
17:00 < mcallan> currently there is no formalization of purpose, and it does not figure in the formal definition of an account/superaccount
17:00 < conseo> so i could formulate an account like 'buildings and infrastructure' and define some accounts like 'architect', 'building material' and 'construction labour' to it?
17:00 < conseo> ok
17:01 < mcallan> the last three, yes
17:01 < conseo> the first account meant superaccount
17:01 < mcallan> no
17:01 < mcallan> superaccount has same name as accounts
17:01 < conseo> hmm
17:01 < conseo> ok
17:02 < conseo> ah so 'US$' just happens to sound very type-like, but it could als be namend prize-money?
17:02 < mcallan> yes, suppose Henry defines "prize" account
17:02 < mcallan> and Heinrich defines "prize" account
17:03 < mcallan> both belong to same superaccount
17:03 < mcallan> two (or more) accounts, one superaccount
17:04 < conseo> ok, so they are not 'super' in an ontological sense, but rather common accounts (for my understanding)
17:04 < conseo> ok they are super somehow, just not as i thought
17:06 < mcallan> they only matter when the two accounts are in same branch of tree, or when vote shifts from branch to branch (i think you understood from your write up)
17:07 < mcallan> then superaccount identity (same between 2 accounts) kicks in, and the pledges are transferable
17:08 < conseo> ok
17:08 < mcallan> i was going to have subaccounts instead, but i think this is conceptually cleaner
17:09 < conseo> hmm
17:09 < mcallan> cleaner because: note that none of this affects resource accumulation in a single account
17:09 < conseo> http://zelea.com/w/User:Matteomartini72-YahooCom/G/p/prz/account/US$ here i pledge directly to matteo
17:09 < conseo> how is that shared?
17:10 < mcallan> no, you have not pledged
17:10 < mcallan> cheap bastard ;-)
17:10 < conseo> right, sry, i mean here i would pledge directly to matteos definition of 'US$'
17:10 < conseo> hehe
17:11 < mcallan> the sac kicks in only if someone else defines a "US$" account
17:12 < mcallan> then it has no effect on this account, but it does affect how your pledge flows elsewhere in the tree
17:12 < conseo> but my pledge would point to matteo, if i shift votes i still would have to repoint my account page?
17:13 < mcallan> the pledge does not point to Matteo
17:13 < mcallan> see: http://zelea.com/w/User:Mike-ZeleaCom/G/p/prz/pledge/US$
17:13 < conseo> Pledged using template User:Matteomartini72-YahooCom/G/p/prz/account/US$.
17:14 < mcallan> that does not matter
17:14 < mcallan> it's a template, look at the data properties at bottom
17:14 < conseo> this would be no problem, as long as my new candidate has an US$ account?
17:14 < conseo> ok
17:15 < mcallan> it is no problem, even if he has no such account
17:16 < mcallan> (your pledge is then ignored)
17:16 < conseo> ok, sure, that is what i meant
17:16 < conseo> for the pledger this is a problem
17:16 < mcallan> why?
17:17 < conseo> because she wants to pledge :-P
17:17 < mcallan> makes no sense to pledge, when it is not wanted
17:17 < conseo> sure, it is impossible to solve this without intervention (e.g. define an account herself)
17:19 < mcallan> i guess there is a problem, in that one is left with a dangling pledge (which looks untidy).  but yes, it can be fixed, as you say
17:19 < mcallan> will only happen in huge polls, i imagine
17:20 < mcallan> mostly the accounts will be universal in a poll
17:23 < mcallan> we only have two problems, as i see (1) defining resource target for a superaccount (2) defining which superaccount is viewed by default in difference bridge
17:23 < mcallan> the two are likely to have similar solutions
17:24 < mcallan> conseo: i can work on these problems at any time, i don't need a solution for my own work yet
17:24 < mcallan> i will turn to count engine now
17:25 < conseo> ok
17:27 < conseo> another problem is account reliability. once a poll further down the tree becomes enactable it's resources are taken away, so they are not really pledged to the top account, but rather to one down the tree
17:28 < conseo> superaccounts just show them as if they are the same
17:28 < mcallan> that is true, and contradicts my assertion that sac has no effect on ac
17:28 < mcallan> here the sac "steals" the action
17:29 < conseo> routing can be stopped at any position, showing exactly where the pledge is available atm.
17:30 < conseo> down the tree accounts are not enactable if the pledge is assigned up-roots (can one say that?)
17:30 < mcallan> by "stopped", you do not mean taken out of flow, do you?
17:30 < mcallan> you did mean that
17:30 < conseo> yes
17:30 < mcallan> currently, no stoppage except to prevent cycles
17:31 < mcallan> exactly same as votes
17:31 < conseo> so more detailed parts of the action can be defined in their own small plans voting for the master plan and becoming enactable independenlty
17:31 < mcallan> we do not formalize action, it is external to system
17:31 < conseo> for votes it is no problem, because they replicate infinetly
17:31 < conseo> exactly
17:32 < conseo> that way people can decide how the flow is going to happen, without needing a top-level consensus
17:32 < mcallan> (i think vote is similar, and also has actions)
17:32 < mcallan> what way?
17:33 < conseo> small 'local' plans can be enacted independently of the large scale action
17:33 < mcallan> right, and in that sense, ac can "steal" from sac
17:34 < mcallan> but again, we define *none* of that
17:34 < mcallan> it is enough that we allow it - we are flexible
17:34 < conseo> does that speak against the stoppable routing?
17:34 < mcallan> yes
17:34 < conseo> why?
17:34 < mcallan> no need
17:35 < mcallan> simply collect the pledges
17:35 < mcallan> they are pledged, and the *target* was met - so collect and act
17:36 < mcallan> this can be done for any account in the superaccount, upstream or down
17:36 < mcallan> (or off to side in another tree/branch)
17:37 < conseo> but it allows a different usage pattern of the vote tree, defining flow inline (by the candidates themselves)
17:37 < mcallan> candidate can already do that by shifting his vote
17:37 < mcallan> (or retracting it)
17:38 < mcallan> that stops flow
17:38 < conseo> right, but you cannot regulate it
17:38 < conseo> it is binary
17:38 < mcallan> how else could it be>
17:39 < mcallan> it either flows, or no
17:39 < conseo> a partial support and vote for the master plan, but some resources stay in your own plan going to be executed as stated in your own position
17:39 < mcallan> then change the account name
17:39 < conseo> it allows to still build a large consent
17:39 < conseo> but then flow stops
17:39 < mcallan> no, only the flow that account stops
17:40 < mcallan> which is what you wanted
17:40 < conseo> then all people downstream have to redjust their pledges to meet your own new account for your 'local' stuff
17:41 < mcallan> people downstream cannot pledge into upstream accounts (?)
17:41 < mcallan> you wanted a stop *upstream*
17:42 < mcallan> rememember, the pledge is tied to the vote
17:42 < conseo> routing would even allow to fine grain a single resource in many different accounts, by splitting it up
17:43 < conseo> upstream to the root and downstream to the single voter, right?
17:43 < mcallan> the stop is between root and leaf, yes
17:44 < mcallan> routing is by vote, and you want something else?
17:44 < conseo> no
17:45 < conseo> it is still all directed by your vote, but the accounts of your candidate may split it up for her candidate in a different way
17:45 < conseo> allowing different forms of accounts on different levels
17:46 < conseo> then every position needs to define its own accounts
17:47 < mcallan> i see a complex solution, but do not see the problem it solves
17:48 < mcallan> simplicity is a great strength, especially in combination with flexibility
17:48 < conseo> it allows that the plans sound differently locally, with defining a local set of resources and then this gets pledged upwards and there different accounts can be defined and managed
17:49 < conseo> they don't have to share the text in detail to follow the same plan
17:49 < conseo> this might be against the recombinant text idea
17:50 < mcallan> i still don't see the problem, at all
17:50 < conseo> ok, imagine you want to manage greenpeace
17:51 < conseo> you have thousands of local groups which all get funding and which all follow certain local plans
17:51 < conseo> then they support the central institution and get funding back if necessary
17:52 < mcallan> that's too much for a single poll
17:52 < conseo> but it is one economy
17:52 < conseo> they all work together for the same goal
17:53 < mcallan> we're not designing a budgeting system
17:53 < conseo> which is very vague, like to preserver natur and stop climate change or so, but it is common
17:53 < conseo> ok
17:53 < mcallan> budgeting system might inolve polls, but is something larger, external
17:54 < mcallan> *involve*
17:55 < mcallan> anything that involves multiple issues cannot be captured in a single poll
17:55 < conseo> why not?
17:55 < mcallan> well, i have to take that back
17:56 < mcallan> anything that involves multiple *non-rival* issues cannot be captured in a single poll
17:57 < conseo> is this for simplicity or for design?
17:57 < mcallan> both i guess
17:58 < conseo> has it theoretical reasons?
17:58 < mcallan> yes, separate issues (those that could exist in parallel) must be handled separately
17:59 < mcallan> otherwise you are forced to choose between them, when in fact both are possible
18:00 < mcallan> so the sol'n for greenpeace (if democratic) is thousands of polls
18:00 < conseo> but this doesn't allow upscale organisations(?)
18:01 < mcallan> why not?
18:02 < mcallan> mind you, not many orgs would want to be *that* democratic
18:02 < mcallan> but if you go nuts about it, then every possible issue can be floated as a poll.  no problem
18:03 < mcallan> cannot be floated as 1 poll, however
18:04 < mcallan> conseo: i will take a break for breakfast, soon
18:04 < conseo> ok
18:04 < conseo> i'll think about it
18:05 < mcallan> ok, back soon
20:30 < conseo> i'm off for today, see you tomorrow
20:32 < mcallan> ok, see you tomorrow
--- Log closed Sat Sep 17 00:00:31 2011