Penalty & Blame For Broken Features

0x4007 commented 1 year ago

Context

Sometimes features that were paid-for and implemented break in the future (for any reason.) For the bot to understand what happened, it is expected that the original issue describing the feature is re-opened.

It would be epic to see the diff from the pull request and compare it to the current working version of the code (main branch, configurable.)

Proposal

If any of the original assignee's code was changed from the time it was approved to the current production version (using diff this should be easy to see) then the blame should no longer be on the original assignee.

Instead, those who modified the lines of code since the approved commit should be blamed for breaking the feature.

In this case, the bot should:

Not apply a penalty to the original assignee and explain why.
Leave a comment on the re-opened issue and explain, in detail, which lines of code were changed, which pull requests (or at least commits) and by who (tag them in a list.)
We can let repository maintainers chase down those tagged members to see who will be responsible to fix.

In the Future

This could be an interesting place to punish the approving reviewers of those pull requests, but that will probably be part of a new specification.
We might be able to use ChatGPT to compare all those diffs and see which one is most likely to have broken the feature, then suggest that they are the assignee to fix the problem.

@pavlovcik i noticed this is a penalty.. It's been a long time since I worked on this issue

Originally posted by @seprintour in https://github.com/ubiquity/ubiquibot/issues/260#issuecomment-1715278687

Keyrxng commented 1 year ago

/start

ubiquibot[bot] commented 1 year ago

Too many assigned issues, you have reached your max of 2

Keyrxng commented 1 year ago

@pavlovcik I'd love to take this.

It's not too far off from /review
Why build up into gpt usage when it could be used now and refined?
If a non-gpt first iteration is preferred, it'd be hoping to jump onto the gpt issue so why not take on part I first

ubiquibot[bot] commented 1 year ago

@Keyrxng The time limit for this bounty is on Wed, 20 Sep 2023 20:28:01 UTC

0x4007 commented 1 year ago

No OpenAI required for the first version.
I think that non-AI features are far easier to test. So let's definitely implement without OpenAI first.
This just requires looking at who made line changes to any of the lines in the approved and merged PR. This is easy to verify without the use of an LLM.

Keyrxng commented 1 year ago

I think that non-AI features are far easier to test.

Hands down!

Alright leave it with me, appreciated dude

0x4007 commented 1 year ago

Thanks for your enthusiasm

ubiquibot[bot] commented 12 months ago

Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment /stop Last activity time: Wed Sep 13 2023 20:33:29 GMT+0000 (Coordinated Universal Time)

0x4007 commented 12 months ago

It doesn't pick up on drafts yet so please add an update here @Keyrxng

Keyrxng commented 12 months ago

draft pushed with requested changes to make: 30-50% complete

ubiquibot[bot] commented 11 months ago

Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment /stop Last activity time: Mon Sep 18 2023 07:09:45 GMT+0000 (Coordinated Universal Time)

Keyrxng commented 11 months ago

should be about ready for review later tonight

ubiquibot[bot] commented 11 months ago

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 Sep 22 2023 09:38:24 GMT+0000 (Coordinated Universal Time)

ubiquibot[bot] commented 11 months ago

@Keyrxng - Releasing the bounty back to dev pool because the allocated duration already ended! Last activity time: Fri Sep 22 2023 09:38:24 GMT+0000 (Coordinated Universal Time)

ubiquity / ubiquibot