I'd like to offer another type of solution to the same problem - a spam
filter is designed to evaluate and filter textual objects according to
the "does this interest me" criterion. Whether the textual objects are
email, and the negative target is spam, or the textual objects are bug
reports/fixes, and the positive target is "I can act on these", is
theoretically immaterial. Practically, it might or might not work, might
be worth a try. The good side is that a bayesian spam filter for squeak
exists and is used in Celeste, and being very little code, it cant be
too hard to adapt for a new purpose.

The benefits over categorization is that it doesn't add any extra work
to the process, and (if the UI is done right) can track ones interests.
In this case for example, instead of categorizing the items as
"interesting"/"garbage" maybe it should assign them scores, so that the
BFAV sorts the things that are most relevant to you to the top of the
list.

Daniel

Marcus Denker <denker at iam.unibe.ch> wrote:
> Date: Fri, 04 Jun 2004 18:09:41 +0200
> From: Marcus Denker <denker at iam.unibe.ch>
> Subject: Re: getting bugs to the right people
> To: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> envelope-to: danielv at localhost
> delivery-date: Fri, 04 Jun 2004 19:59:12 +0300
> reply-to: The general-purpose Squeak developers list <squeak-dev at lists.squeakfoundation.org>
> 
> Hi,
> 
> Yes, you are right. Having all the bugs and fixes sorted would help
> a lot. There are so many posting that I as a harvester
> just can't act uppon in any senseful way...
> 
> (e.g. those eToys enhancements, and all fixes for packages that
> have maintainers).
> 
> It would be nice to have a BFAV with categories: All issues are sent
> to the inbox, and then sorted to the categories... even inside a defined
> package we have multiple threads about the same problem. It would
> be great to group those, too...
> 
>       Marcus
> 
> 
> Am 03.06.2004 um 19:32 schrieb Lex Spoon:
> 
> > I spent an hour or so yesterday trawling through BFAV, and so now I 
> > feel
> > like a real user and have grounds to point out a, umm, missing feature.
> >
> > Most of the things I see being unreviewed are things that very specific
> > people *can* address or *should* address.  For example, if there is a
> > bug in the MorphicWrappers package or the Comanche, then only the
> > maintainer of that package can really address and close the bug.  I'm
> > not sure that these people are always seeing the bugs at all.
> >
> > Further, I'm not sure that *I* should be seeing them as a random BFAV 
> > reviewer.  It's truly mindnumbing to go through tons of bugs on
> > packages that you don't know much about.
> >
> > Along these lines, sometimes we do not have a maintainer when we
> > probably should.  As a particular example, is anyone in charge of
> > maintaining etoys as time goes by?  Someone posted a changeset that 
> > adds
> > a new command to all etoy objects, but this is the kind of improvement
> > that cannot be evaluated by itself.  The exact set of commands included
> > in etoys is very much a matter of taste and it requires that some take 
> > a
> > look at all the options and choose a set of commands that make sense as
> > a whole.  These decisions can't effectively be made one at a time.
> > Similarly, we can't really evaluate whether one small change to buttons
> > should be included; it takes a UI designer to look at a set of changes
> > and evaluate them as a whole.  It wouldn't work to simply start sending
> > in one changeset at a time from Zurgle; Zurgle should be included all 
> > or
> > nothing.
> >
> > Here's a feature that could address these concerns:  attach *every* bug
> > to some specific package.  That way, the appropriate people can see the
> > message, because BFAV can automatically email the maintainer of the
> > package.  Further, inapporpriate people can *avoid* seeing the message;
> > unless I look at MorphicWrapper bugs I won't see them.  Note, by the
> > way, that we can also have a "don't know" package to assign bugs when
> > the user really doesn't know.  This is especially acceptible if it is
> > possible to reassign bugs after they have been created.
> >
> > Just a thought.  Your eyes do not deceive you, and there is no code
> > attached to this email.  :)
> >
> > Lex
> >