[Tracker-discuss] Feature/Change request handling procedure

[Neal Norwitz]

Thanks for your collective efforts to get this working.  It would be a
bit easier for me to comment with the DB loaded up, but I have some
meta & concrete comments.
There are a bunch, I'll try to prioritize some.  The general ones are
probably more important to me than some of the details.  I also think
it's important to get this out sooner rather than later.

The tracker should be much simpler (less options) than it currently
has.  It seems that your proposed schema does a bunch of this.  I want
to see something as simple as possible.  I haven't used the version of
the bug tracker on code.google.com, but I was involved with the
original design.  I like that it's minimal, but still powerful.

The Issues link in the left nav bar should maintain the existing
settings that people have for sorting and grouping.  Only minimal
fields should be sortable/groupable.  We can add more later.  Make
this as simple as possible for users.  If we find we need more we can
add it later.  It will be harder to remove funcationality.  (Basically
be agile and add only the features that people request.)

I'd like to be able to add a new bug easily.  It shouldn't require a
login, though we should always capture an email addr.  Make it a one
step process so people don't get put off creating bug reports.

The search box in the upper right should be labeled that it will
search for issues.  I wasn't sure if it was a general Google search or
specific to the issues without trying it.

I didn't like that grouping took priority over sorting, but sorting is
displayed above grouping.  I'd rather only sort/group by a single
column.  I'd like to see the download to CSV moved elsewhere.  It will
rarely be viewed, but we will always have to look at it.  Grouping on
things like time doesn't make sense, although sorting on time does.

I'd like a lot of flexibility in grouping bug reports together.  This
is where a feature like Google's labels make a lot of sense.  I'd like
to be able to add a bunch of labels to bug reports.  The reason for
this is that no one can handle 900 bug reports.  But they can handle
5.  I want to make it easy to display those 5.  Many bug reports are
focused in a handful of places, some specific modules, doc, o/s
specific etc.  I want to be able to easily filter however I'd like.
The only way I can think of to do that is with labels.

Ideally I would be able to sort by clicking on the column heading
rather than change an option menu and click redisplay.  I would like
to be able change/reorder the columns shown.  I would like to be able
to star issues.  (It could just display a star if I'm on the nosy
list.)

I would like the entire row to be highlighted if I moused over it and
be able to click anywhere in the row to view the details of an issue.

I realize a bunch of these are how roundup is currently implemented,
but I'd like to be able to easily find any subset of issues and track
them.  SF doesn't give me an easy way to do that.  If I change a
viewing preference, it's sticky and I have to change it later.  I want
to have a bunch of different views I can easily go between depending
on what I'm working on.

Hope this helps and doesn't scare you away. :-)

n
--
On 11/21/06, Stefan Seefeld <seefeld at sympatico.ca> wrote:
> Brett Cannon wrote:
>
> >     * version is an enum to express the python version (or branch) the
> >     problem
> >       occured in.
> >
> >
> > Is this a single setting, or can it have multiple values?  If we
> > automatically close old bugs, it might get us to deal with things faster
> > and thus we won't have bugs from a couple versions back.  But otherwise
> > we can end up with bugs where they are present in 2.3 and people need an
> > easy way to note that it is still present in 2.5, etc.
>
> Good point. It certainly can be a multilink, i.e. refer to multiple
> versions / branches. (An interesting side-note: if we hook up with
> subversion, we probably want to track changes to individual branches
> and only close out the parts of a bug that got affected by a checkin.)
>
> > This also brings up the idea of having a dependency field.  If I am
> > waiting for feedback or more details from someone, set that field to
> > their username.  If I don't here from them after a set amount of time
> > (like two weeks) the bug gets closed automatically for lack of information.
>
> Right. I think there can be a status enumerator for this state, together
> with a timer that gets started whenever that state is entered.
>
> >
> >     * severity is an enum allowing users to express the impact the bug
> >     has on them,
> >       such as: (critical, major, normal, minor)
> >
> >     * dependencies: a list of bugs that need to be fixed before this can
> >     be fixed.
> >
> >     * status: one of (new, open, closed)
> >
> >     * resolution, set when status is set to closed: one of (fixed,
> >     invalid, duplicate)
> >
> >
> > Also add "Lack of Info" or something since we end up with bugs that just
> > sit there waiting for more info from the OP that we never get.
>
> Good point. Wouldn't that be the same status enumerator as above
> (or at least, very similar) ?
>
> >
> >     * superseder: a follow-up bug, if resolution is set to duplicate.
> >
> >     * milestone is an issue type useful for release management. With it
> >     it is
> >       possible to query for bugs / peps to be closed for a given point
> >     (release / time)
> >
> >
> > So like showstopper, A1, B2, etc.?  That way one can specify that this
> > bug must be closed by that point or else the release is blocked?
>
> Right. However, that would be an attribute of the milestone -> bugs link,
> not the bug itself. The bug itself doesn't care that a milestone is on hold
> for it. :-)
>
> >     * pep is a placeholder for PEPs, just to illustrate that this
> >     tracker can grow. :-)
> >
> >
> > =)
> >
> >     Access
> >     ------
> >
> >     Users submit bugs, setting title, and optionally components,
> >     platforms, version,
> >     and severity.
> >
> >
> > Don't let them set severity.  I have gotten into mini competitions with
> > OPs over resetting the severity.  They think they know better than me
> > what is severe and what isn't.  And everyone's bug to them is severe.  =)
>
> I guess that's your call. I have made good experience with such a flag.
> And, it doesn't have to affect your ranking, it's merely a hint, you know. :-)
>
> >     Developers set assignee, status, resolution, dependencies, and
> >     superseder.
> >
> >     Conversion
> >     ----------
> >
> >     Conversion from sf.net <http://sf.net> should map 'category' to
> >     'components',
> >     and 'group' to 'version'.
> >
> >
> >
> >     If there are no objections, I'm going to start to implement it.
> >
> >     Comments ?
> >
> >
> > Any way to flag that a patch might be ripe for backporting?  Sometimes
> > people fix stuff in svn but don't have the time or inclination to
> > backport, so it can get lost (people are supposed to note it in
> > Misc/NEWS, but that is really the wrong place to denote it).  If there
> > was a way to close a bug and flag it as needs backporting (or have a
> > "Backport" resolution) that would help matters.
>
> That sounds like something for for a roundup script, where a new bug
> is created by cloning an old one, but attached to a different branch / version.
> Or somesuch.
>
> Thanks,
>                 Stefan
>
> --
>
>       ...ich hab' noch einen Koffer in Berlin...
> _______________________________________________
> Tracker-discuss mailing list
> Tracker-discuss at python.org
> http://mail.python.org/mailman/listinfo/tracker-discuss
>