[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Nice writeup. Just brainstorming, here are the features I personally
find vital for an issue tracker that would make me happy:

1. Web submission. The burden of creating a record should be on the
submitter---it's not too much to ask, and it saves developer time. This
also encourages reporters to provide relevant information like version,
platform, Ruby version, etc. upfront, since they can be prompted for
those data explicitly.

2. Developer discussion via email. This is vital. There's no way I would
want to have a technical discussion using text boxes on a website. And
this discussion should be attached to the issue, of course.

3. Canonicality. I want one name for a bug, and I want one URL that I
can point people to when referring to it. That URL should have the
entire history, including developer discussion, of the issue.

4. Browseability. There should be some public way of getting a view of
all the open issues, at a minimum. (Web seems natural.) Other stuff like
sorting by priority, attachign to releases, etc. are icing on the cake,
but if people are going to be chipping in on development effort, or
searching to see if other people have had this bug, they have to be able
to browse what's out there.

> About the issues identifier I see two options, either we try to
> allocate simple integers like most of the trackers or we just keep the
> unique (long) identifier.

I want a simple one. I can remember JIRA-style "ABC-123" names and
that's really handy sometimes.

Just my two cents.
-- 
William <wmorgan-sup@masanjin.net>
_______________________________________________
sup-talk mailing list
sup-talk@rubyforge.org
http://rubyforge.org/mailman/listinfo/sup-talk