Fabien Benetou's PIM | Proposals / ProjectMeritocracy

Welcome to for http://groups.google.com/group/general-intelligence visitors.
Discussion welcomed on the mailing list.

Principle

democratically manage http://code.google.com/p/genifer/ in a truly distributed yet efficient fashion

Needs

collectively decide what's to do next and who deserves credits

Pre-conditions

we do not have a working AGI yet
- no working AGI solving this problem for us
most members are "honest"
- allowing to focus on the actual useful code, not extremely time-costly security problems

Solution

track every contribution, even outside of the code base
1. e.g. wiki
  1. e.g. getting funding would be written down in the wiki in a dedicated page and could thus be voted on
allow vote of credits for each task
1. including delegation mechanisms (see later on)
provide an explicit rule system
1. with by default (but changeable)
  1. code (rules + engine) and data (votes + changes) are public
  2. initial voting "coins" are distributed ~~randomly~~ equally amongst voters ~~(to induce participation to change this very rule)~~
  3. decisions with "coins" on the changes to this system (rules or engine) are synchronous (up to the point of the decision being sure, initially majority) coins are used, credits are spent
  4. take-over is possible, no safety mechanism
    1. if initial members gain less and less voting power based on overall decision, the project aim will drift
  5. reward "credits" allocation decisions are asynchronous
  6. an API is provided to make reward allocation prone to personal automation
allow scripting of the user own rule system
1. distributions templates (mathematical repartition)
2. patterns templates (conditional and sequential)
3. mimicking templates (delegation)

Risks

information to vote
- lack of, e.g. when somebody has to judge a domain that is out of his domain of expertise
- overload of, e.g. when too much information is provided and make the decision intractable
social bias
- friendship based vote
- retaliation based vote
cheating
- manipulation of the voting system itself, e.g. double spending or other re-allocation
increase load outside of production itself
- cognitively
  - e.g. using finance tools, quantitative tools, in order to try to maximize accumulation with no regards whatsoever to actual productivity and long-term planning
- socially
  - i.e. weighting the social consequences of having the voting known by others rather than focusing on the impact on the success of the project itself
lack of social recognition over time if no activity
- recognition should still be there but decision making and voting power should not since the participant has outdated knowledge of the project relatively to active participant
  - this could tweaked by making the decay of voting power decrease non-linearly based on the amount of voting power gained

Current situation

using Google Code with its own wiki and mercurial
- the wiki provides no API but it is hosted within a mercurial repository
  - hg clone https://wiki.genifer.googlecode.com/hg/ wiki
- webhooks are supported
- authentication is supported
- rules, credits and voting power could be stored in the code repository too in order to keep modifications to them public
- voting "coins" and reward "credits" could be fusioned if credits are proposed as "bounty" as a duplicated proportion of what the user currently have
  - but at the risk of himself fetching his own coin?

Consequently, making a mercurial plugin would thus allow easy usage by the developers (supposedly the main contributors) but could still in a second time provide a simpler interface (web server).

Inspired by

PriorityByEconomicalSystem
management tools a la Microsoft Project
software development group tools a la Trac and Git

Project Meritocracy {Proposals}