Idea: #XX-sob-improve-onboarding
Title: OpenBounty Improved Onboarding
Status: In progress
Created: 2018-04-04


Currently users wanting to publish a bounty need to go through various manual steps, including us whitelisting them for using the platform. This step forces users to wait for us and might make them drop out of the process even if they were committed to create a bounty.

This swarm aims to remove the need for whitelisting users and revamp the onboarding flow at the same time.

Swarm Participants

Product Description

Currently all users wanting to issue a bounty need to go through a whitelisting process. This is required because we currently pay the gas for deploying the bounty contract. In order to make it easier for users to get started we should remove this whitelisting requirement, allowing users to onboard at their own speed.

There are multiple ways the need for whitelisting could be removed:

These and other alternatives will be evaluated as part of this swarm, whatever decision is taken will be documented in a Decision Record.


Iteration 1 — Concept/Design (MVP) 2018-04-20


Iteration 2 — Implementation 2018-05-10

Implement the UI for the new flows and make it functional. Once 122-sob-metrics has laid the necessary groundwork, start integrating some metrics using the tools defined by that swarm.


Iteration 3 — Cleanup 2018-05-30

Devise steps to fully migrate to new onboarding flow, refactor relevant code, delete code, clean up UI.

Exit Criteria

Success Metrics

We don’t have proper metrics for Open Bounty yet but this should affect the following:

Appendix / Notes

Token Whitelisting

Swarm Compensation Experimentse previously had issues with tokens being added to bounty contracts that have no value/are spam. While not explicitly the goal of this swarm this would be worth solving as well if it turns out to be low-hanging fruit.

repository.user_id column

Currently when users sign up and install the OpenBounty app into their repo their GitHub user_id is stored as repository.user_id. This ID is later used to look up which address should be able to confirm a payout (specified at bounty deployment).

This is later often referred to as repo_owner. This concept of a repo_owner is insufficient as it does not reflect the realities of GitHub. Multiple people should be able to publish/pay out bounties on the same repo — as they can add bounty labels.