For me it's not about overload, it's about quality. I want to create higher 
quality applications. 

Currently the bug reporting system is working against me. I spend time on 
dealing with bug reports that would be much better spent on fixing bugs. 
Dropping unimportant bug reports would at least increase the average quality 
of bugs reported which would help. Many of the low quality bug reports come 
from people who submit bug reports without a comment and only a backtrace 
(with no debugging symbols), so only letting people with debugging symbols on 
submit bugs reports with dr konqi makes some sense. (The drawback is the some 
poorly written bug reports can still be very valuable, eg. bug reports about 
unknown critical bugs).

Even better than increasing the average quality of bug reports would be 
increasing the absolute quality, by encouraging people not to simply send a 
report when something is wrong but actually try and work out and what is 
going wrong. (There is a lot non-developers can do here, just by 
experimenting and investigating. If we can change people from being helpless 
bug reporters to effective bug investigators then that is good).

The bug reporting system provides very valueable information. However the 
quality/quantity equilibrium is such that I'm prepared to trade some quantity 
for an increase in quality.

BFN,
Don.

On Wed, 30 Aug 2000, Andreas Pour wrote:
> Dirk Mueller wrote:
> > On Mit, 30 Aug 2000, Andreas Pour wrote:
> > >   (1)  already discussed, do not permit a backtrace to be sent if there
> > > are no debugging symbols.  OTOH, non-crash reports (like
> > > http://my.favorite.site/ does not render properly) should still be
> > > allowed.
> >
> > sure, that's what we're talking about.
> >
> > >   (2)  harder to implement, get a group of volunteer testers together.
> > > Get 1-2 people responsible for each app and they go through the reports
> > > for these apps.  They can filter these as non-useful,
> > > non-reproduceable, already fixed or requires developer attention.
> >
> > Sure, we need to integrate volunteers better but I personally don't like
> > when a "non-programme" closes such bugreports unless they're clearly
> > duplicates. I'm afraid that they will close bug reports too early because
> > they don't know the internals etc.
>
> Good point, but I think this can be dealt with.  The idea would be that
> they don't have to close anything if there is no "overload" (i.e.,
> outstanding bug reports exceed a threshold).  The developer could define
> the "overload" point -- which means the developer is not having enough
> time to look at the bug reports.  The options then are (1) the bug
> reports are completely ignore, or (2) the developer gets help in finding
> the "real" bug reports.
>
> If you think there are many bug reports now, wait till distributions
> start shipping KDE 2.  You will have to work full-time just to read the
> bug reports ;-) -- and many of them will be a distribution's fault
> (e.g., why does SSL not work -- when the answer is, the distribution did
> not ship SSL b/c of export problems).
>
> Ciao,
>
> Andreas

-- 
xya
asdf