openwebgovernancebody

Table of Contents

Extensions
TODO
UI/X
Examples

Roles
Proposals

Lets look at some workflow
Activity streams
Terms

Built on top of a XWiki.

Any additions we need to make to XWiki would be done via creating our own Extensions (the link provides existing examples of how XWiki may be extended). Where possible we will work with existing Scripting API.

The membership/groups/roles
- via API
Login and signup
- already handled by XWiki

We program for variables, but we build the UI for this later; we test with hand coded variables. examples of "variables"

Number of stakeholders = size of body
% share of 3 groups that make up the body out of the box. It's 1/3 for each.
- Examples of this:
  - 10%/80%/10% for a more radical democracy, giving a much bigger voice to normal "people"
  - 10%/10%/80% to give a more hierarchical body, etc
Security code
Flagging
Recall threshhold
Voting time frames
etc ...

Extensions

The following need to be written up here, in programming terms, to become XWiki modules

Template: structure/workflow/templates to define variables
Signup:
Invites: methods for members to draw in others
User management:
- for creating wiki pages with user rights, user groups who can edit the wiki and lock pages
  - [Can we define "lock pages"?]
- creating/joining and leaving groups
- admin of groups
Moderation: logic for flagging
Sortition: for roles and posts
Voting: x3
User page scripting
- [Q. Can we elaborate on this a little?]
Basic security and checks
- [Q. Should this really be a separate module?!]
Filtering: Activity Streams by hashtag/category
- [Was previously not marked as "filtering" but I believe that was the intent]
User Roles: are complex and needed for money but we can leave these out of draft version to KISS
- [Q. Is this its own module or part of "User Management"?]

TODO

Get a minimum spec running
Roll it out (initially) as test installs
Build the UX up from this experience and user feedback
Loop to 2.

UI/X

Each person/page/group/role is a wiki page with:

boxes/regions for our custom Extensions
an activity stream

Examples

[The note '(variable)' appears several times below. Do you mean that these are a programmed variable, that would be configured by admin/mod/voting via each instance itself?]

A value that can change, set by #OGB template on instance creation, best edited by UI but for version one this is not needed.

A proposal is simply created by clicking on the proposal extension, that creates a wiki page that can be edited by the group that created it/or admin above. This has a voting extension. Flag. Comments. Activity stream. This page layout will be defined in the body template and can be edited (v02)
A Role/user/member has a wiki page with Flag, Comments, yes/no to lottery, Activity stream
A Group has a wiki page/s with Proposal, Flag, Comments, Activity stream
A Voice has a wiki page and admin rights for all the site, with Flag, Proposal, Comments, Activity stream

etc.

All wiki pages have a list of members, mods and admins as well as activity stream/edits.

Roles

Signed up account, has a wiki page with a lottery yes/no, activity stream, comments, flag
MOB can edit their page and any group they have joined, they can edit main/subpages (variable) on the body wiki
Group member can edit group/subpages (variable) wiki page and create prosals and vote on them
Groups/body can have roles, if they do the editing power, maybe divide by these roles
Vocies can edit any page downwards, but by "tradtion" they ask before doing this as needed
- [Am I correct that "tradition" here implies "not enforced by code"?] yep - the whole project is based on "human" trust building to solve issues, we avid hard codeing any UX or streamlining outcomes, they get to work this out themselves, though the templates can come with "example" workflows, to start them off that they can change.

Proposals

Are written as wiki pages then locked (variable) when a vote is called, they can be put to body wide, to a group, to the voices. Proposals can be commented on, and flagged.

Lets look at some workflow

A normal user is not selected for the body by sortition, but still has something to add to the process, they can write a proposal and lobby #OGB to support it, then if there is one supporter in the #OGB she/he can put to a vote body-wide. If this gets over a threshold (variable) and wins the vote then it becomes body policy.

The body would then take this directly to the voices if urgent action is needed or would repropose this to a relvent group (or create a new one) who could work more on the ideas to then vote this through. The group could act on this or they could send it to the voices as a proposal.

The voices could act on this individualy or vote a consensus to act with much more power on this issue.

Activity streams

Are key to #4opens process, every action is visible, nothing that happens in the body is left out. People can customise their views of activities (default variable).

All activities are published as ActivityPub "objects" and can be subscribed to by any ActivtyPub-compatible project/service.

In the "mythos" and "traditions" of the #OGB, working off-site is looked upon very poorly. This includes private chat groups etc. a user who is found to be pushing agendas this way should be subject to flagging and recall (variable).