Recently we had a bit of confusion in Bugzilla about exactly who does what, who's responsible for what, and when it might be appropriate to circumvent someone else's priority in order to get something done more quickly. (Read: step in on someone else's bug to fix something.)
The situation: let's say that denise
writes a patch. Then afuna
comes along and commits that patch. A week later, I push it live, woo! It turns out, oh noes!, there was a bug in that code that went live. Who is responsible for fixing this?
The short and correct answer is: once code has gone live on the site and contains a bug, it is everybody's responsibility to ensure a timely fix is made.
When it comes down to it, this is a balancing act between Dreamwidth the community project and Dreamwidth the business. We spend most of our time optimizing for the former because I believe that's the right thing to do. However, from time to time, we have to make concessions in the name of the latter. (Example, I'd much rather be working on some features right now, but I need to do the payment system. Also, The review queue needs some serious work, but alas, I have to deprioritize it for a little while!)
This balancing act comes to the front again when we talk about the difference between code that is still theoretical (in Bugzilla as patches) and code that is live and available for users to interact with. As soon as code is live, I expect anybody who can step in to fix problems to do so, and I expect people who submit patches to understand that once it goes live, they lose a lot of that ownership that they are given while working on it to begin with.
I don't want people being afraid to fix bugs because of code/bug ownership or interpersonal issues -- we're all on the same team here. We're all working together to make sure this site continues to be as amazing as it has been, to keep a wonderful home for us and our friends, etc etc. This is something that is going to take people working together to accomplish, and 'this is my bug, go away' can be counter-productive to those goals in some cases.
Now, also consider that it does depend somewhat on the severity of the bug in question. If it's a minor issue (colors/font wrong, text out of place, ugly, etc) then you should ask the original author first
before you touch the bug and start fixing it. It's just polite. In this example, Denise put all her time into the original feature or fix, more than likely she feels bad that it was broken and would like the opportunity to fix it. If Afuna swoops in and fixes it, that hinders Denise's ability to learn and it doesn't let her fully resolve the issue. (If in doubt on priority, ask Denise or me -- we'll be happy to tell you.)
But, and I want to stress this again, the decision on priority is going to be one that is fuzzy. Denise may think the bug is not worth an immediate fix from someone else, but Afuna might think it is. If Afuna comes in and fixes it, then Denise might be annoyed, but Afuna did nothing wrong. If the priority was wrongly determined, feel free to point that out and discuss it, but let's avoid any anger and frustration: everybody here did the right thing and was working to the betterment of the site.
Does anybody have any thoughts on this subject? I'm happy to discuss it and try to find something that elegantly balances the priorities and needs of the project with the goals and desires of our development community.