Dev-Bounties at Status

Archive
1

Taking a retrospective look on bounties at status from the start with Status Open Bounty and now using Gitcoin as our active tool, we need a way to allow permission-less bounty posting for core contributors that want to assign an issue to a bounty but also an understanding of what we’ve done so far and what has worked vs. what hasn’t.

The good

  • Gitcoin campaign recently worked very well in terms of active contribution with 19 bounties completed so far
  • Defined issues with reasonable scope and well thought out funding scheme as well as marketing
  • Growing list of developers contributing to embark outside of core team
  • Using DAI as a stable-coin helped in terms of bounties taking much longer and fluctuations in bounty value.

The bad

  • Pushing for 60 bounties over one month was a lofty goal and unreachable for a small team
  • Bottleneck exists ad naesuem for managing and handling bounties eg. myself and @cryptowanderer
  • Ad-hoc bounties get outdated or even worse sometimes don’t work

Based on learnings so far I’m proposing that each active team that would like to “bounty the world” take on a small working group of 2-4 dedicated members who define their responsibility (Bounty deployer, payout guy, etc.)to the cause to start a focused campaign on a set of issues they’d like to see bountied and scope out the issues for the particular set of problem / features they’d like implemented.

A really good piece of feedback that @iurimatias gave the other day is that we should consider bounties as a bit of a soft-introduction or even internship into the codebase that particular individual is working on. We should take all the feedback we get to make our code-bases easier for outside contribution through the learnings of bounties.

I believe that each new bounty campaign would require at least:

  1. Set of 4-5 issues max per initiative to exist with tags to define the bounty and proper scope for newcomer for each specific campaign, and completed before starting a new campaign with the existing bounty team.
  2. A spreadsheet like the funding scheme one above to define the scope of DAI / SNT involved
  3. Defined team members for each set of bounties to handle and confirming developer support is offered for the subset of issues.
  4. Work with finance to confirm address used for profile and funding for the specific agenda.

I’d be very happy to help anyone in getting setup with Gitcoin in terms of how it actually works for funding, deploying etc. and opening this up for further discussion and input on if everyone thinks this makes sense or any other comments; especially from @oskarth and others who have been interested in opening bounties on the desktop, nim team etc.

3 Likes
2

Creating bounties as the first tasks that people do when they join is a great idea. Similar to how some companies have people work in customer service for the first 3 weeks.

What would this practically look like? Would people be given a starter project, then split it up into bounties? What does our documentation for creating bounties look like today?

cc @anon16796968 @j12b @ceri

2 Likes
3

As it happens after chatting with @ShawnS and @ceri earlier I just today updated the content for our new “jobs” page to include a link to gitcoin bounties as a method of contribution. We could easily set up a workflow that encouraged any job applicant to pick up relevant bounties in lieu of interviews/etc.

We have also been trialling “introductory projects” as a method of contributing - which could be described as bounties without a bounty tool.

4

Our documentation for creating bounties is slightly outdated (and on our wiki) and has different implications as we use gitcoin now, but can definitely be updated and still utilize the advantages of the project board style we’ve experimented with for embark in tandem with our past Status Open Bounty docs.

Similarly we can still use the format that we’ve used possibly just separate project boards for each context of what is needed in github.

It’s open for discussion or what works best for each initiative, also this topic is just specifically for development focused bounties and am just trying to help define how core contributors, people ops etc; the biggest thing I think needed is fully fleshed our terms for individual bounties (issues) before we bounty them.

5

Wonder if this could look something like People Ops checking for a minimum number of related open bounties when hiring for a role (and linking the bounties tag from the job ad), so that candidates have the opportunity to pick up bounties in the first instance in lieu of interviews (if they choose?)

3 Likes