proj-amendableCode-acnotes

AmendableCode? will be a webservice for group governance with the following distinct features:

The rest of this page is notes to myself and may not be very comprehensible to others.

API

RESTful, i hope...

/api/version/

/user/
 n
 news
 by-id/
  /*
   influence
   payout
   stake
   effectiveStake
   strength
   news
   constituency/
    nominees
   position
    /*
 by-strength/
  /* dup -- only lists up to 50% (the # needed to calc n)
 pending/ (post here to apply to join)
  */
 search

/forum
 news
 /proposal
  id/
   */
  search
 /slot
  */
 /user/
  /*
  token
  proposal

/official
 /tribune
  news
  /senior
   /website
   /pending-resolution
    *
   /published
  /middle
   /website
   /mediation
   /published
  /junior
   /website
   /published

 /exec
  news
  /ceo
   /website
   /portfolio
    */
     reassign/
      */ (confirmed cabinet members)
     nominate
  /eeo dup
  /cabinet
   by-user/
    */
      website
      portfolio/
       */
        dup
   by-portfolio
    */
     user/   dup
     description
     [plugin]

 /chair
  news
  /emergency
   /lock
  [plugin]

 /judge
  news
  /by-user
   term
  /by-court

 /elect
  news
  /primary
   /election
    term
     /beginDate
     /nextElectionDate
    election/
     current/
      vote/
       ballot/
        *
     result/
      */
       candidate/
        nominator/
        round/
         winner/
         candidate/
          */
          support/
          score/
   user/
    website
    vote
     */ (proposals)
     ceo/
      */
       (vote; -1,0,1)  
   chair

   announce/
    chair
    ceo
 
  /external dup  (except eeo, not ceo)
 /delegate
  announce
  news
  user/
  chair

/constituency
 announce
 news
 constituency/
  */
   news
   join
   election/
    candidates
     */
      support
      score      
    ballot/
     */
   delegate/
    announce
    website
    user
    beginDate
    history
    strength
   member/
    */
     nominated/
      */ (user ids of nominators)
    history    
   superconstituency link
   subconstituency/
    */ link

   history

   forum/
   
  search
 user/
  */
  constituency

/xcouncil
 announce
 news
 council/
  */
  location
  vote/
   pending/
    */
     supporting-user/
      */      
   history/
 user/
  */
   council
   apply
   resign


/court
 news
 /by-id
  high/
   judge/
    /*
   pendingResolution/
    */
     valid/ (list of judges)
     invalid/ (list of judges)
   case/
    tribune-initiated/
     */
      dup
      strike/
       */
      forceClarify/
       value
       supporter/
        */ (list of judges)
         comment
       dissenter/
        */ (list of judges)
         comment
       text
       beginDate
       endDate
       success/
        value
        yes/
         */ (list of judges)
          comment
        no/
         */ (list of judges)
          comment
        fix/ (only if success value == false)
         (a patch to the policies)
      */ (list of judges)
      findRight/
    tribune-restraining/
     pending/  (b/c we have to see if the other tribunes will sign onto it)
     */
    office-initiated/
    appeal/
     pending/
     */
      dup
      acceptCase/
       */ (list of judges)
    ordinary/ (only if there are no other courts)

   foundRight/
    */
     text
     comment
     supporter/
      */
       id
       comment
     dissenter/
      */
       id
       comment
    pending/ dup
  /*
   judge/
    /*
   case/ dup
 case/
  by-id/
   */
    type
    news
    round/ (orig, appeal, etc)
     */
      announce/
       */
      status
      plaintiff/
      defendent/
      complaint/
       */
        statement
        type
        uri
        violation
        argument/
         due
         plaintiff/
          text
          date
          history/
         defendent/
          text
          date
          history/
        decision/
         decision
         date
         detail/
          [plugin] (vote count of multiple judges, etc)
         remedy
         comment
         dissent/
          judge/
           comment
      question/
       rule
        */
         status
         due
         plaintiff/
          opinion (true or false or freeform)
          text
          date
          history/        
         defendent/
         decision
          dup (no remedy)
       fact
        */ dup
  by-start-date/
  by-end-date/
  search  
  
/announce
 /auto
  [plugin]
   */
 /chair
  */
 /tribune
  */
 /finance
  term
  comment

  income/
   total
   comment
   class/
    */
   transactions/
    by-date/
     */
      by-class/ dup
      by-id/ dup
    by-class/ dup
    by-id/
     party
     authorizer/
      */ (mb multiple ppl had to sign off)
     amount
     class
     date
     comment
     [plugin]
  expenses/ dup
  netIncome

  cashFlow/
   netCashFlow
   class/
    */
     amount
     comment
   comment 

  balanceSheet/
   asset/
    comment
    class/
     */
      amount
    asset/
     */
      value
      comment
      uri (link to asset management URI)
   liability/ dup
   equity/  (omitted for groups w/o equity)
 
  retainedEarnings
   ?
 
  [plugin]



/news


/document
 /act
 /policy
  /by-id
  /by-class
   bylaws/
   foundRight/
    */
   majorContract/
    */ (whatever policy classes have been created)
    misc/
   ordinary/
    (whatever policy classes have been created)
    misc/
     */
 /otherDocument

/asset
 /software
  /self
   repo/
    hg
  [plugin]
 [plugin]




/history/date/
 (same API, but looks in archive, if available)


Types of software-executable acts

officials

documents (including policies)

classes

cases

portfolios

configuration

users

emergency

assets

software

other assets

[plugin]

other

[plugin]



If you contact us or members of our team, your message may be posted to the public mailing list; also, you waive any intellectual property rights to any content or ideas in your email.


plugins: py-notify or trellis? PEAK's plugin? plugins dependency management, packaging? plugins should themselves be able to have plugins should mb do it "the django way" as much as possible use of WSGI? can separate web services be plugins? use Parliament? glossary: "extension points" components w/ 1st-class interfaces (zope.interface -- which can be used w/o C) plugin registry: PEAK's hook? grok's martian (adds additional level of indirection) w/ a simple dictionary (or w/ PEAK's hook)? ZCA (note: would have to use that patch that makes it C-independent)?

answers so far: py-notify or trellis? py-notify PEAK's Plugin? yes plugins dependency management, packaging? no plugins should themselves be able to have plugins -- enabled by PEAK's Plugin should mb do it "the django way" as much as possible: todo: learn Dj use of WSGI between components? yes, sometimes can separate web services be plugins? no -- security boundary to preserve secret ballot use Parliament? no, tight integration with Django and GAE datastore glossary: "extension points" components w/ 1st-class interfaces (zope.interface): no registry: martian

acCore:

submitPatch acceptPatch rejectPatch listPendingPatches getPendingPatch executeShellCommand updateDirectory getVersionControlSystemInfo getVersionControlInfo getAmendableCodeVersion (event listeners)

ac core2:

runTests replaceProductionVersion replaceBackupVersion executeShellCommand registerEventListener deregisterEventListener

add to parliament:

addMember(id, role, attrib) removeMember listMembers( filter = None) castVote(member, uri, value) # public/private in URI scheme # "vote" is very general isVoteURIPublic(uri) getVote(member, uri) registerEventListener deregisterEventListener

use py-notify


could institutionalize the Linux model where there is only one committer, but many trusted lieutenants:

https://github.com/WordPress/book/blob/master/Content/Part%203/13-development-in-a-funnel.md

contrast this with Github's seemingly more egalitarian model, where every programming employee is encouraged to deploy a change whenever (given that it has been reviewed by some others, etc), and are shown how to soon after they are hired. (i think Facebook has something like that too). However imo these might work because the implicit hierarchy of the corporate structure is still there; that is to say, if senior lead devs get mad at what someone else is committing, that other person had better comply or they will be out of a job (and at that point lose commit access)

i guess if Contributor Logic goes with the 'meritocracy' model then we want to have a small but slowly growing, exclusive group of committers. If we go with the current governance model, then committ access would be bestowed or removed at the sole will of the elected manager of that product/project.

another note:

" One of the major issues was around the style of governance in the project. Many weren’t happy with the BDFL model. A BDFL governance model is common in free software projects. Notable BDFLs are Linus Torvalds of Linux and Rasmus Lerdorf of PHP. A BDFL is a free software project leader - the one person who has final say about the direction and vision of a project. In reality, as a project grows there are often numerous people who have an influence and who make decisions about project direction.

Rich Bowen, one of the developers who was dissatisfied with how WordPress? was run, came from the Apache project. Apache has a committee model. The committee is made of up both developers and non-developers, all of whom have a say in the running of the project. Unlike WordPress?, which only require that commits be approved by the committer and/or the patch reviewer, commits in Apache require a consensus. Habari launched with a committee structure, much like Apache. Decisions are made by committee consensus.

...

Michael undertook a redesign of the Habari interface, which he says now was both a good and a bad experience. He had a good experience designing it, a bad experience getting it approved, and a good experience implementing it. The bad experience was down to Habari's committee structure. A lot of time was spent discussing approving the new admin interface. People with no design background weighed in with opinions and their voice was given equal credence. For Michael, this left him feeling that he couldn't get his work done and he ended up leaving Habari. When asked about whether he is more comfortable with a BDFL or Apache-style model, he says now:

    It’s easy to end up in very long discussions if everybody has equal footing. And that makes for a great democracy, but it’s also very hippie, 60s, everybody gets to sit around and share their opinion, but that’s not always something that’s really worthwhile. You don’t actually, necessarily, get a better product out of it. And so often you need somebody with vision, or at least somebody with a point of view with opinion to weigh in.

Another flashpoint was around the issue of commit access. In the Apache project, there was a clear path to get commit access to the repository. In WordPress? in early 2006, getting commit access was not possible for most people. It would not be opening up soon, and definitely not to the number of people who wanted it. Only Matt and Ryan Boren had commit access to WordPress?, themselves constituting a funnel and checking mechanism through which all the code would run. More committers were eventually added, but it was a slow process and one that led to frustration, particularly amongst prolific contributors.

Coming from Apache, Rich brought a different perspective to the project, one that chimed with the more dissatisfied developers. For Rich, WordPress? didn’t constitute a true meritocracy - there was no opportunity for those with ability to gain power and responsibility. The final decision over who did and didn’t get power and authority lay with the project’s leader - it was down to his discretion to determine who had ability and deserved power. When Matt, in a discussion thread, says that WordPress? is a meritocracy because commit access is provided to "the best of the best of the best contributors who prove their worth over time with high quality code, responsiveness to the community, and reliability in crunch times,” Rich responds by pointing out that because the final decision lies with the BDFL it prevents the community from becoming a true meritocracy.

What lay at the heart of the discussion was a fundamental disagreement about how a free software project should be structured. In Homesteading the Noosphere Eric Raymond discusses project structures and ownership, looking at how a project structure emerges over time. The emergence of WordPress?' project structure very much follows what Raymond outlines - the project has a single owner/maintainer, or in the case of WordPress? it had two - Mike Little and Matt Mullenweg. Over time, Matt assumed leadership of the project. As more and more contributors were attracted to the project those that were active were given commit access. In WordPress?' case, commit access carried with it an implicit level of authority. Those with commit access are the arbiters of the code that ends up in core. Matt made clear on a number of occasions that he didn't "want it to be a status thing," but this didn't prevent it from becoming so.

He posted to the mailing list in 2005 saying "Committing != community status. It simply is a way to ensure that all the code that goes into the core is reviewed before being distributed to the world.” But community members naturally ascribe authority to those with commit access. People with commit access are trusted above others. There was nothing clear and prescribed about what it meant to be a committer or a lead developer. Instead, the roles developed organically and, for the community, authority naturally followed commit access to the repository, and commit access followed high quality code submissions along with an understanding and commitment to the project ethos. Commit is a symbol of trust; with only two committers it appeared that the project leads did not trust others in the community.

This had another impact on the project: a lack of acknowledgement for non-code contributions. Because implied authority naturally followed code it meant that there were no defined leadership roles within the project for non-coders. Commit access may have been given out sparingly to developers but authority and leadership was still in theory achievable to anyone who could write code. For those whose role was helping on the support forums, writing documentation, providing translations, or any of the myriad supporting activities that go on around software development, there was no formal way for those who worked hard and demonstrated a commitment to the project to progress, gain status, or be acknowledged. While coders receive props for code accepted into core, there was no system of acknowledgement for those who work on supporting activities. So when there were rumblings of discontent, it wasn’t just coders who were complaining.

Habari’s approach was the opposite of WordPress?. Commit access was achievable by anyone. The Habari motivations page says "Our contribution model is a meritocracy. If you contribute code regularly, you will be granted permission to make contributions directly (commit access).” The project takes this approach even further - it isn’t just coders who received commit access. Owen Winkler, one of Habari’s founders says:

    There are some people who are committers, who are part of the primary management committee in Habari who I would never want to actually touch the code because they don’t really do development. But we give them access to it because they’ve demonstrated that they’re part of the community and they’re actively trying to advance Habari as a project.

In Habari, commit access is a clear sign of trust and responsibility in the project. In a project in which commit access = responsibility and authority, it makes sense to give access to anyone who holds such a position within the project. However, if you're trying to create a project in which the two do not go hand-in-hand, keeping commit access as purely a checking mechanism makes sense. That said, if it’s not clear to people within the project what constitutes authority and what doesn't, and having a commit access is one of the few indicators of authority that there is.

There were disagreements that went beyond those of governance and commit access. WordPress? has always been user-focused. This means ensuring that the software works for as many people as possible on as many environments as possible. As a result, decisions are made that don’t make developers happy. From the start, questions were asked about whether WordPress? would be rewritten. Because it wasn’t rewritten, developers have to deal a lot of technical debt.

WordPress?' focus has always been on users, and maintaining a good experience for them. Habari, on the other hand, was intended to be useful to users, but at its heart it is an educational tool for developers. One of the driving ideas behind Habari was to create a tool that taught people about development, development best practices, and being part of a free software project. Rich Bowen, who did't know a lot of PHP, said that he hoped that the new project would teach him about it. This meant not just teaching developers about PHP, but educating them about best practices around coding methods and being part of a FOSS community. They eschewed WordPress?' low barrier to entry in favor of an approach that would cultivate fewer developers but better developers.

In a post announcing the Habari Project, Scott Merrill writes about how one of the founding principals behind Habari is to make it fully object-oriented.

    This has resulted in some wonderfully efficient code, and so far the system is remarkably fast. Object oriented programming allows us to streamline the development of user-created plugins; allows us to integrate a unified error handling system; and vastly simplifies the construction of our Application Programming Interface.

Habari was written in PHP 5.1, giving developers access to PHP Data Objects. This gave them a level of database independence lacking in WordPress?.

WordPress? is focused on users. It’s important that changes to the software don’t break a user’s website. The Habari project is concerned with creating an educational tool for developers. On the one hand, the Habari developers found fault with WordPress? for not using the latest coding practices, on the other, the WordPress? developers felt that Habari's approach messed with users. As Ryan Boren put it:

    Screwing users because developers want to play is not cool. It’s a good way to become irrelevant. A big reason WP is so popular is because it is not infatuated with the latest, greatest developer lust objects that require users to upgrade their platform.

In February 2007, when Ryan wrote the above comment, PHP 4 was still running on 88.44% of websites. PHP 5 adoption was slow and many web hosts didn't support it. If WordPress? had made the switch to PHP 5 it would have meant that it was suddenly unavailable on a huge number of hosts.

" -- https://github.com/WordPress/book/blob/master/Content/Part%203/24-habari.md

note: since the above was written by Wordpress guys one might expect it to be biased against Habari, even if unintentionally.

however, as of Feb 2015, Haberi development has slowed (but not stopped). There was a bugfix/maint release a few months ago but the last feature release was over a year ago and there's only a little activity on Github or on the wiki over the past year. Also, looking at their webpage: http://habariproject.org/en/ the page seems focused on the project and doesn't actually sell the product (eg explain why users should use it), and in fact their vision page only talks about what devs get out of it, not what users get out of it: http://habariproject.org/en/vision

was their problem that Wordpress simply had too much momentum? Or was it their development model and dev-focused (as opposed to user focused) community vision? Or was it that they didn't work on getting paid for this work? Or none of the above?

---

http://mxr.mozilla.org/

http://lxr.linux.no/+trees

http://sourceforge.net/projects/lxr/

--

good read: http://www.dummies.com/how-to/content/ten-roberts-rules-to-customize.html

--

rro motions chart: http://www.robertsrules.org/motions.html

--

haskell-like:

http://www.nomyx.net/

--

---

--

--

more voting software:

https://news.ycombinator.com/item?id=8411866

https://easyvoting.co/

http://www.unbaa.com/

---

related work:

http://modeling-languages.com/enabling-the-definition-and-enforcement-of-governance-rules-in-open-source-systems-slides/

http://modeling-languages.com/add-a-governance-md-file-to-all-your-oss-projects/

making the case that unclear governance (or at least, inability for projects to process patches in a timely manner and to make regular releases, or to accept patches without lots of 'politics') is a big reason why ppl dont contribute to open source projects:

the same people's projects to involve collaborative definition of DSLs:

https://github.com/SOM-Research/collaboro/blob/master/README.md http://modeling-languages.com/enabling-the-collaborative-definition-of-dsls/

---

https://forum.ethereum.org/discussion/1009/the-peoples-republic-of-doug-ethereum-based-decentralized-organization https://www.youtube.com/watch?v=oZVsIiQ1ME0 http://metagovernment.org/ https://github.com/dennismckinnon/Ethereum-Contracts/tree/master/DOUG

"DOUG will record name requested at the address of request and create a confirmation request of consensus contract. When a concensus contract has reached criteria for a successful concensus (or maybe doug will ask everytime he is called) in either case once doug recieves the go ahead he will make the swap (this involves changing the address located at name).

Doug is a Decentralized Organization Upgrade Guy. His purpose is to serve a recursive register fo r contracts belonging to a DAO s other contracts can find out whi ch addresses to reference withou hardcoding. It also allows any c contract to be swapped out inclu ding DOUG himself"

https://eng.erisindustries.com/smart%20contracts/2014/12/17/dennys-smart-contracting/ https://eng.erisindustries.com/ http://eris.academy/view/doug

https://consensys.net/ventures/spokes/ BoardRoom? boardroom.to

BoardRoom? is a next-generation organization governance apparatus that enables decentralized decision making on the blockchain. BoardRoom? integrates organizations’ managerial and decision making structures. Directors of the governing Board may be proposed for appointment or removal. Existing Directors vote on such proposals. Other proposals related to any aspect of governance may be tabled and voted on. If pass, a proposition can activate “middle-ware” which links to other decentralized applications on Ethereum or other mechanisms to execute the details of the passed proposal. For example, an organization can create a proposal to start a crowdfunding campaign, issue tokens as assets, and delegate equity shares. Middle-ware which sets up the details required to execute this proposal would be wired, with appropriate parameters to various dApps, including dApps that subserve/: -token issuance and management -token exchange -token and persona registries -wallet.

---

https://forum.ethereum.org/discussion/110/bitcongress-blockchain-based-voting-system

---

https://www.reddit.com/r/ethereum/comments/3wrlc0/game_subethanomic/

---

another voting app:

http://debate.futuristparty.org/

---