Ok, about establishing bug tracking on Sourceforge:
There is some export mechanism if we need it later on (the following
copied from the sf support pages):
<sf help>
XML Export
The XML Data Export facility provides Tracker data, DocManager data and
Project News releases in an XML format. Due to the limited visibility of
data in disabled or project member-only Trackers (which will appear in
this export), the XML Data Export may only be accessed by Project
Administrators.
The XML Data Export facility may be accessed by Project Administrators
from the "Backup" section of the Project Admin pages for the project.
The XML Data Export facility will provide a complete set of Tracker
data, less file attachments, from all Trackers for a project. This data
may then be parsed from its XML format for inclusion in spreadsheets or
for further analysis by the project.
</sf help>
So I would suggest to start the bug tracking! There are some needed
setup tasks (I think Allin as the project admin has to do this):
1) disable SF patches tracker (to avoid confusion and only keep the
trackers that are really used)
2) disable SF support requests tracker (dito, support is on the mailing
list)
(2b: unrelated: maybe also disable SF mailing lists, referring to the
existing lists)
3) make me the "Tracker Admin" for the remaining two trackers, namely
"bug reports" and "feature requests/RFE" (Tracker -> Admin ->
choose
which tracker -> "Add/Update Users & Permissions"...)
After (3) I think I should be able to do (if not I'll get back to you):
4) allow unauthenticated issue submissions, because we don't want to
scare off users by having to register, right? (Tracker -> Admin ->
choose which tracker -> update preferences -> allow non-logged-in
postings -> submit)
5) maybe set other options, such as public tracker display, automated
emails to the team, ...
I'm not sure if the priority attribute is necessary, but given the scale
of 1-9 I suggest the following meanings for the bug tracker (note that
feature requests have their own tracker, and do not appear here):
9: crashes the entire computer, sets the house on fire, or x-rays the
backup disk in the closet
8: dataloss without gretl crashing (higher priority than a crash-loss
because it could go unnoticed)
7: gretl crashes (assuming such a thing always implies possible dataloss)
6: leads to wrong results/numbers (higher priority than giving no result
at all)
5: default priority for new issues
4: a feature doesn't work, although it should
3: documentation is missing
2: cosmetic issues like bad formatting
1: reserved for spam-type issues
About the "categories" and "groups", let's see later if/how we can
use them.
-sven