Consolation Prize?

[Keyrxng]

First, why?

Say someone assigns a job to themselves and carries out all of or some of the work, let's say it's an old issue and it's no longer relevant or required and just hasn't been removed/updated yet. With a very busy team and a lot of distance to cover it's possible for these scenarios to arise especially (as the codebase repeats), as things continue to grow.

What happens then?

I propose a consolation prize of sorts, what exactly that would be is definitely beyond my current understanding of things and above my paygrade to decide as well obviously.

The assignee who committed the work but through no fault of their own has had to stop due to the issue being body-bagged, should receive either a percentage of the allocated rewards or have some form of tracking in place so that if it happens on multiple occasions it can be said 'well that's n hours of work' or 'n% of the spec achieved' so you can claim 20 bucks or something along those lines.

An alternative Solution

Sign-post any new /start command with a disclaimer not to begin the work until someone has confirmed that it is still relevant and should be executed. (If this already exists and I missed it then I think it should be made clearer on DevPool onboarding docs etc)

Disclaimer

I am by no means salty or have a bitter taste in my mouth that this happened to myself, I'm glad it did actually as it has given me my first issue to raise. Looking forward to hearing your thoughts.

[Keyrxng]

Is this the correct way to do things @pavlovcik? Just open new issues, hash it out and take it from there or should it be opened as a discussion first?

[0x4007]

I propose a consolation prize of sorts

We've done this informally in the past based on how much work we see has been done with a manual payment. It's preferred to formalize the process but we couldn't think of a robust and quantitative way to determine the reward amount for partially implemented work.
Proposals:

• Perhaps we could use ChatGPT as an arbiter by passing in the pull request and the specification, while possibly also getting input from the review team. However if we didn't need to rely on the review team this process would be far more efficient.
• We can prorate based on the estimated task duration (the Time: label) and how long the bounty hunter was working on it before the plug was pulled
• In the future we plan to implement an "XP" system for leaderboards. We could issue credit for these situations which would certainly act as a form of prize that is free for us to give out.

Sign-post any new /start command with a disclaimer not to begin the work until someone has confirmed that it is still relevant and should be executed.

This could be interesting for issues that are older than X days. For example if an issue was created over 30 days ago the bot could issue a warning like this. Otherwise the more recent issues I think we would want bounty hunters to start asap!

Is this the correct way to do things @pavlovcik? Just open new issues, hash it out and take it from there or should it be opened as a discussion first?

Yeah we sort of stopped using discussions because they don't get nearly as much traction as issues for engagement.

[0x4007]

@0xcodercrane looks like the bot is down

Update: I'm using it on another repository just fine.

[0x4007]

Or is it refusing to price this issue because it was opened by an external contributor? @wannacfuture @whilefoo any ideas?

[whilefoo]

I think one of the latest merges broke the bot. I pulled the latest development branch and it's not working: ubiquity-whilefoo#52

[0x4007]

Update: I'm using it on another repository just fine.

ubiquity/sponsorships#9 (comment)

It must be the local config here at https://github.com/ubiquity/ubiquibot/blob/development/.github/ubiquibot-config.yml.

[whilefoo]

Oh it's because you are using Priority: 0 (Normal), we changed the priority number from 1 to 5.
This is also why #495 is not generating a permit, because label should be Priority: 2 (Medium) not Priority: 1 (Medium)

[0x4007]

I just changed the labels lets try again.

Looks like it didn't work. We should be throwing an error though if thats the case!

[0x4007]

@whilefoo not sure what it could be but its a pretty critical issue if we cant have bounties be priced on this repo!

[whilefoo]

yeah I'm not sure, after I fixed the labels it seems to be working on my repo: ubiquity-whilefoo#52

[0x4007]

The only relevant difference I guess is the issues' content in this repository compared to yours? We need more logs to diagnose.

[ubiquibot]

Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment /stop
Last activity time: Fri Aug 25 2023 20:28:10 GMT+0000 (Coordinated Universal Time)

[ubiquibot]

@Keyrxng - Releasing the bounty back to dev pool because the allocated duration already ended!
Last activity time: Fri Aug 25 2023 20:28:10 GMT+0000 (Coordinated Universal Time)

[Keyrxng]

/start

[ubiquibot]

Deadline	Sat, 02 Sep 2023 09:12:35 UTC
Registered Wallet	0xAe5D1F192013db889b1e2115A370aB133f359765

Tips:

• Use /wallet 0x0000...0000 if you want to update your registered payment wallet address @user.
• Be sure to open a draft pull request as soon as possible to communicate updates on your progress.
• Be sure to provide timely updates to us when requested, or you will be automatically unassigned from the bounty.

[ubiquibot]

Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment /stop
Last activity time: Sat Sep 02 2023 08:12:30 GMT+0000 (Coordinated Universal Time)

[ubiquibot]

Task Assignee Reward

[ CLAIM 18.75 WXDAI ]

0xAe5D1F192...133f359765

If you've enjoyed your experience in the DevPool, we'd appreciate your support. Follow Ubiquity on GitHub and star this repo. Your endorsement means the world to us and helps us grow!

We are excited to announce that the DevPool and UbiquiBot are now available to partners! Our ideal collaborators are globally distributed crypto-native organizations, who actively work on open source on GitHub, and excel in research & development. If you can introduce us to the repository maintainers in these types of companies, we have a special bonus in store for you!

[ubiquibot]

Task Creator Reward

Keyrxng: [ CLAIM 126.4 WXDAI ]

[whilefoo]

Task Creator Reward

Keyrxng: [ CLAIM 126.4 WXDAI ]

@pavlovcik this should've been capped to the bounty price, right? Should we invalidate the permit and do manual transaction, or just let it be this time?

[Keyrxng]

I have already claimed it but I'm happy for it to be deducted off the next bounty or whatever I'm easy either way cheers

I also wasn't aware that was the case or I wouldn't have claimed it I want to add

[0x4007]

Task Creator Reward

Keyrxng: [ CLAIM 126.4 WXDAI ]

@pavlovcik this should've been capped to the bounty price, right? Should we invalidate the permit and do manual transaction, or just let it be this time?

I really wish I had more clarity on how exactly these numbers are being calculated. This seems way, way higher than expected. We'll let it be this time. Any ideas how exactly it came to this number from the spec?

[whilefoo]

This number seems way too high, maybe we should log the calculation or display it in the comment so we can see what's going on