[OPEN-ILS-DEV] Bug tracking (was: 1.6RC1 - Acquistions - possiblebugs)

[Wills,Steve]

Q/A is something every enterprise can benefit from and an effort that
core developers tend to not to do well simply because they are too
intimate with the code they are writing.  Personally, I HATE code
reviews because no matter how smart I am, there is always another way
and um... a fudged branch..and um.. a typo... and um... blah blah.  So
we all get that.

In many efforts I've been involved with, Q/A is a required stop on the
way to full dev status.

If we open Ticket editing to a wider community, how do we filter noise
and differentiate between bug reports and requests for training?  I'm
sure half my "bug reports" are the latter :)

Steve

p.s.
Dan Asks: " If every commit message was tied to a
ticket with three pages of description, which fell into a roadmap with
precisely adjusted dates, with perfectly synchronized code styles and
unit tests for every method, but the resulting process encumbered the
developers so much that we were only able to make half as much progress
towards the development of new features, would that be a desirable
outcome?"

The Answer: Of course, but only if the three pages of description are in
DocBook format! ((a little DIG there ;) ))