Hi,
I'm thinking of doing what Lars suggests, when we migrate to Redmine:
close wishlist bugs that have seen no activity since, say, a year.
Thoughts?
Almost every bug tracker for free software projects has a section for **wishlist bugs**. Often this results in ever growing lists of wishes, most of which will never be fulfilled.
A long list of bugs, even if it is wishlist bugs, is rarely useful. It's hard to keep track of what is there, and so the information is not kept up to date when things change. Even if a wishlist bug gets implemented, the bug is often overlooked, and remains on the list.
Joel Spolsky calls this [a software inventory](
http://www.joelonsoftware.com/items/2012/07/09.html). Carrying a large inventory has costs, and usually results in slowed-down development. It increases the friction of doing things in a project.
I have some quite old wishlists for my own projects. I have even more wishlists hidden in my own [GTD system](
http://gtdfh.branchable.com/). I am not happy about either, and I'm going to have to do something about that.
Just closing all wishlist bugs immediately would be bad manners. Keeping them open indefinitely, just in case someone will some day decide to look through the list in order to hack on something, is wishful thinking: that rarely happens.
So I'm thinking of a compromise: keep wishlist bugs open for a while, perhaps a few months, and if nothing is happening to them, close them with an apology.
URL:
http://blog.liw.fi/posts/wishlist-bugs/
--
intrigeri
| clé GnuPG @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc
| empreinte OTR @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc
%0A>%20%0A>%20Almost%20every%20bug%20tracker%20for%20free%20software%20projects%20has%20a%20section%20for%20**wishlist%20bugs**.%20Often%20this%20results%20in%20ever%20growing%20lists%20of%20wishes,%20most%20of%20which%20will%20never%20be%20fulfilled.%0A>%20%0A>%20A%20long%20list%20of%20bugs,%20even%20if%20it%20is%20wishlist%20bugs,%20is%20rarely%20useful.%20It's%20hard%20to%20keep%20track%20of%20what%20is%20there,%20and%20so%20the%20information%20is%20not%20kept%20up%20to%20date%20when%20things%20change.%20Even%20if%20a%20wishlist%20bug%20gets%20implemented,%20the%20bug%20is%20often%20overlooked,%20and%20remains%20on%20the%20list.%0A>%20%0A>%20Joel%20Spolsky%20calls%20this%20%5Ba%20software%20inventory%5D(http://www.joelonsoftware.com/items/2012/07/09.html).%20Carrying%20a%20large%20inventory%20has%20costs,%20and%20usually%20results%20in%20slowed-down%20development.%20It%20increases%20the%20friction%20of%20doing%20things%20in%20a%20project.%0A>%20%0A>%20I%20have%20some%20quite%20old%20wishlists%20for%20my%20own%20projects.%20I%20have%20even%20more%20wishlists%20hidden%20in%20my%20own%20%5BGTD%20system%5D(http://gtdfh.branchable.com/).%20I%20am%20not%20happy%20about%20either,%20and%20I'm%20going%20to%20have%20to%20do%20something%20about%20that.%0A>%20%0A>%20Just%20closing%20all%20wishlist%20bugs%20immediately%20would%20be%20bad%20manners.%20Keeping%20them%20open%20indefinitely,%20just%20in%20case%20someone%20will%20some%20day%20decide%20to%20look%20through%20the%20list%20in%20order%20to%20hack%20on%20something,%20is%20wishful%20thinking:%20that%20rarely%20happens.%0A>%20%0A>%20So%20I'm%20thinking%20of%20a%20compromise:%20keep%20wishlist%20bugs%20open%20for%20a%20while,%20perhaps%20a%20few%20months,%20and%20if%20nothing%20is%20happening%20to%20them,%20close%20them%20with%20an%20apology.%0A>%20%0A>%20URL:%20http://blog.liw.fi/posts/wishlist-bugs/%0A>%20%0A>%20%0A>%20--%20%0A>%20%20%20intrigeri%0A>%20%20%20%7C%20cl%C3%A9%20GnuPG%20@%20https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc%0A>%20%20%20%7C%20empreinte%20OTR%20@%20https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc%0A>%20 "Responder a esta mensaxe")
