Decentralised OKRs for 2018 Q3

At Status, we have been using Objectives and Key Results to define our roadmap. Now, we want to begin decentralising that process.

We created our first OKRs together, in person, in Bangkok. This time, we want to do it remotely, and using the most innovative governance tools available. The fun begins next week, starting on the 18th June 2018.

You can get involved in two ways:

  1. 18th to 23rd June: There is a template at the bottom of this post you can use to create your own O or KR (or both). Just comment on this thread or start your own one using the “OKR” category label. Please add (with motivation) what you think are the most important features that Status should work on in Q3.
  2. 26th to 30th June: Vote on the most important features using Status surveys in Aragon’s brand new app. Anyone who holds SNT can get involved in the voting. Just head here.

We’re excited to get the entire Status community involved in defining our roadmap. See below for more information on what OKRs are, how voting will work, and more. Huge thanks to the Aragon team and Brett Sun for helping us set this all up!

                                     . . .

There are some very important things to note about the whole process in general:

  1. This is an experiment. It is about getting our community used to using tools on chain and figuring out whether strong signalling mechanisms that require at least some skin in the game and some willingness to pay gas fees will work going forward.
  2. All of this voting is happening on the main network, so any fees you need to pay to vote will be in real ETH.
  3. Status is not bound by the votes, we are using this as a means to poll the community in an interesting and novel fashion that requires a lot of participation.
  4. Voting in Aragon still requires a MetaMask account, so we need people to move some SNT to an accessible address before next week. Don’t move everything you own, just a few SNT should suffice to make sure that you can register your considered opinion, which is what we are really interested in getting insight into.
  5. SNT are not locked by voting - so you can use all the SNT in your wallet to vote on each and every survey you care about. Each vote just takes into account how many tokens you had at the block before the vote was created.

What are OKRs?

All Status core contributors are strongly encouraged to take part in the process as before. However, we’d like to offer the wider community the chance to submit their own Objectives or Key Results that they think we should be focussed on and justify why, using a short template we have created and our new research forum: https://discuss.status.im.

Here are some useful definitions, from this open deck:

OBJECTIVES

Are Ambitious, Uncomfortable, Qualitative.

For example, “Make Status the most active open source crypto project” or “Create the best DApp experiences for users and developers using Status” or “Make Status the world’s most secure decentralised messenger”.

KEY RESULTS

Are Quantitative and Measurable.

For example, “Increase monthly active contributors by 20%” or “Sponsor 3 Ethereum meetups around the world”.

The voting process

Aragon’s Survey App allows us to organise all the Objectives (qualitative stuff) with associated Key Results (quantitative stuff) and put them into separate surveys per Objective. Anyone who holds SNT in a MetaMask account 1 block before the survey in question began can then vote on the Key Results associated with each Objective.

To repeat: each Objective is created as its own survey. People can then vote on Key Results for the Objectives they care about and ignore the others. We use the specific results under each Objective to determine priority Key results from P0 to P5. Then, we look at the total number of votes for all Key Results under each Objective to identify and prioritise the most popular Objectives overall.

You can see a good example of how this will look in the “Ship Beta 1” survey already set up - which is an OKR we put together for Q1 2018.

This is the process in detail:

  1. Go to https://discuss.status.im, find the topic of the team under which you’d like to submit either an Objective, or some Key Results, or both.
    1. Each team has their own topic in the forum, clearly marked, so give a little thought as to which team your desires are most relevant to. If you don’t know, just post your submission in Core.
  2. Using the template provided in the first post, submit your thoughts, or simply comment on submissions by others with improvements or suggestions.
  3. Good submissions will become surveys using Aragon, where you can then use your SNT to vote for the most relevant Os and KRs associated with them.
  4. Make sure you have some small amount of SNT in a MetaMask account that also has a little bit of ETH to pay fees, before the 25th of June 2018.
  5. We take the feedback from all the submissions and votes and use it to refine our OKRs.
  6. We will then reflect on this process to improve future iterations of our own DAO and decentralised, open source development process.

OKR template

Please post the OKR in the following format. If you can’t fill everything out perfectly that’s fine, but the more details the better!

Objective: XXX
Key Result(s): XXX
Notes: XXX

Example

Objective: Improve utility of the wallet
Key Result(s): Support exchanging one token for another (e.g. ETH ↔ SNT)
Notes: Right now the wallet can’t do much with the existing tokens

Let’s get this ball rolling:

Objective: Proper light client support / trust-less transaction support
KR: LES enabled as option with up to date CHT and decent performance (TODO: Quantify)
KR: ULC added as option in our app
(KR: Get other people to support ULC nodes (Upstream merge / docs and dappnodes? / quantify number of nodes?)

From Status.app this would partly answer

secure transactions
open and decentralized systems?
and resistant to bad actors?

As we currently trust a third party (Infura). It also seems likely we are currently failing the following litmus test:

User with $1M in ETH trust Status?

and this would partly help remedy that.

Also see:

2 Likes

Objective: Incentive running of Whisper nodes aka paid master nodes

From https://ideas.status.im/ideas/168-paid-master-nodes/README:
KR: Users running mail servers and transacting. Target: 10
KR: Users paying for a mail server. Target: 50% of D7 retained users, or 20% of all users.
KR: Daily Transacting Users. Target: 35 ((5000 DAU TARGET*0.2 TX%)/30 PAY-MONTHLY).

KR: Stretch: implement model not just for master nodes but for other Whisper nodes.

Comments: The current proposal in 168 is a bit naive. Dmitry S and Ricardo had some interesting ideas for using a sub accounting system that’s similar to s^3 but simpler. Essentially paying for effective data delivery, and each node being able to punish the other by disconnecting them. While Swarm s^3 is probably a more thought-out incentive system, it isn’t ready yet and too much to do in a reasonable timeframe. This topic is probably worth its own thread, with a cryptoeconomic analysis and everything, but better to put something down on paper for now.

There’s also some overlap with https://ideas.status.im/ideas/280-discoverable-trusted-server-nodes/README and https://ideas.status.im/ideas/086-push-notif-v2/README

From Status.app this would partly answer these points:

open and decentralized systems?
that are properly incentivized?
and resistant to bad actors?

users as stakeholders?
a thriving ecosystem of contributors?

If all our servers disappeared tomorrow, how could Status still operate?

2 Likes

Looking at slack stats, suggestion for an OKR, get DM’s/Private communications down and public communications up Slack

Going to be handy for when we move onto Status Desktop

2 Likes

Objective: External teams can rely on Status dev tools

KR: New developer docs site is live with 3 sections complete
KR: A new developer can follow the Build Status quick start to set up Status in 20 minutes or less
KR: 2x external teams using an extension

Comments: This objective can possibly be broken into multiple. There are two layers:

  1. Improve usability of tools with great documentation and easy install
  2. Build more tools—help developers build for mobile, optimise for Status and improve their DApps

Building out the developer experience is imperative. A more advanced/long-term version of this objective might be: Status is a recognized platform for web3 development.

2 Likes

I’m feeling excited to see this use case :grinning: Please let us (a/k/a Aragon :eagle:) know if there’s anything else we can do to help make this happen :+1:

1 Like

Objective: Create an amazing experience of Status at DevCon

KR: 100+ people engage in the experience
KR: 15+ positive Tweets about the experience
KR: +80 repo forks or +100 stars (for example)

Comments: The idea is to enable a scenario at DevCon that:

  • Showcases the power of extensions to superpower DApps
  • Leverages core functionalities of Status to connect people
  • Works in context of the conference

Starter ideas:

  • A build on WhoPays that allows groups to split expenses at DevCon with a smart contract
  • Use of a proof of location platform for a scavenger hunt on-site
  • Interactive DApp gameplay, e.g. a live game of Crypto Against Humanity with prizes claimable by QR code

We can build a DApp for this internally but will consider external partners as plan A.

Objective : Make Status the safest chat platform

KR: A middle-man with access to the private keys required to decrypt a message cannot decrypt the whole conversation (0% success rate)
KR: 100% of online users are offered an automatic update within 5 minutes of a hotfix release being made available in case of a known security flaw.
(other KRs welcome)

1 Like

Objective : Increase engagement in chat

KR: Increase chat daily active users by 500% (currently at < 400 DAUs)
KR: X public messages exchanged per week per user (TBD)
KR: Y private messages exchanged per week per user (TBD)

1 Like

P2P Team OKRs (proposal)

Objective: Improve decentralization and trust

KR: LES and/or ULC are operational and used by at least 10% of all users.
KR: Mail Servers are discoverable in less than 5 seconds.
KR: A new discovery protocol is created that provides latency under 1 second to find a minimal set of peers and consumes less than 10 kB.

There are two swarms:

Objective: Protect users from spam and DDoS

KR: Implement at least one countermeasure against the simple network spam and/or DDoS attack. Messaging should be working and latency should not increase by more than 50% over 10 minutes. (TBD: examples of simple attacks)

Objective: Keep being the part of Ethereum network

KR: Server nodes should use the same Discovery protocol as the whole Ethereum network (they might use another discovery protocol along as well).
KR: Mobile clients discovery protocol traffic and latency are not increased.

Notes: This might be required for LES/ULC work.

2 Likes

Objective: Implement basic security practices in Status development
Key Result(s):

  • Implement an ad-hoc security review process for the core teams;
  • Introduce DevSecOps practices for infrastructure teams;
  • Create a group of people interesting in security who will be kept up-to-date with infosec and DevSecOps practices;
  • Conduct security training for all developers.

Notes: Right not we are fully dependent on external security audit, but we want to be safe in between the audits as well.

3 Likes

For me, the OKR’s should probably come after a discussion of what we’d like to accomplish generally in the next time-period. This joint discussion can serve as a conceptual tool to discuss measuring what success means.

To me it seems mixing measurable metrics while pitching objectives increases coordination costs.

2 Likes

May I suggest we setup a open an SNT carbonvote poll or topic democracy where anyone can add ideas that are on our minds, then allow any SNT holder to vote on it as the beginning basis for this discussion

Very timely and to-the-point comment. I was going to post something about this when I saw your comments :slight_smile:

I think people may have gotten the idea that we need to post only fully-baked OKRs in this thread (I know I did at first), and that is not the intention. The reason why the Q2 OKR meetings were productive is that the barrier to entry was pretty low (we started by throwing around some keywords, and then built it up until we got to actual objectives and only then to the KRs).
I think we need to keep the barrier to entry as low as possible so as to collect as much feedback as we can. Right now it would be super helpful even to just have some rough objectives posted here that we can later aggregate into a poll/carbonvote.
The fact that the gathering phase coincided with the rush to beta probably isn’t helping, since everyone will prioritize working on beta launch over thinking about Q3 OKRs.

1 Like

It is a bit hard to put it into OKR structure but as we are releasing beta, we need to have better tools to test backward compatibility of Status app and server nodes.

We should also create a fully parametrized build that can take a commit/branch of status-go and status-react, build required pieces and finally output the app for iOS and Android.

This could be a part of an objective to improve developers and testers day-to-day work or our CI pipeline.

This is how I envision our CI/CD working if we moved to TeamCity (using TC’s “build chains”). It’s pretty straightforward to set that up once we have it running somewhere. Hopefully, now that @jasonn is onboard we’ll have the bandwidth to get this off the ground.

ENS Usernames OKRs (proposal)

Objective: Improve user experience in Status.
Objective: Increase utility of SNT.

KR: Launch on Mainnet
KR: 10% of Status messenger users register a username.

1 Like

Thanks for all the ideas everyone. To simplify the OKR process, I recommend:

  1. We put any new ideas into our Q3 spreadsheet (https://docs.google.com/spreadsheets/d/1KFnkdcitkMRAVpRM1MciK4FhO5i2_IwG3-l1P5DHdzE/edit#gid=0). For now, I’ve copied team structure’s from Q2 - but that could all change once we have our OKR’s finalised. I’ve copied all the above suggestions into the spreadsheet already.
  2. We will seed the new features into the OKR Voting DApp once we have given people enough time to fund their wallet.
  3. Sometime next week, we close the Voting DApp.
  4. Teams/groups should take the votes from the DApp, and finalise their OKR’s accordingly based on the number of votes and people voting for each feature.

The goal would be that by Monday 16th of July our Q3 OKR’s are finalised. Any questions, please come discuss in the #okr channel

1 Like