Hi ! I've been silently skipping this kind of threads to stay out of the way , mainly because there is a big true behind the fact that some discussions we've had in the past were unnecessarily long ... even if in the long run they have served to the purpose of very-late agreement ( <ot> like in that historic moment when brane for the first time *completely agreed* with me ;) ... after some time /me insisting so hard ... </ot> )
... Ryan pulled the trigger ... :P On 3/15/13, Ryan Ollos <[email protected]> wrote: > 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. I see your point ... but from the outside and based on my experience , that would complicate things ; starting with the fact that developers will be more concentrated in writing the release notes rather than code . That is substantially different to having a custom field edited from time to time when is really necessary (e.g. once when ticket is closed) and then automatically put all such values side-by-side at release time , briefly annotated with ticket metadata thus backed up by ticket history reflecting related commits . >> When the release date comes, it should be trivial for release manager to >> get the release notes >> into consistent and presentable state. >> [...] > > > 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. > IMHO tickets (i.e. tasks + enhancements) are the concrete bridge between requirements and implementation thus acting as the minimal unit of traceability in agile software . Minimal means that e.g. it's possible to adopt heavyweight traceability and software engineering tools (e.g. IBM Rational ClearCase et al. , ... I've even written one such integration for Trac in the past ;) across the development process . As a side-note I mention that in the software projects I lead the following policies are *extremely* mandatory : - Every task has to be related to a ticket (1 ticket may enclose different tasks) - Every commit has to be bound to at least (and preferably) one ticket * with Trac this happens ootb without any effort ... * ... though it seems BH won't enjoy such pleasure in a while because a. our repository browser is in the void atm , after several months b. even after it will be working it seems it will be hard to hook into ASF repos c. ... though maybe there's a chance to make such things happen or even extend svn to match our expectations - continuous code review ... which afaict is by far much more than using the ML for such purposes - ... a few more ... long story short . In the ML there a few notable instances showing that the policy initially installed by Gary of doing something **similar** and **keep tickets focused** has been notoriously helpful . I'll add a few concrete situations that have happened in the past in this very same project : - @ryan : I could determine that #457 was related to #270 in a few minutes ... guess how : traceability - often a features is only developed up to the point it works but no further ... where does the rest go : (sub) tickets * ... which are much better than private sticky notes * ... and encourage communication across the development team , and serve as a backlog for e.g. users troubleshooting the software , new developers making their way into the project * ... otherwise we'd have to remember pending tasks like those we've created long time ago and much later turn out to be useful (e.g. #162) - Content generation * which includes the RELEASE_NOTES * ... but could support other scenarios e.g. PPMC reports * I even recall that once I translated a considerable number of RUP doc templates into wiki pages and generated a big percent of it . BTW the target organization was required to deliver all those bureaucratic artifacts every quarter or so . ... but finally I'd argue that this is neither either my team nor any other (enterprise | company | ... ) I've worked for in the past , and thereby we should stick *as much as possible* to the ASF policies and defined processes installed throughout many years , and improved along the time . We'll have to hear carefully the advices provided by persons with long experience because 1. such practices are there for a very good reason 2. we should not be swimming against the stream 3. we should encourage people to spend their time wisely Quick inline comments to express my opinion : [...] > therefore I > find value in a properly-set milestone field. + what's the dashboard view for ? > 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. + [...] > > 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. > ... I confess I've worked before in the following areas : video games (3D) , hardware design and manufacturing , hard real time control systems , hosting providers , broadcasting , research , antivirus (security ?) , social networking , finance , power generation and distribution , mining , sports , telecom , astro and geo physics (<= i.e. diversity) > > I did not see > much value in it, ... and under other circumstances, outside the ASF , I'd agree ... [...] > 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, + [...] -- Regards, Olemis.
