#### Presenter: Mayank

#### Topic: Architecture Tech Debt


#### Date & time: 11/18 11:41

#### Notes

How can we make tech debt sustainable?
How can we manage tech debt in a sustainable way?

We should do what we can to allow people to track their on stuff.
No need to come up with a strict to force people but provide tools to make it easier to understand the ROI for fixing it.

We should have a way to track code through specific functionality.

An effort to continuous triage bugs and making it easier to prioritize things so the issues are not sitting around
forever and bugs are becoming stale. Is there an advantage to marking things as tech debt vs priority help wanted? Why 
is a specific delineation such as tech debt important.

Tech debt = stuff we are creating ourselves whether its taking a shortcut or not covering all the test cases in the code 
for example. This could be because we are targeting the wrong set of use cases.

Cron job is an example where we didn't really address the use cases. People wanted it to work the way cron jobs works, 
but we don't want to do it how cron works. Tech debt is self-induced.


#### Key Learning / Takeaways

- See [doc](https://docs.google.com/document/d/151EF619SoQMo0_LJsJjEThTxAC5CuXWXtgFpqNbvuDc/edit#heading=h.jvkwmmv9y2rh)

#### Action Items
- Refine the definition of tech debt, need to come up with 3-4 concrete things that define what tech debt is and how they 
are defined in the pipeline. Define the tech debt process
- Identify a solid crisp way to identify and flag issues
- Process of identifying and catching the tech debt being introduced

