-
Notifications
You must be signed in to change notification settings - Fork 61
Penalty & Blame For Broken Features #758
Comments
/start |
Too many assigned issues, you have reached your max of 2 |
@pavlovcik I'd love to take this.
|
@Keyrxng The time limit for this bounty is on Wed, 20 Sep 2023 20:28:01 UTC |
|
Hands down! Alright leave it with me, appreciated dude |
Thanks for your enthusiasm |
Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment |
It doesn't pick up on drafts yet so please add an update here @Keyrxng |
draft pushed with requested changes to make: 30-50% complete |
Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment |
should be about ready for review later tonight |
Do you have any updates @Keyrxng? If you would like to release the bounty back to the DevPool, please comment |
@Keyrxng - Releasing the bounty back to dev pool because the allocated duration already ended! |
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:
In the Future
Originally posted by @seprintour in #260 (comment)
The text was updated successfully, but these errors were encountered: