Hamburger wrote:+1 on using a bug tracker, if the resulting aspects are clarified first:
- how do we educate the user base to use it (or is it a tool for developers only?)
I would start by establishing it as a tool for developers only, as they usually have a better insight for what's a bug and what isn't. Similar to how bugs and issues in the code are currently reported on this "Current development and bugs" board.
But of course it should be left it open for regular users to report issues as well. However, for a "normal user", it's usually hard to determine if their problem is a genuine bug in the code or a configuration/user error, so it's probably better to steer the discussion on the forum first. However, if during such a discussion it turns out that the problem is actually a bug, it should be filed and tracked accordingly (maybe including a link to the related forum discussion for background info).
The bug tracker should not be considered an alternative way of getting support - questions of such kind should be closed right away, with a hint to use the Forums instead. These bug reporting guidelines should be posted on the Wiki or as a sticky note on this board.
- who does the work of managing the bug tracking/assigning/closing etc.?
I'd handle this in an open fashion and improve/modify the process as we go along. Primarily it should of course be the "core developers" who work on the code base already anyway (and might even be the authors of the functionality in question). When you contribute new code and functionality, you should be prepared to maintain and improve it and to assume some responsibility. So again, the people initially in charge of handling bugs would be the ones working on the code already.