Brian Mastenbrook <brian@...> writes:
> Here are things which I think are essential feature requirements:
I actually have no idea about quite a lot of that.
Here's some kind of minimum from my point of view:
* a user of sbcl must be no more constrained in tools they must have
installed than they are now when they wish to file a problem report
or "change request".
At the moment, if a user wants to report a bug, they must be able to
do SMTP in some way. They do not need to have a graphical web
browser, emacs, or xml-rpc client; they do need some kind of mail user
agent and a live internet connection. If at all possible, I would
like this bare minimum to continue; an exception is that it would be
acceptable to depend in addition on sbcl itself to report a bug.
* an 'administrator' of the bug tracker must be able to batch
operations to bugs.
At the moment, if I close a number of bugs, I delete a number of
entries in BUGS. If I want to annotate a number of bugs, I can write
text under a number of entries in BUGS. Anything which requires
multiple feedback cycles to achieve the same effect is a non-starter:
the point here is that sometimes multiple apparently dissimilar bugs
are affected by one "workflow operation", for want of a better term,
and requiring that to be broken up increases workfriction.
This batching requirement effectively kills off all the off-the-shelf
web-interface bugtrackers that I've ever come across. Having had a
uniformly negative experience with all such, I'm not sorry.
* it should be easy to refer to sources of information, including
** sbcl mailing-list messages;
** #lisp IRC discussions;
** cliki and sbcl-internals pages;
** the hyperspec;
** the sbcl manual;
** comp.lang.lisp or cmucl mailing-list messages;
** other likely suspects.
If the bug is purely textual, then textual description is fine. If
it's being presented to a questor over http, then hyperlinks or inline
content, as appropriate, should be inserted.
* users of the software should be able to add unbounded metadata to
change requests, and query this metadata.
What I mean by this is that the software itself shouldn't define a set
of tags with certain semantics; instead, the users of the software
should be able to grow tags and apply queries to tagged data.
Entomotomy got this bit right, using the CLiki concept of *(topic);
debbugs gets this wrong.
The wide picture, as far as I am concerned, is that debbugs is very
close to an ideal interface: for users, because it is very easy to
submit a bug; for developers, because it is easy to tag bugs, adjust
their severity, close or reassign them, all without making more than
the most conservative of requirements on installed software (and its
complexity). Debbugs doesn't have quite the flexibility of the ideal:
it has a fixed set of tags, for instance, and bugs are assigned to
packages (which may not have a clear mapping into the monolithic sbcl
system, though it would work fine for contribs); that said, I would
encourage anyone attempting to design a bug tracker for distributed
collaborative work to try using debbugs for a little before going too
far down any given road.