Web: as a repo owner, i want to be able to approve people who've started work, so i can filter those who i want to work with

[owocki]

@dternyak is requesting a feature that allows the bounty issuer to approve requests for work instead of first-come. This will allow them to filter out developers who aren't a fit skillset or timing-wise

[owocki]

cc @PixelantDesign -- curious if you think this is a good idea or not

[mkosowsk]

@owocki some discussion on this topic in this ticket: https://github.com/gitcoinco/web/issues/403

I'm partial to an "Interest Expressed" approach where Developers could express interest in a given ticket and then the Bounty Issuer could chat with developers and look at their profiles to find a good fit over a certain shorter timeframe.

Think it would be best to be pretty explicit against spec work, that's a bad scene 🤔

[thelostone-mc]

@owocki That would mean the bounty hunter would have to wait until the issuer okays the request ?

• might make it harder for folks who are good but just starting out on open source
• the hunters timelines get affected, you've got a week of free time but I approve it 3 days later

Both approaches have it's de-merits

Question : Gitcoin who is our primary customer: the issuer / the hunter ?
If it is the issuer, then this approach makes sense.
If it's the hunter, then maybe not

Ideally it should be both -> but that's realistically not possible (from my experience )

[mkosowsk]

@thelostone-mc gonna have to respectfully disagree with you on this one. I think Gitcoin has two primary customers, the issuer and the hunter. I think that at any given time there could be a focus on improving the experience for one or the other but Gitcoin only succeeds in the long term if both have a good experience and a great two-sided market is developed.

I think to limit the de-merits that you list (which are definitely valid concerns) it would be best to have a short time-frame for an issuer to give his or her blessing to a hunter, I think between 1-3 days would suffice 🤔

[PixelantDesign]

@owocki

I think this is a good idea as it allows the funder to select the best candidate for the job. The risk is the timeline which is set by the funder (it'll be up to them to actively keep up with the folks that express interest and spend the time filtering candidates). Another risk would be only the best folks would get selected and folks with less experience may not get chances at some projects. This is where we will need to clearly define the experience levels (beginner, intermediate, advance so that funders have guides and contributors understand expectations). Lastly we will need to implement a very good notification strategy and system. All doable.

Another thought is that as we build out the profile feature, reputation stats could help make this process a little smoother for the project as well.

[thelostone-mc]

@mkosowsk I'm keen to see how we come up with something which benefits both.
In my limited experience I start off with the same thought and end up leaning towards one side!
The feedback I had gotten from a few folks -> identify your most important customer and build it around them. (the others are important too, just not as important)

It is possible I'm wrong but I'd seen this in many places like Uber, Paypal and so on !!

[owocki]

if i had my druthers, we'd add a bounty_work_scheme param to the Bounty object, and that bounty_work_scheme could be one of

• approved_workers_only
• any_workers

num_submitters

• 1_workers
• 2_workers
• n_submitters

competition_or_cooperative

• competitive - only 1 worker gets paid out
• cooperative -- all workers up to n from above get paid out

The submitter of the issue could designate a bounty_work_scheme when they submit the issue, and the downstream application would handle either.

[owocki]

as for how to tell someone they're not a fit for abounty:

i think letting the bounty hunter save face with the community (i.e. telling them privately) and being direct that your’e looking for someone with more X experience is the way to go.

[owocki]

moving the convo over here https://github.com/gitcoinco/web/issues/973