[GRASS-dev] new bug tracker

GRASS GIS GRASS GIS developer
1

Hi,

suggestion; rearange order of trackers:

either:

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..

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

rename "web" to "website"

?
Hamish

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] So now I
have "all open", "new", "open, confirmed" power queries. It is a pain I
have to recreate these for each tracker, but I guess options will be
different. Can three like these be set up by default for all trackers,
for all users? ("all" == [Quick Browse] button on right side once you
figure that out)

pps- can "Submit New" be moved to left or made bold? It gets a little
lost in the middle of the other options.

ppps- can you set default activity chart to weekly/monthly in the
summary section?

2

Hamish wrote:

suggestion; rearange order of trackers:

either:

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. ?

rename "web" to "website"

Done.

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.

So now I
have "all open", "new", "open, confirmed" power queries. It is a pain I
have to recreate these for each tracker, but I guess options will be
different.

Yes, this can't be avoided due to differeces between fields in
different trackers.

Can three like these be set up by default for all trackers,
for all users?

I don't think so. I thought of this myself and haven't found such
functionality.

("all" == [Quick Browse] button on right side once you
figure that out)

pps- can "Submit New" be moved to left or made bold? It gets a little
lost in the middle of the other options.

You are right but this is yet another feature, :(.

ppps- can you set default activity chart to weekly/monthly in the
summary section?

Nope.

Cheers,
Maciek

3

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

4

Hamish wrote:

Maciej Sieczka wrote:

1) move "feature request" trackers before "issues" trackers so
wishes don't get filed as issues

2) group code, doc, web:

Same as above (even more doubled work). But maybe it is woth it. ?

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

OK. Will do. Tomorrow, hopefully. This will delay the new bugtracker a
bit more though. Sorry.

I think we should try hard to get it right before adding any real
bugs.

Yup.

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?

A tracker can have it's foreword like the one I've just put for the
code issues tracker. Let me know if you can spot it though ;).

If it has to be external, linked help pages can live on the wiki site.

That would be preferable. We shouldn't add any docs to GForge as GRASS
has it's WIKI for that.

Maciek

5

Maciej Sieczka wrote:

A tracker can have it's foreword like the one I've just put for the
code issues tracker. Let me know if you can spot it though ;).

after looking. If you put some blank lines before and after, it might
stand out more.

Hamish

6

Hamish wrote:

Maciej Sieczka wrote:

A tracker can have it's foreword like the one I've just put for the
code issues tracker. Let me know if you can spot it though ;).

after looking. If you put some blank lines before and after, it might
stand out more.

I have tried that first. Such blanks are skipped and don't make any
difference.

Maciek

7

Maciej Sieczka wrote:

Hamish wrote:
> Maciej Sieczka wrote:

>> A tracker can have it's foreword like the one I've just put for the
>> code issues tracker. Let me know if you can spot it though ;).

> after looking. If you put some blank lines before and after, it might
> stand out more.

I have tried that first. Such blanks are skipped and don't make any
difference.

do dumb tricks like a single space on the line or   work? "."?

Hamish

8

Hamish wrote:

do dumb tricks like a single space on the line

Tried that too; they are purged when saving changes.

or   work? "."?

These are treated like normal strings.

Maciek