Status issue curation and communication by bounties about swarms HOT 18 CLOSED

@oskarth @tiabc @andytudhope @pablanopete My vision on the bounty process in the core team. So, any core team member can submit a proposal. Text as it's explained to the core team member (developer, tester):

1. If we have something to delegate to the contributors - we can do this
2. Issue for the bounty should satisfy these conditions:

• we are ok to wait undefined time for the PR
• it's described in a good enough way, so external contributor can understand. If it's a bug then there are clear steps to reproduce, actual and expected results. In case of status-react project - there is a link to TestFairy session with logs/video
• we have clear acceptance criteria: how do we check that it's done?
• we can estimate its complexity in XS, S, M, L or XL style (XS - tiny issue to fix, XL - lots of research and work to be done). Most of the time we will use S, M and L labels.

3. If you have such issue (or will create one) then tag it with a

• label "Ready for bounty check"
• label of complexity

4. At least 2 more team members agree we need it. Comment or +1 in the issue from extra 2 team members are OK. ? Need leads to approve too?
5. As soon as it's done you can just wait or ping in the Slack channel 10-ob-bounties with issue number. As a result, Anna or someone else from the "Bounty curation team" (see #10 ) will add a label and send SNT tokens to it.
6. Please, do not add label "bounty" on your own - it will result in 0 bounty shown to the contributors, so "Bounty curation team" will make sure that issue is listed and gets SNT almost in the same time.

from swarms.

Perfect, will make that a reality, thank you for the suggestions @oskarth - inspiring as always 😉

We have 11 bounty issues in status-react and 5 in status-go, so don't really need that assumption - can just start with the real numbers. Otherwise, the rest sounds good. Particularly like the part of tracking recurring contributors (though it seems like most of these so far are falling down further into core contributor positions).

from swarms.

Hi @oskarth! I am happy to lead this if everyone else is OK with that. I think Anna might want to focus on QA, and only devote the time Testing & Evaluation requires here. That said, if I am wrong, it's worth noting that Anna is more experienced than me and currently has deeper insight into the issues in status-react and status-go, so would make a better lead if she does want to take point.
Would be an awesome way for me to learn more about the code-base and sharpen my own clojure and go skills!

from swarms.

Have there been progress to this? We seem to be running out of PR's for people externally to be involved in, but I doubt it's because we don't have work to do.

from swarms.

(a) Curation of issues. I can do it + communication and coordination with a core team, so we understand the SOB mechanism and have more and more bounty issues with minimal administration effort on top of this. Guess 10 hrs per week might be enough
(b) - assumed it's external developers who contribute - suggest @andytudhope can do this in close cooperation with SOB team and me

from swarms.

@andytudhope @annadanchenko Cool, go for it! Do you want to setup channel etc? As a dev would like to have clarity in what specifically I can do to get other people to do specific pieces of work I know need to be done but they don't have to be done by me.

I think it'd also be good if we have 1-2 devs from both Clojure and Go team who can help @annadanchenko select issues, especially since a bunch of these might be technical and not necessarily user-focused.

from swarms.

Very happy to help with this initiative as well @oskarth @annadanchenko @andytudhope

from swarms.

OK, so Anna, Hutch and I will collaborate on this. @oskarth and @tiabc will help just a few hours a week to curate the best issues for bounty following O's outline above (particular w.r.t time-critical issues that should rather be solved by core contributors).

Anna has devoted 10 hours/week to curating correct issues with the team.
I will devote 10 hours/week to ensuring communication with all devs, capturing their details and following up in GH and Riot. Hutch will support these efforts, though has not yet detailed a time commitment. Suggest one call per week to identify bounty issues that are not being attempted and try to figure out why, to discuss issues under review, and generally keep on top of things.

Most of the initial processes are set up, but far too manual. @pablanopete it would be really great to see if we can automate the contributor spreadsheet. @oskarth is there not just a way to pull this stuff (GH username, email if available, website etc.) directly from the SOB backend? We already have the analytics from there to assess accurately the two stated goals:

monthly active contributors
daily transacting users (of SNT)

and would be nice to see if we can enrich that, or just make it more accessible to the team.

from swarms.

is there not just a way to pull this stuff (GH username, email if available, website etc.) directly from the SOB backend?

@andytudhope I believe we have a bunch of this data available, yes. If you give me a list of the data you think would be useful I'll see what I can dig up later this week. Some (website) might require some additional work but I suspect basics (username, issue, payout) can fairly easily be dumped from DB. We can then create a cron job to send report of this on a weekly basis, say.

from swarms.

I can devote at least ~10 HR PW as well to communication with devs / followup and spreadsheet curation.
~5 HR PW to issue curation after discussion with @annadanchenko @andytudhope and definition of issue criteria

from swarms.

1. Let's specify concrete names for bounty sizes, say: bounty-size-XL? Are there any borders between sizes? If we don't have them, the estimations will be pretty subjective and approximate.
2. Can we change the issue size on the go in case it had been expected to take little time but turned out to be really complex?
3. Do we have any written instructions for assigning bounties except for this comment? If not, let's create it. If yes, let's add missing parts there.
4. I'm in the bounty curation team. What steps shall I follow to send SNTs to the issue?
5. Let's rename Ready for bounty check to something like bounty-awaiting-approval or awaiting-bounty-approval or awaiting-bounty-check or anything else consistent with other labels format?

from swarms.

6. I don't think we need any lead approval. We're striving to a scalable and consensus-based team so the lead's position becomes sort of deprecated, as I can see. Also, we don't want leads to be a bottleneck and distract to stuff like that.

from swarms.

Clarification on distinction between this swarm and SOB:

1. SOB is a separate division/team with goals to have devs and organizations in general. This would still exist even if Status wasn't a consumer of SOB.

2. This swarm is about Status as a consumer of SOB. Even if SOB didn't exist Status would still benefit from a bounty program like Gitcoin.

from swarms.

@naghdy so this is definitely something we need to work on as it is the one part of our process that we can't directly control - we require the devs in either status-react or status-go to move issues into the appropriate column in their ZenHub boards (Bounty-Check in status-react, Goteam stil needs to make one) so that we can review them, edit the issue for clarity and prepare it for bounty. We require some input from the devs themselves though - I have been trying to encourage both teams to submit smaller/time consuming but not hard issues, or break down current ones into simpler tasks, but have not had much luck with that.

from swarms.

@andytudhope As I said a week or two ago, we need clear metrics and graphics that illustrate this on a regular basis, otherwise it is too vague.

The iteration goals are still tasks, not actually goals in terms of % growth of bounty issues / contributors. To me this is the main task of the swarm leader. I'd be happy to assist.

from swarms.

Concrete suggestions for metrics

1. 10% week over week over growth in available issues for all Status repos, as well as in status-go and status-react independently. Assume 10 issues first week. Do this for 3 months and we are at 30x, then re-evaluate since we might hit on financial limits.

2. 10% week over week growth in new contributors for all Status repos, as well as in status-go and status-react independently. After 1 month of real tracking introduce 3rd metric which measures and grows recurring contributors.

Get this data for last few weeks. Plot it over a timeline. Plaster it all over #general on a weekly basis. This achieves three things:

(a) communicate success
(b) clarifies deficiencies, e.g. this repo failed to meet growth target this week - why and how do we fix?
(c) forces automation naturally, e.g. instead of "automate" or "bounty all issues" at once we can gradually introduce processes that actually solve bottlenecks.

To me this is the proper way of setting targets and it shouldn't take too much time, it just requires someone to do it regularly.

They also tie directly into the metrics mentioned in org paper.

@andytudhope @annadanchenko

from swarms.

Those metrics seem solid, this is great to see.

Thanks @andytudhope and @oskarth for driving this.

from swarms.

This swarm has now been closed and absorbed into OpenBounties itself, specifically #59.

You can read the full report here: https://github.com/orgs/status-im/teams/status/discussions/9

from swarms.