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
No comments:
Post a Comment