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