Open-Media-Network
/
openwebgovernancebody
7
4
Fork 0
Code Issues 3 Pull Requests Releases Wiki Activity
Page: Tech to do list
Pages
02a. Draft Funding Application for NLNET 01. Online Governance 02 DRAFT funing NLNET 02. Tech Spec 03. The Tyranny of Stucturelessness 04. Existing Projects 99. FAQ A complementary project Corruption A grassroots social/tech project to root out/mediating the corruption in teditional vertical structers. A grassroots social tech project to root out/mediat corruption APconf outline Funding application for RIPE Home NLnet application 02 New draft funding Statements of support Stuff to look through Tech to do list The purpose and vision for our #OGB project This is how I see it, comments please? links to look through test page
45 Tech to do list
tomspost edited this page 2022-03-24 15:00:17 +00:00
Unescape Escape
Table of Contents
This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

Tech TODO

OGB Modules

Template Module

For use when starting a new OGB (Open Governance Body).

Use the existing XWiki template system to build a set of pages which cannot be accessed by non-developers. No access from the OGB users, except to clone.
Set up a basic template to understand if there is additional developent required.

Including a grpup that checks if some is a stakeholder or affiliate.

Signup Module

Login if exsiting user on the instance

  • Create new account as 'Member' (everyone):
    • may decide to only observe or take part (untick the box "take role")
    • create a personal wiki page with their activiy pub stream; to do with what they want
  • Upgrade to 'Stakeholder Member':
    • fill in questionnaire body (template)
    • a tagged activity pub message will get posted to the approval group
    • group members must each submit 'approve' or 'disapprove' (this is useing the vote modual, likly with a passive time in/out)
  • Upgrade to 'Affiliate Member':
    • Fill in questionnaire body (template)
    • a tagged activity pub message will get posted to the approval group
    • group members must each submit 'approve' or 'disapprove' (this is useing the vote modual, likly with a passive time in/out)

Invitation Module

Facilitating how members can invite new people. [Research how this currently works in Xwiki]

  • Send email
  • SMS [a pain?]
  • QR codes
  • Print Posters
  • Signup URL
  • AP event

This will aslow work for the groups, then it would be a AP event

User Management Module

  • Facilitate creation of wiki pages
    • member individuals
    • member groups
    • permissions or members/groups to edit and lock pages
  • Create groups
  • Join groups
  • Leave groups
  • Admin of groups

Moderation Module (flag module)

[Should this just be the "flagging" module - what features are required? Or does this better fit in as part of the "User Management Module" above?]

  • any page/account can be flaged, the are thresholds and create AP alertes and API actions. we call this something nice like "step back"

Sortition Module

  • Determines who gets placed in a given 'Body'
  • Runs every 10 mins
  • Looks for any space in body
  • Uses the ratios of sortition into 'Body Member' (1/3 1/3 1/3)
    • candidate for each pool are selected randomly from the candidates (who are taking part)
  • Updates the new members rolls
  • Posts to ActivityPub and alerts via email
    • [Q. How many ActPub "users"/streams will there be? One for Organisation, one per Body, one per Member?]
  • Second sortition runs to pick 'Voices' of the 'Body'
    • 3 to 5 are picked as sortated as voices (see above)
  • [add activity time outs and time limits]
  • [add group and wifi logic]

Voting

  • 3 options
  • can vote on any "proposal"
  • if it goes through, then one of the admins/mod takes the action
    • it auto announces via ActPub

Filter Module

Facilitate how hashtags and/or categories from ActivityPub messages are processed by various parts of the OGB system.
Various separate designations within OGB should be able to filter specific messages/posts. This module provides the ability for other modules to achieve this.
[Is the above an accurate interpretation?]

  • Members
  • Stakeholders
  • Affiliates
  • Body
  • Voice
  • Groups
    • Admin
    • Group Members
  • Roles

Yep, we have to deside if it is a singal actor with tags a few actors?

These need writing up:

See the Extentions section here

UI to choose templates for OGB

  • Java backend
    • [Any specific reason why Java? XWiki specific?]
  • Velocity front end
  • Used by any member to set up a new OGB XWiki instance
  • Choose from available templates
  • [Research if this functionality is in XWiki or needs developing]
  • [Hamish to define template and how differences]

NFR (Non Functional Requirments)

NFR (Non Functional Requirements)

###Development Framework Use a modem cross platform framework Deployment support for AWS Lambda, Azure Functions, and Google Cloud Functions, and others Framework examples https://www.pulumi.com/ and https://www.serverless.com/ Simple deployments and update Infrastructure as code pattern ###Development GIT Version control GIT Flow with feature branches Code review at check in All business logic and algorithms must be documented High level of automated testing coverage Developers are able to run their own deve ###Release notes Change sign off for production Zero downtime updates (using green blue pattern) ###Quality Control Dedicated QA staff Automated and manual testing Pre release testing Regression testing Active monitoring and issue alerting Dashboard to clearly see the current performance Dashboard to clearly see the current performance ###Performance High performance that scales up and down Paged data access. The UI only loads data needed to show on the current page Scaling based on partner and customer usage load Processing times for imports and exports ###Reliability 2 physical live (active/active) locations for all production infrastructure and data storage Security Encryption of all data during transmission Encryption of all data at rest (files and Databases) Use a key management system so the keys are not exposed to ops and devs Password requirements - length, special characters, expiry, recycling policies, 2FA Login / Access levels User session / Inactivity management - Durations, actions Audit table of all user driver changes so it is clear who did what Capacity High transactions per second Storage - how much data does the system need to store Year-on-year growth requirements Integrity Bad data trapping - data imports, flag and continue, stop the import policies Filtering test data from production Localization Support multiple currencies
Support multiple tax systems Support multiple delivery systems TLDs eg .de .fr Directory based eg /pt /it Disaster planning Recovery plan for systems and staff Backup of code and data - Frequency Process of restoring data and backups

Requirements

[Can we list what the key behaviours of the system should be. In part I want to be certain that a wiki is the most suitable candidate - the initial list here was taken from the end of the previous version of this document]

Function:

  • “objects” voting/consensus process/decisions
  • We need activity streams of any “object” and “action”
  • Flagging is built from the existing “objects”
  • We need “security” workflow/check “objects”
  • Lottery code (random numbers)
    • Mersene twister is probably fine
  • Groups
    • membership
      • [can one account belong to many groups?]
    • when first set up, default templates are provided (e.g. a set of "skeleton" wiki pages)

UI/X:

  • We need structure and workflow – the 3 way split with sliders [link please]
  • We need drag and drop
    • to build this structure and workflow out of democracy “objects”

Definitions

[Feel free to link to other pages if the content is already elsewhere]

  • Object: ...
  • Action: ...
  • Flagging: ...
  • ...

Development Process

  1. Choose a well maintained, open source wiki to be the base of the functionality
  2. Find a team who are skilled in the language(s), data storage and frameworks used to build the chosen wiki
    • recruit from the maintainers initially if possible
  3. Do story mapping exercise to define the features and scope and user life cycles
  4. Prioritise the stories to highlight MVP features
  5. Design initial wireframes
  6. Define/design the templates and wiki page structure needed to support the project
  7. Define the roles required to support the user features
  8. Link the roles to the page templates (who can edit what)
  9. Simplify the UI to lock down the templates from careless modifications
  10. Define the new voting module
  11. Define the automated actions on voting, flagging, and elapsed time
  12. Define the sortition feature
  13. Define the sortition actions and timings
  14. Define the activity pub output feed
  15. Define the user classification feature (e.g. use their email address or post code to classify them)
  16. Define non-functional requirements
  17. Define automated testing requirments
  18. Define git flow process
  19. Define peer code review process
  20. Finalise wireframes
  21. Design simple, accessible UI/UX and demonstarate key "hero" pages for developers
    • [Q. Can someone define hero pages, please?]
  22. Build MVP using scrum process
  23. Deploy, use, and get feedback
  24. Define Version 1 to meet key feedback
  25. Build
  26. Deploy and iterate from 23.

Why XWiki

Ideal candidate as it has active maintainers, and because it already has ActivityPub integration

Team Members

Tom Campbell Hamish Michael

Story Mapping Output (prioritised vertically - downwards)

TBD

Wireframe Diagrams

One page overview diagram of all pages

Home page

[FIX THE FOLLOWING IF NECESSARY - I GUESSED THE STRUCTURE A BIT]

Signin/signup wireframe:

  • The pages are in reverse order to the user groups
  • Voices blog first then groups pages, then body, then users
  • Side bars of voices blog items and recent activity pub feed

Functionality wireframes:

  • Voting config
  • Voting actions
  • Voting results

Build Templates

For the wiki page types

  • Voice blogs
  • Groups
  • Body
  • Other users

XWiki Modules [Draft List]

Modules

are simply blocks on the wiki pages with options

  • A front end that gives you a choice of templates (and in version 02 a way to modify them) DONE
  • propsal is tyed into the voteing
  • User roles - user, member (body), mod (group), admin(voice)
  • Body balance - stake-holder, user, affiliate
  • Voting - consensus -1 (1%) constitutional vote (⅔) and majority vote 50%
    • ^[This needs to be more clear]
  • Lottery - to fill roles
  • Basic security checks
  • Flagging
  • we need activertytpub streams on/next to wiki pages and user created activerty streams, maybe we can use tags for this?

Scripts

  • Gives rights
  • Auto create wiki pages based on roles and memberships

[Please have a look through project descriptions and update this]

Identity “objects”

[The word "identity" above is a correction from "ideantery" - please make sure it is a corrrect correction :)]

With admin access privileges.

Use the roles

Group “objects”

The content of the groups is stored in a wiki (we use an off the shelf one).

Each group has:

  • Wiki
  • Member list

Definitions

Some or all of these may already exist on other pages - can link or move elsewhere if preferable

Human

  • Body:
  • Member: are mods
  • Stakeholder:
  • Affiliate:
  • Voice: are the admins
  • Group: can have roles and can be defined by the template
  • Role: this is defend by the template
  • Admin: the is no admin, all the jobs are done by voices/mods)
  • Sortition:

Technical

  • Extension/Module: Interchangeable terms referring to XWiki Extensions
  • ActivityPub:
  • Flag: