Re: [sup-talk] Choosing a bug tracker for Sup

From: Nicolas Pouillard <nicolas.pouillard@gmail.com>
To: Tero Tilus <tero@tilus.net>
Cc: sup-talk <sup-talk@rubyforge.org>
Subject: Re: [sup-talk] Choosing a bug tracker for Sup
Date: Mon, 02 Nov 2009 09:46:34 +0100	[thread overview]
Message-ID: <1257150627-sup-1843@peray> (raw)
In-Reply-To: <1257143690-sup-7839@tilus.net>

Excerpts from Tero Tilus's message of Mon Nov 02 08:01:31 +0100 2009:
> Requirements collected:
>  - Store/track
>    - Formal attributes: Issue type, severity, priority, category,
>      person assigned, progress status, incriminated version and
>      platform, planned milestone/released
>    - Informal meta: Issue details, discussion, answers, attachments
>  - Web-interface (at least for issue submission, searching and displaying)
>  - Issue submission, commenting, attachments and editing attributes by email
>  - Notifications by email

Nice summary.

> Nicolas Pouillard, 2009-11-01 23:52:
> > OK lets forget Ditz[2] as an option.
> 
> Why?  (not that i have any reason why not, i've never used diz)

At least temporarily, I think it also fails at staying simple. And while
it is fun to hack that's fine but then it becomes burden and code to maintain.

> > Note also that I would make no objection to using a traditional bug
> > tracker.
> >
> > It seems that we do not find a tool we really like.
> 
> Looks like this is a issue you have discussed in depth before.  Any
> pointers to list archives?

Not really publicly, and I'm open to seeing tools I don't know.

> > A simple question I asked me was:
> >   "Do we really need to invent this (big) tool?"
> 
> Well... if somebody invented it for us already.  :)

Yes but a big tool imply development, extensions, upgrades...

> > Especially for a bug tracker we need recipes, protocols more than a
> > nice interface.
> 
> Now we are talking!  ...and when trying to choose a tool, we need to
> think about what we need it to do for us.

I would say that we need a collection of small and clear tools.

> I tried to pick the requirements you used.
> 
> > So we need a web interface for non technical users, great.
> 
> OK, this seems reasonable requirement.
> 
> > What about a pre-formatted email explained on a single web-page for
> > reporting bugs.
> ...
> > A bot will receive emails on the mailing-list and process those
> > which are in the right format.
> 
> Requirement: Bug submission by email?
> I'd say we need that.

Yes some people tend to really dislike web UIs, and while it is not
my case I prefer to keep a "by email" option anyway.

> > I think that the bot will not have a lot of information to store:
> > 
> >   (correct me if you find something else)
> > 
> >   * Issue type, severity, priority, category, person assigned,
> >     progress status, incriminated version and platform, planned
> >     milestone/released.
> > 
> >   * Issue details, discussion, answers, attachments.
> 
> This is pretty traditional.  I'd still want to challenge a bit.  Why
> do we need severity and priority?  What would they be used for?

I don't say that we need all of those, that the flexibility point.

The configuration will be something like:

attributes:
  type: [defect, enhancement, task]
  severity: [critical, ...]
  priority: [high, low, ...]
  category: [UI, index, ...]
  assigned to: [someone, someoneelse, ...]
  progress status: [waiting, open, started, closed]
  ...

This can be tweaked as needed, if we need one more 'type' we add it,
if we do not need severity we remove it.

> > I would store and manage the first category using a simple YAML
> > file.  The bot acknowledges its updates by simply answering to the
> > discussion.
> 
> Requirement: Email notifications to ticket "subscribers"?
> That's reasonable.

I would say that the mailing-list is the only subscriber, people
choose to follow the discussion or not with their email-client.

This only miss the "vote for this issue" feature, which we can avoid
in the mean time and delegate to a polling tool afterward.

> > Those of the second category can be managed using a single email
> > discussion.
> 
> Requirement: Issue comments/attachments and status changes by email?

Right.

> > I don't know yet how many issues I've forgotten
> 
> I can't figure out anything really necessary you would have missed.

I got some more input via other channels about the need of an UI to
search, triage, sort issues. I would say that all of this can easily be
done by playing with the YAML file.  The only tool I see would be one
to fetch the email discussion given a Message-ID, but this is a matter
of another separated tool.

Thanks for your input!

-- 
Nicolas Pouillard
http://nicolaspouillard.fr
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk