[TriLUG] Issue Tracking

[Brandon Van Every]

On Thu, Nov 8, 2012 at 7:13 PM, Roadrunner <mamiano at nc.rr.com> wrote:

> YAGNI. Having worked on several quality management systems, I once thought
> Github's issue tracker was just too stupidly simple to work. But it serves
> its role in the ecosystem well enough, without all the over the top navel
> gazing about codes and a plethora of drop-boxes that few or none actually
> care about. Of course it depends on the scope and stakeholders in the
> process - it is certainly possible to be too simple, but putting useless
> cruft in front of users is more common.


In a volunteer open source context, people can care a great deal.  Bugs
that don't have enough basic information provided, don't get worked on.
 Bugs can sit in a tracker a very long time before one of the dev leads
actually looks at it and decides to do something about it.  Open source
developers often don't have the resources to be monitoring and dealing with
the bug tracker full time.  So the memory that the tracker provides is
important - that's why it's a tracker - and the more it's filled out (what
*was* your OS?), the more likely anything is going to get done.  This is
why volunteer dev leads are fully justified in yelling at people until they
get with the program.

In a company setting, you have cash, which paves over a lot of issues.
 Cash commands people's full time attention; more people are dealing with
the bug tracker more frequently.  Sure you can skip steps, if the problem
is going to be fully dealt with in 2 days anyways and you can just pester
the guy in the cubicle next to you for whatever they didn't provide.  One
should consider the differences between face-to-face physical workers and
distributed virtual workers, before assuming YAGNI.


Cheers,
Brandon Van Every