The debate: Should all development, including refactoring work, be accompanied by a tracking issue? (in our case, Jira)
The common ground: Our primary goal is quality. A working product, every release, is more important than anything else. Our codebase is old and automated tests are lacking; we are working on this but it's a long-term project, we need interim processes.
Position 1: Refactoring work must be tracked in Jira. If it is not obviously related to the change you are making then you must raise another issue. If you don't then the work bypasses review and testing and there is a risk to our primary goal. The argument has been made that PCI compliance (a near-future goal of the business) requires this level of tracking; I'm not in a position to say that is true or false with any level of certainty.
Position 2: Code quality is vastly important. The better it gets (to a point; a point we are nowhere near), the more likely we are to keep releasing a working product. Anything which puts a barrier, no matter how small, in the way of refactoring is a risk to our primary goal. Often, the IDE does the work for you, so it isn't likely to go wrong anyway.
The following cases have been made:
Would it satisfy both positions if a developer writes "Refactor" and the relevant revision numbers on a card? Honestly, this feels like it's going to make everyone equally unhappy. It still puts a level of resistance on doing the refactoring, but doesn't offer sufficient tracking.
What about having all-encompassing Jira issues that cover the refactoring work for an iteration? Yes, this removes the developer resistance layer, but I fear it also removes the tracking benefits of having a Jira issue. How do QA get a clear idea what to test? This seems to be a political solution, keeping everyone calm by adding in a light-weight but ultimately pointless process.
It seems to me that, given that both sides of the debate ultimately want the same thing, there should be a solution that makes everyone genuinely happy. We can't have been the first people to ask this question, so what experiences have others had in similar situations?
Best Answer
Perhaps I'm missing something here, but how does creating a ticket for work you are doing that doesn't fall within the scope of your other tickets a 'resistance layer'?
Have you recently implemented using a ticket tracking system? If so, then sit down and make your rules for using it and let the team know that they are expected to follow these rules. If this includes creating refactoring tickets for this work, so be it. You can't make exceptions early on or it could derail the whole process that your team is trying to set up.
If you've been using a ticket tracking system for a while, then I really don't understand why this would be a 'resistance layer'. Your team should already be use to having Jira open and looking at their tickets and should be comfortable making tickets.
If you wanted to keep all refactoring efforts in one place, create a main ticket for this, and have your team make tasks under it for work they are doing. Then it takes like 5 seconds for a dev to make a new task for this and they can log their time to that task.
Project managers, team leads, and developers need to know how much time is going to the refactoing effort. You don't want it to become a black hole of time. Having the tickets keeps developers accountable for their work while providing managers and leads a place to keep track of how many hour going to the effort.