首先 - 您希望保持您的注册非常简单，否则维护注册的开销将阻止人们使用它并浪费更多时间，而不是实际修复技术债务解决.....
如果您仍然决定继续，我建议保留一个简单的寄存器，这是一个平面文件/简单数据库/ Google电子表格，其中包含以下字段：
- 模块/组件名称
- 需要修复的内容说明（您可能有一个类别列表，但我认为这也需要一个单行文本）
- 以天计算的估计修复时间（我倾向于坚持整天，否则人们会倾向于开始记录小事）
- 哪位开发商承担了债务（并提供了修正时间估算）
- 债务发生在哪个项目上（任何暗示，哪个项目经理负责）
规则如下：
- 预计开发商对技术债务的透明度。如果开发人员因项目压力而需要承担技术债务，开发人员应将其与估计的修复时间一起添加到日志中。
- 项目经理对他们的技术债务负责（即他们是否迫使开发商采取捷径？）。他们应该能够为总债务增加提供可靠的商业理由，并提出应该采取哪些措施来解决这个问题。
- 如果没有注明技术债务，那么该代码应该具有最高质量并通过任何相关的代码审查。如果注意到技术债务，那么开发商就可以获得任何注明的“通行证”（审查可能会有助于考虑债务记录的准确性以及应该采取哪些措施来解决问题）。
- 预计开发人员会对修复时间给出合理的估计。如果他们说需要两天的时间来重构架构，那么如果他们在以后的某个时间有两天的时间来修复它，他们不应该感到惊讶....
我认为这种方法将创造一个良好的整体动态 - 开发人员有责任保持透明，并考虑如何解决技术债务，项目经理/业务主管必须做出权衡，但很明显，成本债务是他们的责任，最好的开发商和建筑师将在完成艰难的项目中获得荣誉，同时也能控制技术债务。