Monitoring: Better reports

[amyjko]

A question I would like the chapter to answer is how to train people to produce reliable, precise information for failure reproduction. I feel like the chapter skims through this part in the chapter and makes it sounds like “it is what it is”. I wish that the chapter would go into details about how we can change this behavior, where maybe the chapter focuses on how changing feedback questions will help user better explain bugs and give them guides on how to list the steps to reproduce the issue.

I thought this chapter was insightful and started off really well with Amy’s personal story, as it made me want to keep reading. As a Windows user, I’ve seen the error reporting feature quite often, especially when applications randomly close or crash. Prior to reading this chapter, I always thought that if users submitted an error report, it would be useful to the engineers or developers if they read it so that they have an idea of what the problem is. The reason I never submitted one is because the problem is usually fixed when I relaunch the application or I felt that if I did submit one, it would be overwhelming to those reading it since I imagine they already get enough reports. After learning that these reports need far more detail than what is provided, and because there isn’t enough detail for the team to figure out exactly what the problem is, I wonder why Windows still has the feature. Is it because even though they won’t know the exact problem, developing teams might still have an idea? If large companies such as Microsoft have teams dedicated to reading these reports, how do they interpret the feedback the users have if it is not specific enough? These are a couple questions I had that I would like the chapter to answer, but overall, this was a fairly interesting chapter.