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

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

Solution

  1. 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
  2. allow vote of credits for each task
    1. including delegation mechanisms (see later on)
  3. 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
  4. 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).

See also

Inspired by