You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's not always clear how to report tech related issues. Often times mental notes are taken, akin to "this code needs refactoring", or they're written in code review but without further action taken.
Going down these unstructured routes leads to these issues being forgotten.
I don't think we should define a process here, but give some suggestions for what can be done.
The easiest might be adding #TODO notes as and when these issues are found, and periodically takes some time to go scouting.
Another suggestion might be, for more dire situations, exposing a trello board with all the tech related issues, so it can be seemlessly mixed in with sprints.
Regardless of the approach, the aim is to make sure tech debt is always exposed
The text was updated successfully, but these errors were encountered:
# TODO would also be very easy to measure and keep track of the count. It also doesn't depend on a specific service.
One of our customer projects has a TODO.md file in the root of the repo. Perhaps this file could be required, and that contains what the preferred option or process is for the project. Either the file itself contains a list of items, or just states that code has been marked with # TODO items throughout the project.
It's not always clear how to report tech related issues. Often times mental notes are taken, akin to "this code needs refactoring", or they're written in code review but without further action taken.
Going down these unstructured routes leads to these issues being forgotten.
I don't think we should define a process here, but give some suggestions for what can be done.
The easiest might be adding
#TODO
notes as and when these issues are found, and periodically takes some time to go scouting.Another suggestion might be, for more dire situations, exposing a trello board with all the tech related issues, so it can be seemlessly mixed in with sprints.
Regardless of the approach, the aim is to make sure tech debt is always exposed
The text was updated successfully, but these errors were encountered: