[TriLUG] Issue Tracking

Roadrunner mamiano at nc.rr.com
Thu Nov 8 19:13:38 EST 2012


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.

Sent from my iPad

On Nov 8, 2012, at 5:08 PM, Brandon Van Every <bvanevery at gmail.com> wrote:

> On Thu, Nov 8, 2012 at 4:45 PM, Brian McCullough <bdmc at buadh-brath.com>wrote:
> 
>> 
>> Because of the wide variation in user types, the UI needs to be simple.
>> Even us techy types can appreciate that.
> 
> I've used Trac and Mantis plenty of times to file bugs / features for other
> people's open source projects.  There's nothing wrong with their UIs; they
> work.  Trying to "simplify" these UIs is overthinking things.  You pick
> stuff from drop-down menus, that's about it.  People who claim to be
> "non-technical" must be forced to do a proper QA drill if it's within their
> area of responsibility.  This includes submitting information in all fields
> so that it's actually useful, and providing steps to reproduce the problem.
> Such issues are cultural and cannot be solved by "simpler" UIs.  In
> volunteer open source culture, techies who do not do all the steps are
> yelled at, until they start doing the right thing.  This is normal and open
> source culture doesn't work if techies don't internalize the need to carry
> their own weight.
> 
> For non-techs who are *not* responsible for filing bugs, you may wish to
> have a mailing list or web form interface that goes into some database
> somewhere and notifies various people.  I have no experience with this.
> All of the open source projects I've watched over the years have typically
> abandoned such interfaces, because volunteer open source works best when
> people are flogged into providing useful bug reports.  But if you have
> associates or customers who aren't paid to write good bug reports / feature
> requests, then simply communicating with them by fairly standard means,
> i.e. email, to hold their hands and get something useful out of them, may
> serve you better.
> 
> Some companies have a culture where they put all their TODO items in a bug
> tracker.  Others use wikis, chat, email, or face-to-face meetings.  Getting
> people to pay attention, monitor, and respond to any method of
> dissemination, and getting everyone using *the same* method of
> dissemination, is a challenging managerial problem.  No technology will
> solve the problem for you.  In particular, as a bug tracker fills up, a
> huge backlog develops.  Even when triaged, people are going to tune out
> some of that, because trying to actually deal with all bugs / features in a
> tracker would lead most human beings to despair.  Managerially, you might
> be better off limiting the flow of TODO information to a simple stream of
> emails - and don't send out so many emails!  If people have hundreds of
> emails in their Inboxes every day, as the hive mind of the Microsoft campus
> once had (I'm told secondhand), people will ignore them.
> 
> In addition to Trac and Mantis, Bugzilla seems popular and I doubt it's
> lacking anything.  Pick one and just do it.
> 
> 
> Cheers,
> Brandon Van Every
> -- 
> This message was sent to: Mitch Amiano <mamiano at nc.rr.com>
> To unsubscribe, send a blank message to trilug-leave at trilug.org from that address.
> TriLUG mailing list : http://www.trilug.org/mailman/listinfo/trilug
> Unsubscribe or edit options on the web    : http://www.trilug.org/mailman/options/trilug/mamiano%40nc.rr.com
> TriLUG FAQ          : http://www.trilug.org/wiki/Frequently_Asked_Questions



More information about the TriLUG mailing list