From b26db5e5cb17faad3925dd8e2499dc54efb90aca Mon Sep 17 00:00:00 2001 From: Oskar Thoren Date: Mon, 16 Apr 2018 10:41:40 +0800 Subject: [PATCH] 120: Add artifact doc and update README with pointer --- README.md | 2 +- .../README.md} | 7 +- .../permission-less-and-compensated-work.md | 78 +++++++++++++++++++ 3 files changed, 82 insertions(+), 5 deletions(-) rename ideas/{120-swarm-process.md => 120-swarm-process/README.md} (97%) create mode 100644 ideas/120-swarm-process/permission-less-and-compensated-work.md diff --git a/README.md b/README.md index 94f5b91..5527477 100644 --- a/README.md +++ b/README.md @@ -33,7 +33,7 @@ aborted. | Idea | State | Success metrics? | Exit criteria? | Clear roles? | Future iteration? | |---------------------------------------------------------------------|---------------------------|------------------------|------------------------|------------------------|------------------------| | [127-sob-testing](ideas/127-SOB-testing-process.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | -| [120-swarm-process](ideas/120-swarm-process.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | +| [120-swarm-process](ideas/120-swarm-process/README.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [121-swarm-compensation](ideas/121-swarm-compensation/) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [92-disc-v5-research](ideas/92-disc-v5-research.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | | [87-new-protocol](ideas/87-new-protocol.md) | :walking_man: In Progress | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | :white_check_mark: Yes | diff --git a/ideas/120-swarm-process.md b/ideas/120-swarm-process/README.md similarity index 97% rename from ideas/120-swarm-process.md rename to ideas/120-swarm-process/README.md index 62da54f..1bb76ff 100644 --- a/ideas/120-swarm-process.md +++ b/ideas/120-swarm-process/README.md @@ -36,6 +36,9 @@ this. - Possibly UX for communicating things during Town Hall, etc. ## Product Overview + +**UPDATE: Our thinking on this matter has evolved, see [Permission-less and compensated work at Status](permission-less-and-compensated-work.md) for more** + There are two constraints that govern how this structure is designed and cultivated. One is that Status the company wants to ship a product, and the other is creating a decentralized autonomous organization. Since we are moving @@ -127,10 +130,6 @@ Description: ### Iteration 3 (Buffer) -Possibly something related to Type-1 swarms and communication thereof, but to me -once success metric 3 is achieved this is a slightly different focus and thus -ideally a different swarm. - ## Success Metrics Three primary success metrics. diff --git a/ideas/120-swarm-process/permission-less-and-compensated-work.md b/ideas/120-swarm-process/permission-less-and-compensated-work.md new file mode 100644 index 0000000..7a69dcd --- /dev/null +++ b/ideas/120-swarm-process/permission-less-and-compensated-work.md @@ -0,0 +1,78 @@ +## Background +This document outlines the development and participation of contributors to +Status. In particular we have found: As an open source organisation, we should +improve and further incentivize community involvement and development Status, +where people feel comfortable working on whatever they want There are Core +Contributors [CC] at Status who are paid salaries to solve particular problems. + +The purpose of the document is to help core contributors understand how Status +currently organizes swarms (and their shortcomings) and steps towards improving +this process. + +## Swarms: permission-less and compensated work within Status + +Suppose Person A is undertaking a task, and Person B is funding it. Who should +be evaluating Person A's work? + +Naturally it makes sense for Person B to, as they are assuming the risk, though +they might choose to delegate this responsibility to a trusted person. + +### Current Model + +In our case, Carl and Jarrad (major SNT holders) are to a large extent +delegating funding of work through Nabil (COO) and, by further extension, Status +core contributors. Decision making is done by core contributors. This makes up +the 'main Status entity', which is currently a form of 'DAO 0.5'. + +So how do we currently want to evaluate work? As an entity, we can choose to +delegate this evaluation to paid core contributors as swarm leads (trusted +model). Additionally, we can choose to require PM/UX/Eng representation for +user-facing swarms, as well as a minimum of three contributors per swarm. These +are evaluation and funding mechanisms we can choose to adapt and formalize, +where 'contributor time' is a form of funding mechanism, as salary compensation +is decoupled from the swarm process. + +### Shortcomings +One shortcoming of this is it does not support funding from other SNT holder and +the wider community. The evaluation and funding mechanism for this could be +improved/adapted. Similarly, requiring specific roles or minimum contributor +count is an arbitrary restriction that isn't desirable as a general compensation +mechanism for getting work done. Example: lone hacker in middle of nowhere doing +something that is a public good in Status and a funder believes they are able to +execute on by themselves. Specifically what other forms of evaluation and +funding mechanisms we want to make easy is something that we will find out as +time goes on, largely through SOB and its experiments. + +What happens with work that doesn't fall neatly within existing categories?? It +depends on the nature of it. It might be completely isolated from the core app, +e.g. in the form of organizing meetups, writing content, developing a dapp that +doesn't require coordination with main code base, etc. If it does involve +changes in the core app, there's a selection mechanism where we can choose to +accept or deny such work (example: pull requests in status-react). Since we are +open source, in case of strong disagreement, one could imagine a fork and +alternative app artifact being distributed. But in the 99% case it would be in +the interest of the swarm, as well as its funder, that this work gets into the +core app. One could look at Status Core Contributors as custodians of the core +app, and this swarm would likely need to coordinate with CCs to ensure their +work has impact. + +### Where to go from here? + +1. Acknowledge that: + +a) We will experiment with Swarm evaluation and funding mechanisms (both time +and money) + +b) Swarms experiments won't be restricted by constraints outlined below in [2] + +c) To the extent experiments are successful, this might impact below constraints + +2. Encode the following evaluation and funding mechanism for salaried core +contributors: + +a) Delegate evaluation of swarm's performance to core contributors in a swarm +(evaluation process still tbd) + +b) Require PM/UX/Eng contributors for user-facing swarms + +c) Require a minimum of three core contributors per swarm