currently, our verified users are determined by these factors:
sms_verification = true and e.grant_contribution_amount > 1000 then 'verified'
1 makes sense to me as it tells us that you're willing to be "verified" or "identified" by SMS means, and that you're serious about funding open source. The only feedback here is we can figure out the best cut-off threshold for the grant contribution amount and how we want to divvy it up between rounds, or of all time.
bounty_work_submits >= 3 or y.hack_work_submits >= 3 or q.bounty_earnings > 1000 then 'verified'
If you've done at least three bounties with us, hackathon or otherwise, or have earned more than $1000 in winnings or work completed, then you're verified. Again, we can modify the threshold numbers as we see fit.
hack_winner_kudos_received >= 1 or kudos_sends >= 10 or kudos_receives >= 20 then 'verified'
I might rethink this criteria. Winning a hack would be the biggest signal here, and less so on how many kudos you've sent or recieved. Even winning a hack doesn't automatically make you necessarily a good developer, communicator, and non-flaky engager, but it's more likely. This criteria I'm lukewarm on.
action_points >= 500 then 'verified'
where action worth is assigned like this:
values
('Visit', 0),
('Login', 1),
('played_quest', 2),
('updated_avatar', 1),
('new_grant_contribution', 3),
('receive_kudos', 1),
('joined', 1),
('unknown_event', 0),
('beat_quest', 3),
('start_work', 3),
('bounty_abandonment_warning', 0),
('new_bounty', 5),
('new_kudos', 3),
('work_submitted', 4),
('Logout', 0),
('new_tip', 2),
('worker_applied', 2),
('send_tip', 2),
('status_update', 1),
('stop_work', 0),
('work_done', 5),
('silent_status_update', 1),
('hackathon_registration', 3),
('worker_approved', 2),
('update_grant', 1),
('killed_bounty', 0),
('wall_post', 1),
('leaderboard_rank', 0),
('bounty_abandonment_escalation_to_mods', 0),
('receive_tip', 0),
('bounty_changed', 0),
('extend_expiration', 0),
('new_grant', 3),
('new_grant_subscription', 3),
('bounty_removed_by_funder', 0),
('created_kudos', 2),
('increased_bounty', 0),
('bounty_removed_by_staff', 0),
('account_disconnected', 0),
('new_crowdfund', 0),
('created_quest', 2),
('worker_rejected', 0),
('mini_clr_payout', 0),
('killed_grant_contribution', 0),
('hackathon_new_hacker', 3),
('consolidated_leaderboard_rank', 0),
('bounty_removed_slashed_by_staff', 0),
('added_slack_integration', 0),
('killed_grant', 0),
('flagged_grant', 0),
('increase_payout', 0),
('negative_contribution', 0),
('removed_slack_integration', 0),
('consolidated_mini_clr_payout', 0),
('bounty_abandonment_final', 0),
('worker_paid', 3),
('noop', 0)
) as f (action, action_worth)
I think this criteria is fine, this might be more appropriate for users on our platform that might not be developers and are just engaging frequently with builders.
- how can we better capture non-earners but folks who still are contributing and engaged in the space aside from actions?
- are there any gaping holes in our thinking of this simple verification model?
- is this a good start, and where does the puck go on this?
- what's the next viable step on building this into our product?
- I recommend we manually do this first.
- agree on the criterion
- manually start verifying folks on our platform (maybe a bulk verify tool)