Browse Source

Tweaks to about.md, added two new templates and edited elected_board.md

Nathan Schneider 5 years ago
parent
commit
9a22508a71
4 changed files with 50 additions and 10 deletions
  1. 20 0
      _create/benevolent_dictator.md
  2. 8 8
      _create/elected_board.md
  3. 19 0
      _create/self-appointed_board.md
  4. 3 2
      about.md

+ 20 - 0
_create/benevolent_dictator.md

@@ -0,0 +1,20 @@
+---
+layout: create
+title: Benevolent dictator
+permalink: /create/benevolent-dictator/
+
+community-name: 
+mission:
+values:
+structure: One community member, the benevolent dictator for life (BDFL), holds ultimate decision-making power while seeking to represent a balance of the views and the best interests of the community as a whole.
+membership:
+removal: The BDFL can remove misbehaving members at will for the sake of the common good.
+decisions: The BDFL sets the community's policies and makes decisions for the community, taking reasonable account of input from other community members.
+deliberation: Community members are free to discuss and debate community policies, practices, and culture.
+implementation: The BDFL is responsible for implementing—or delegating implementation of—policies and other decisions.
+oversight: If members are not happy with the BDFL's leadership, they are free to voice their concerns or leave the community.
+limits: In the event that the BDFL is unable or unwilling to continue leadership, the BDFL may appoint a new BDFL or choose to alter the governance structure entirely.
+rights: 
+agreements: 
+evolution: The BDFL can change the governance structure of the community at will.
+---

+ 8 - 8
_create/elected_board.md

@@ -1,19 +1,19 @@
 ---
 layout: create
-title: "Elected board"
+title: Elected board
 permalink: /create/elected-board/
 
 name:
 mission:
 values:
-structure: "An annually elected board determines policies and implements them."
+structure: An annually elected board of no more than 5 members determines policies and implements them.
 membership:
 removal:
-decisions: "Each year, on $DATE, members vote on nominees for board positions. The 5 nominees with the largest number of votes become board members for the subsequent year. Current board members propose and vote on agreements by a secret ballot. At least 51% of board members must vote to approve a proposal in order for it to become an agreement."
-implementation: "Board members or their designees should have access to the means to implement the rules that the board has passed."
-oversight: "Community members unhappy with the board's implementation with the agreements may seek to replace board members at the next election."
-limits: "Board members can serve an unlimited number of 1-year terms."
-rights: "The board is expected to operate according to this Rule and the explicit agreements it has created."
+decisions: Each year, on $DATE, members vote on nominees for board positions. The 5 nominees with the largest number of votes become board members for the subsequent year. Current board members propose and vote on agreements by a secret ballot. At least 51% of board members must vote to approve a proposal in order for it to become a community agreement.
+implementation: Board members or their designees are responsible for implementing agreements, and the board should have access to the means to implement the agreements that it has approved.
+oversight: Community members unhappy with the board's implementation with the agreements may seek to replace board members at the next election.
+limits: Board members can serve an unlimited number of 1-year terms.
+rights: The board is expected to operate according to this Rule and the explicit agreements it has created.
 agreements:
-evolution: "Changes to this Rule require 51% of the board to approve a referendum circulated to the entire community. The change passes if it receives 2/3 approval of all who vote after $NUMBER days."
+evolution: Changes to this Rule require 51% of the board to approve a referendum circulated to the entire community. The change passes if it receives 2/3 approval of all who vote after $NUMBER days.
 ---

+ 19 - 0
_create/self-appointed_board.md

@@ -0,0 +1,19 @@
+---
+layout: create
+title: Self-appointed board
+permalink: /create/self-appointed-board/
+
+name:
+mission:
+values:
+structure: An annually self-appointed board of no more than 5 members determines policies and implements them.
+membership:
+removal:
+decisions: Each year, on $DATE, current board members elect the board members for the subsequent year. At least 51% of board members must vote to approve a proposal in order for it to become a community agreement.
+implementation: Board members or their designees are responsible for implementing agreements, and the board should have access to the means to implement the agreements that it has approved.
+oversight: Community members unhappy with the board's implementation with the agreements may voice their concerns to individual board members or in the community at large.
+limits: Board members can serve an unlimited number of 1-year terms.
+rights: The board is expected to operate according to this Rule and the explicit agreements it has created.
+agreements:
+evolution: Changes to this Rule require 2/3 approval of the board.
+---

+ 3 - 2
about.md

@@ -8,7 +8,6 @@ Too many of our communities, especially online, adopt default governance practic
 
 This is a very preliminary prototype. The eventual purpose is to do for governance what the [Contributor Covenant](https://www.contributor-covenant.org/) has done for shared norms—enable simple, drag-and-drop adoption of common-sense community tools. Since communities have diverse governance needs, however, a one-size-fits-all approach will not suffice. The goal is for communities to easily and intuitively design governance systems appropriate to their contexts.
 
-
 ## Contribute
 
 Contribute via Issues and Merge Requests [on GitLab](https://gitlab.com/medlabboulder/communityrule).
@@ -44,7 +43,9 @@ Contribute via Issues and Merge Requests [on GitLab](https://gitlab.com/medlabbo
 
 ## Design goals
 
-* Compatibility with Loomio
+* Further modularity
+    - In _modules, develop pseudocode primitives and complex modules with inputs, outputs, and actions
+* Compatibility with Loomio?
     - Translate each module into Loomio practices, implicitly or explicitly (e.g., time for a proposal, threshold, voting options)
 * Module system with database
     - JavaScript pulling from GDocs?