One of the constant debates while I’ve been programming has been that of how to organise work. Are bugs different to blueprints?
I’ve been mulling over a new tracker for a while (just because none of the ones out there /really/ fit me) and was thinking about this angle over the weekend.
Defects/bugs/crash reports/blueprints/specs all share two common themes: firstly they are associated with a delta between someones desired behaviour of the code, and the actual code. Secondly, they may represent a commitment to actually enact that change, but such a commitment is not a guaranteed feature of any of these things. One can write a specification and fail to get consensus and agreement on it in the community. The presence of a bug report is not agreement that the thing is wrong.
I think tasks then are a good place to factor out such commitments – they probably want to be linked to the reason for the task, design documents, crash data etc. A number of projects I’ve been involved with have used Kanban boards to manage their work in progress – essentially each card on the board is a task, not a bug/spec/etc/etc.
Another interesting thing about considering the resulting task as a separate thing is that it provides an understandable boundary between ‘my view’ and ‘your view’ for scheduling work on a shared codebase. E.g. consider a codebase with many drivers such as Neutron. One organisation may care a great deal about the driver for switch vendor X. Another may care about vendor Y – they likely won’t both be considering bugs in the other drivers to be of equal importance. So priority or importance is only understandable in the context of a single organisation, whereas something like impact is relevant in the context of users. Users can probably be partitioned up too – users that use driver X will naturally be much more impacted by issues within driver X – but users generally are not as heavy consumers of project trackers as developers are.
I’ve no final conclusion to draw here yet, just starting a discussion on it :)
