Auto-WONTFIX for old UNCONFIRMED wishlist items

Ingo Klöcker kloecker at kde.org
Sun Nov 14 23:52:27 GMT 2004


Hi Philippe,

on Monday 15 November 2004 00:08, Philippe Rigault wrote:
> 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).

At least with respect to wishlist items you are missing the point. I'm 
also no fan of auto-WONTFIX. Therefore I've asked Coolo to exclude 
kmail. OTOH, WONTFIX is the only correct resolution for wishes which 
we, the KMail developers, never want to see in KMail. (So it's not a 
single developer who makes this decision, but all of them.) The fact 
that WONTFIX (as term) doesn't really work for wishlist items is a bit 
unfortunate. A wish can't be fixed, it can only be implemented. 
Therefore a better wording for closing wishlist items which will never 
be implemented would be WONT_BE_IMPLEMENTED. Simply think of WONTFIX as 
an abbreviation for this.

> 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)

None of the above fits for a wish which will never be implemented. Of 
course, never is a long time. But IMO it's more honest to close a wish 
as WONTFIX than to leave it open forever. This way the user won't be 
disappointed each time a new version is released without his feature. 
He'll only be disappointed once.

> > 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).

This is more or less also my opinion. OTOH, non-legitimate wishes will 
be closed as WONTFIX. Why should we leave a wish open which we never 
want to see in KMail? KMail is free software. If the reporter can't 
live with our decision he can pay somebody else to implement his wish. 
But he has to be aware of the fact that this feature will never find 
its way into the official version of KMail.

> 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!".

If you agree with a wish then you should vote for it. If you don't want 
to spend some of your limited votes on this wish then this wish is 
probably not that important.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20041115/b904e81b/attachment.sig>


More information about the kde-core-devel mailing list