Collecting data on repetitive requests for more generic implementations of patterns/components
Problem
Implementing these patterns/components in a more generic way often requires knowledge upfront about effort VS availability, or will introduce scope creep into other issues.
Further information
This issue came up during the UX weekly call
Usecase
We might want to think of a way to keep ourselves informed across the different product area’s on patterns/components that are implemented or not implemented on a case by case basis, but should be implemented in a more generic way.
Implementing these patterns/components in a more generic way often requires knowledge upfront about effort VS availability, or will introduce scope creep into other issues.
Data helps us to get this scheduled and lets us be pro-active
Proposal
Let's track the following data:
- How many times have we come across it?
- Where did we come across it?
- Why was there decided against implementing it at that point in time?
Let's track this data through making use of:
- Epics?
- Related issues?
- Labels?
- Manually in the description?
- ?
Make a rule like:
- If we come across a pattern 3 times. This should be scheduled and implemented next release. The release after that we must fix known ~"technical debt" and UX debt.