AKipman proposes a very interesting idea. He says:
“Lastly *I think we should be posting check-in mails* and I will be doing so in the future. I already do so internally every time we post an LKG (last known good) to our internal partners, and I will be posting the same list externally when we ship the beta of Whidbey. I think this is the single most valuable information a developer can have when he/she are trying to figure out what the delta is since the last technology preview, alpha etc. What has changed? What are the breaking changes? What are the new features I should be pounding on? I strongly recommend this to any feature team, as this is one piece of information our customers have to *discover* by trial and error, and this would give them a clear roadmap of
- what to look forward to,
- what to play with first and
- prepare them for what will break since the last time we did this.
I have to say that I agree with him totally on this. Specifically what I want is:
- Our bug databases should be made available online to the public. Both for viewing bugs and reporting new ones
- Check-in mails for bug fixes should then be made available publicly when we hit the milestones that we release to publicly
- Faster release cycle so that these fixes can be rolled out to quicker
- Information about whether the bug has an active test running full time to prevent regressions so that everyone knows that this issue will be caught if it comes up again
This would provide a very tight loop between us and the users directly using our products. It would help improve the quality of the product and would allow customers to make an informed choice as to whether they should be downloading this new release or not.
Another thing that I think this would help with is the propensity for developers to send out a check-in mail that says “fixed some bugs”. These summaries drive me nuts because they give me very little information. Attached with the mail will be the list of bugs fixed and the code that is changed, so I can usually grok what’s happened. However, it’s also the case that there are way to many bugs fixed and far too much code changed and you end up going “i don’t really understand why we were broken before and I’m not really sure why we’re fixed now”. What’s worse is that if, in the future, you get another bug similar to the one that was fixed you won’t make the mental connection between the two and you won’t know who to talk to and you won’t know all the details involved.
I tried very hard on my check-in mails to explain what was fixed and what the problem was. I usually try to consider the fact that there are developers, QA and PMs (along with other interested parties) who will be reading it. So I try to address what the problem was (usually through a simple example of its symtoms), what actually caused it, how it was fixed, why i believe that the fix is correct, and how I think we should work to make sure that this doesn’t regress (for example, more focus on testing a certain area of the code). Of course, sometimes I get lazy and don’t go that much in depth, but I do try my best.
I do this because I know people are going to be reading these and I know that this information will be useful to some of those out there. I think that the realization that now these reports are going to be read by a lot of people will motivate people to try harder in this regard. I also think it will help improve the quality of the code. I’ll explain why. During the process of drafting these mails I’ve been forced to think deeply about the issue so that I could explain it well enough for everyone to understand. While doing that I’ll suddenly realize “hey! damn, i forgot about something” or “waitaminute… what about this case… I don’t think that will be fixed”. This actually happened today, and because of it I ended up doing 3 iterations over the code until I ended up with something that I felt was write because I could explain in depth what the original problem was and why my solution fixed it completely. If I had just written “fixed issue blah” or “fixed some bugs” I would never have realized that I wasn’t truly fixing the issue, I was just fixing the symptoms that were presented in the bug reports, while not fixing a whole host of other ways for the bug to manifest itself.
Are these kind of interactions useful, or desirable to external customers?