Since the beginning, we’ve always avoided allowing this capability. We felt it went counter to how a bug tracking workflow should work. The problem we had with other bug tracking tools was that there was never an automatic assumption being made between the state of the issue and who should be working on that issue.
So, if John assigned a bug to Jane, and Jane had a question, she’d have to ask the question, potentially change the state of the issue (“Missing information”) and then re-assign the issue back to John. Our gripe was that the application should let John know he needs to respond to Jane’s question before she could continue working on it. With DoneDone, changing the status of the issue also determines who acts on it next.
Our worry was people would just assume they had to keep re-assigning the issue back to the creator if they had a question, or wanted the bug to be tested, etc. when this is not the case. The issue statuses determine who should act next.
Many of you, by emailing us, tweeting, or posting on our forum on GetSatisfaction, came up with some valid use cases where it really would help if we simply allowed the feature. Zak posted a couple of great examples on GetSatisfaction, where assigning an issue back to the creator makes complete sense:
Developer-A creates a bug and assigns it to Dev-B. Dev-B decides she doesn’t have time for it and wants to assign it back to Dev-A (who is perfectly capable of fixing the bug himself).
And another: Dev-A creates a bug and assigns it to himself. After making progress he gets stuck and decides Dev-B should take over. Then, after staring at the code for 5 minutes, Dev-A finds the solution and kindly asks Dev-B to assign it back to him.
….Currently this restraint seems to do nothing but punish developers for taking initiative and logging their bugs as they find and fix them.
After enough internal debate, we’ve finally decided to allow this feature. If you are the issue creator, issue resolver, or an admin, you can re-assign any issue back to the person who created it. In the case where an open issue is in a state other than “In Progress”, or “Ready for Next Release” the issue goes back to the “Open” state – self-assigned issues can only be in those two states.
We hope you find this new addition helpful, and understand why it took us so long to get it in. Thanks for your continued support!