that's a great question, thank you Drunken_Founder! haven't experienced something like this. because everything is public, we think that acts as a deterrence for people to do what you described. in addition, we closely keep track of bounty activity, and so if we see that a bounty has been completed (per the spec/acceptance criteria) but not rewarded for a while, we'd reach out to the maintainers to check in. if we ever determine any foul play, it's only fair and reasonable to un-feature that org from bounty discovery on Algora and suspend their use of our app.
I hope this answers your question, thank you so much for your feedback! happy to follow-up here
I suppose that even covers a more intricate case: Somebody submits a PR, lots of discussions back and forth, lots of asks from the project, finally the submitter gives up since they don't want to keep spending time on things that start diverging from the original ask. After that, the code is there, the project eventually takes the code and integrates it themselves after little work. Or a lot of extra work.
What I'm trying to say is: The line could be blurry. The PR code quality could be crap and the project really needs to invest a lot of time to make this fit for merge, in which case they rightfully refuse the bounty. But it could be that the code quality is great and they are just trying to misuse this to make people do more than they originally wanted. And the difference between those scenarios could be hard to see for somebody external. Or even for the parties involved: The project could legitimately think that the code is not of sufficient quality while the submitter could legitimately think that they satisfied the request.
Who is the arbitter? Will people tend to accept the PR anyway (silently clean up and spend time afterwords), not wanting to risk their reputation? Or will submitters tend to accept major changes, possibly beyond the original ask, not wanting to risk their reputation? Seems a bit to me like a problem also faced by Airbnb and similar services.
As a consumer, within some definition of reason, I would be ok with taking "good enough" for $200 and then just doing another $200 for more work to improve on that, as it's own new distinct job.
At these levels it's not such a concern about getting stuck with a bad job. You just don't use that developer again and the $200 didn't wipe out your company.
I've commissioned jobs like that on freelancer sites for a lot more and pretty much did the same thing. Paid someone else to rework it or reworked it myself. I wouldn't use them again, but I did still get enough of what I needed and the job got done.
I guess it goes the other way too. Let's say I'm uncommonly generous and most other consumers will be much more demanding and try to get away with whatever they can. So the same thing as a provider. You get burned by one buyer for $200, you just don't service them any more but otherwise don't worry about the chance too much.
I see. How do you prevent them from submitting another bounty though? Should you warn them that next time you will not accept a PR? I mean, the wheel otherwise just turns one more time and you are back in the same seat.
that being said, we have only had a handful of projects using OSS bounties so far so we haven't seen everything under the sun. I acknowledge what you mean by blurry lines and how/when they might occur. but as I said before, when specs/scope/acceptance-criteria are in place, it's really hard to go wrong
I hope this answers your question, thank you so much for your feedback! happy to follow-up here