On Thu, Mar 14, 2013 at 7:03 AM, Peter Koželj <[email protected]> wrote:
> There has been several requests from our mentors to be less ticket savvy. > > While I do not agree that our BH should be used for bug tracking > exclusively > (Jira and similar have served me as planning tools quite successfully in > the past), > I can see some room to relax our process a bit. > > There is on thing that I would like to suggest if we are going that way: > > Every (or almost every) commit or patch should also include a modification > to RELEASE_NOTES (ticket based or not). > There should be no need to preoccupy release manager with what was done, > what the status is and so forth. > When the release date comes, it should be trivial for release manager to > get the release notes > into consistent and presentable state. > > Disclaimer: I am not suggesting that we retire our issue tracker. > Bloodhound needs to eat it's own dog food after all. Hi Peter, I'll try to explain my thinking on this. I'm asking myself, what is the value of tickets and release notes for the developers and for our users? Let me describe two experiences. The Trac project has been around for a while now, so users are running a wide range of versions, and a typical user is not running the latest version. Fairly often, a user will report an issue on the mailing list or in a ticket and that issue will have been resolved already in an existing or upcoming release. When I find that ticket, I want to be able to immediately see what release the issue has been resolved in, therefore I find value in a properly-set milestone field. Sometimes I will see a new feature or change that I may not like. Rather than possibly rehashing this immediately on the mailing list, I've found it useful to be able to review the ticket in which the change was made and see the considerations and decision making that led to the change. In contrast, I've found a RELEASE_NOTES file //with very detailed changes// to be tedious to manage and not all that useful in imparting information about the changes that were made. However, I really like what the Trac project has done via a //Release Notes// field in their tickets, and generation of a Release Notes page using wiki macros (1). I worked with the Trac devs on many tickets for the last release, and found this process to be low overhead. So I suppose I would be in favor of following the "Trac process" of release notes generation, or being very relaxes in our processes leading up to 1.0, but I don't think that managing a RELEASE_NOTES file will be better than either of the other two options. My contrasting experience is, that I worked the past few years on a team of 4 developers and we followed the "Trac process" to create the release notes. This was for a medical devices, so there will never be any end users reviewing our release notes - they were for developers and internal company use only. Following the "Trac process" of release notes generation fulfilled some regulatory requirements, but aside from that, I did not see much value in it, and had this not been a regulated product, I wouldn't have put the effort into producing detailed release notes. I mentioned because, at the current stage in Bloodhound development, we may have more in common with that medical device project than we have with the Trac project. My conclusion is - Of course time spent managing tickets must be small, and there should be minimal overhead for developers and release managers. What I'm hearing from you and others points to that being the goal of everyone. The Bloodhound project does not have many releases yet, few to zero users and a manageable number of tickets. While establishing our process and good practices early on can pay off down the road, we have to weigh that against work that will be incurred, and it may not be worth making much change to our process and being more careful, organized and detailed until we get to release 1.0. Given that, I'd favor continuing to do what we do now, with a small and concise RELEASE_NOTES file, but developers should update that file when they make major changes, so that the release manager manager's responsibility is limited to reviewing the file and making sure nothing big has been overlooked. Once we get a user base established, I'd favor moving to something like the "Trac process" of release notes generation. Anyway, I apologize for the lengthy reply, but I wanted to explain why I think a bit of organization is good at the appropriate phase of a project. I hope we can rapidly reach a conclusion on what the community feels is best, and I will try not to say much more on the subject. (1) http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/1.0
