[GRASS-dev] Re: new bug tracker

[Hamish]

Maciej Sieczka wrote:
> > suggestion; rearange order of trackers:
> > 
> > 1) move "feature request" trackers before "issues" trackers so
> > wishes don't get filed as issues (reader will start at top and stop
> > when they find a near match..
> 
> That would take removing all the trackers above feature requests, and
> setting them up again, so they are added in the end. Needless to say
> I'm not to keen on doing that :). If I find a way to avoid doubled
> work, will do. Is that fair enough for you or do you find the problem
> really big?
> 
> > 2) group code, doc, web:
> > 
> > code feature requests
> > code issues  
> > code patches 
> > doc feature requests 
> > doc issues 
> > doc patches 
> > web feature requests
> > web issues 
> > web patches
> 
> Same as above (even more doubled work). But maybe it is woth it. ?

[I prefer option "2" above, it's cleaner]

I think we should try hard to get it right before adding any real bugs.
After it goes live it will be too late to change without massive work.
For now I have saved the text of my 2 "test" code,doc bugs and can
repost them.

for recreating the existing trackers with minimal pain, you can view/
save the html source of a page to get a readable/cut&paste list of all
menu options for that tracker. Hopefully an easier solution can be
found -- maybe someone at intevation can make a low-level change?


> > ps - after I create a "Build Query" in the tracker, how do I get
> > back to an "unqueried" list? [fixed, sort of: I had to use
> > ctrl-click to unhighlight the "confirmed" status or highlight all
> > options]
> 
> I had the same problem and "solved it" the same way.
...
[other stuff to learn]

To make it more useable a lot of these bumps should be documented.
Is there a way to add/link help text to the trackers? If it has to be
external, linked help pages can live on the wiki site.


Hamish