Auto-WONTFIX for old UNCONFIRMED wishlist items

[Philippe Rigault]

Hello KDE core developers,

I would like to comment on Stephan's automatic WONTFIX proposal.

I fully support cleanup efforts and am willing to help as others, but I think 
that this proposal has the potential to do more harm than good. I also think 
WONTFIX is already a bad way of resolving bugs (let alone having an automated 
system to resolve them in a bad way), and would like to explain why.

Please bear in mind that this is the point of view of a (long time) KDE user
who, as many do, contributes to it, partly by diligently packaging, testing,
filing and analyzing bugs and sending patches whenever possible . I am 
convinced that there are many people outside KDE core developers that are 
also willing to help get rid of the clutter, and that sometimes they are in a 
good, if not better position to make a call about the bug (for example, only 
they have access to the platform or configuration where the problem is).

First, WONTFIX is already is the *worse* resolution for a bug/wish, because
 it combines irrevocability (WONTFIX = will never be fixed) with subjectivity
 (I, as a developer, can't fix it, therefore it cannot be fixed by others)
 and is intrinsically inconsistent (somebody else might fix it in the future,
 but I decide to bar that option at the time I mark WONTFIX). This resolution
 is essentially more about one developer's opinion at one point in time,
 rather than the nature of the bug in itself, and it really means "GOAWAY" to
 the submitter (a sure way to make him happy to contribute again). I can
understand "Won't fix for release X", but not "Will never fix" (unless the
bug/wish is invalid of course, but that is another resolution).

To further illustrate how self-contradictory and unhelpful WONTFIX is,
consider this situation: I have a bug/wish that I want to report, and this
bug has been reported before. If it is in a state of anything but WONTFIX, I
know what state it is in. I can add to it, or just wait. But if I see that it
has been closed as WONTFIX at some time in the past by some developer, what
should I do ? Maybe there is a developer who *now* can implement it ? So it
has truly become a *NEW* wish in today's context, and the legitimate action
in this case is to file it as a *NEW* bug. This would really clutter the
system.

So I think greater care should be given when marking reports as WONTFIX, and
 I can't think of any situation where WONTFIX helps as a blanket statement.
 Those I can understand:
- WORKAROUND (there is a --suboptimal-- way to get the desired behaviour)
- PLEASE_HELP (helpful, means: I can't or won't fix myself, you'll have to
help to get it resolved).
- NO_FIX_FOR_NOW
- WONTFIX_FOR_RELEASE=X (helpful to people watching the bug, so they don't
expect it in release X)

> Please have a look at http://bugs.kde.org/expired.cgi - I would like to
> give the listed wishlists a WONTFIX automatically after having the link
> online on dot.kde.org for a while. What do you think?

It is bad enough when a developer closes your bugs with WONTFIX (he is one of
the maintainers for now, but who says no other developer will implement it
now or in the future ?).
Having arbitrary rules to close wishes as WONTFIX is just about the best way
to discourage people motivated enough to submit bugs. Worse, I think it will
greatly encourage cheating, because as soon as an automated system to make
these calls is in place, creative ways to get around it begin.

> The current limits are ID < 64000 (roughly 15 months old) and less than 60
> votes (remember at 80 they become auto-confirmed for most products).

How come http://bugs.kde.org/show_bug.cgi?id=33282 (0 vote) doesn't show up
then ? Is it because it is NEW and not UNCONFIRMED ?

This bug also illustrates another way to improve the cleanup system IMO. In
this case, somebody without bugzilla write access (myself) looks at a bug,
spends some time to analyze it and thinks it is invalid. Because most of the
work is already done (if that call is right), there should be a fast track to
the assigned developers to either validate that judgement (and closing the
bug immediately), or saying something else about it ("No, I think it it
valid", "Not sure, leaving as is").
This kind of pre-filtering ("Reviewed by"), if correctly organized, would
result in *many* invalid/duplicate bugs going away quickly, and many old
wishes being better characterized in the context of today's KDE.

> So the kmail team is going to implement all the 800 wishes - that to a
> good share are only wanted by single persons? Neat idea.

you make two assumptions that are not entirely true:

1. People submitting wishes understand that there is no promise to implement
them. It is therefore fine for a legitimate wish to stay forever (i.e as long
as it s not fixed).
2. The fact that a bug/wish only has votes or comments from one person does
NOT mean that it is wanted by a single person. Currently, when I see a
bug/wish already reported, and I agree to it without anything to add, I
consider the wish registered, and I specifically refrain from adding to the
clutter out of respect fot the KDE developer, who might not be happy to see
tons of comments like "Yeah, I agree!".

Your proposal beaks both those principles, and would force people to:
 a) never trust the state of the systen, because legitimate reports close
themselves automatically after some time.
 b) spend some time to --artificially-- clutter the systen to influence some
kind of bug "score" if they want to enhance the chances for a wish to stay
alive.


Cheers,

Philippe Rigault

-------------------------------------------------------