christianlist wrote:We have so many tracker items that it's hard to get a good overview of were we are and where we want to go.
That's the reason I simply stopped following them myself. Back when I was actively developing the bug and RFE trackers took way too much of my time, just to do the first-level analysis if the bug or request was a valid at all. Not counting time trying to reproduce, asking more info etc which rarely got any answers. People just submit items and don't bother replying.
IMHO we need to have a lot less tolerable approach in future to keep this in hand. Especially with the RFEs. If the idea doesn't look like a good one to implement in foreseeable future we just close it. Not leave everything hanging there for years to come. We tried to handle this problem with the TODO-list. I think the approach is good - just should rename the RFE list to wishlist to make it obvious there are no any guarantees of implementing it. And the submitter(s) not developers need to convince others the wish item is worth implementing. All items are "future" by default.
I'm thinking we could split them like this:
- 3.0 - for the items we'll include in version 3.0
- 2.16 - for the items we'll include in version 2.16
- 2.14.2 - for them items we'll possibly include in 2.14.2 (maybe we'll decide not to release 2.14.2 at all)
- Future - for items that we may eventually implement, but it's not on our agenda in the near future
- Limbo - for items that are not likely to be implemented at all, but we'll keep them around just in case things change
Should we have more/less milestones than this?
I don't believe setting initial milestones works. It hasn't worked before. People always think they have time for something but after all are late for the release and then we add untested and work-in-progress patches to releases just to get the code in. I tried hard to track the features we'd include for few stable releases. It just didn't work. We didn't get all we were planning to get but got few we didn't plan. It is very hard to do project plans when people are doing all the work as they wish in their free time.
We need to think it other way around. Set the milestone when the code has been accepted to the release. Until that the item is "future". I don't think there are features we "must have" for some release. If we have, then we must also have a serious commitment to implement it. Not just "I may do it".
Also, I don't think we need "limbo" at all. If the thing doesn't look good then just remove it. If somebody thinks it is a good and needed idea they submit it again and that is then a signal that there might be some good in that idea. Current trackers are polluted with the "future" ideas nobody is interested in implementing but somebody once thought to submit anyway.