Thanks Bob, Theo, Chris for your detailed answers. >From Ingos answer :
> ... Later on, when somebody would have time to look, such unprocessd reports have low visibility because they are nothing but an old posting on a mailing list, drowning in a lot of noise from invalid and resolved reports. Means for me, that a table of bugs / features are required. Instead of reinventing the wheel and add a new interface, create a table (could be a static site) including posting date, arch (release, stable, current), subject, if it is not enough a description, bug / feature, open / incomplete / WIP / closed. And, also a link back to bugs@. As a new bug / feature is posted at bugs@ add them to the table as open. If a dev answers, change it to incomplete / WIP and, if it is solved then change it to closed. A ideal world would provide complete bug reports so, the user has to provide as much informations as possible. The dev could ask for more informations if needed - if a dev didn´t ask for more details or the user don´t provide them then nothing happened. It is only a idea. I also have no team but maybe it is a option to start for one person (from a given date and, let the past) where others could join. Or, as Theo said, keep it as it is ... and expect, that users ask again about - lets say - forgotten bugs / features. Regards, Christoph
