Investigating Tickets Workflow

This is the general train of thought I try to follow when I’m looking at something unfamiliar. This will be updated and refined as needed.

1. What is the request?

This is a good point to ask the ticket author for clarifying requirements, instructions for how to reproduce the bug, and providing actual vs. expected results.

2. If it’s a bug, can you reproduce it?

We need to eliminate the possibility that it’s not a ”It works on my machine” scenario.

3. Trace the flow of data

a. What data is currently available to you? To the component?

b. How can you use the currently available data to solve the problem?

c. What do you need to change? Are major changes involved?

d. Of the available data,

• What can I safely add / remove / change?
• Can I add / remove / change the data itself?
• Can I / should I add/remove/change an existing data structure?
• Can I (at least partially) solve the problem by creating separate lists or dictionaries of data? (ex. all data vs. filtered data)

4. Are there existing tools / techniques / function helpers that you can use?

Once you have a better understanding of the issue, check if someone may have already encountered this scenario and wrote a fix that you can adapt.

Keep in mind:

• Look for patterns
• Note what techniques you may need to use
• Write down your thought process and the things you’ve tried
• In the original ticket, take notes of your findings. It is always better to overcommunicate
• You may need more context from another developer