On Thu, Jun 26, 2008 at 3:41 PM, Dennis Schridde <[EMAIL PROTECTED]> wrote: >> I am quite sure we have discussed this before, and we made a decision >> that we should not put feature requests in the bug tracker, because >> this would fill up the bug tracker and make it harder to find and sort >> bugs. (And I hope you agree that fixing bugs is more important than >> adding features.) > I think that is what priority:wish is for. :) You can iirc filter for > priority>wish
But you cannot filter it away, at least not easily. So feature requests will pollute the bug list. That is unacceptable. We *need* to focus on clearing the bug list, and then it must be readily and easily available. Bugs must not be hidden among hundreds of feature requests. Bug reports are much more important than feature requests! > And yes, I agree that there should no feature request popup in the bugtracker > which are unrealistic. > Discuss with other users -> file a request. In that order. > There are also wrong or newbie bugreports, but the overall quality is > acceptable. I think if we can make the discuss-first-report-later policy > clear to the users, the same would work for feature requests. Who is going to tell people that their fancy, enthustiastic idea is stupid, and emphasize the point by rudely closing their feature request? It is either not going to happen, or it will take way too much developer time. Take the idea of limited ammo for all units. This was discussed extensively in connection with Watermelon's patch that implemented this feature. I am not sure if this was on the forums or on this list, or both. It was soundly rejected - yet it appears again as a feature request in the bug tracker. If we cannot simply close it because it is misplaced, we would have to restart a time consuming discussion about this feature in the bug tracker - a place hardly anybody reads. It is much better that such ideas are raised in the forums, and if there is agreement enough that this is a good idea, then a wiki page is started for it that sketches out how it can be implemented, and answers are worked out for the problems people see with it. This way also rejected ideas can be documented with reasons why - instead of being closed and buried in a tracker, which is in any case much harder to read. - Per _______________________________________________ Warzone-dev mailing list Warzone-dev@gna.org https://mail.gna.org/listinfo/warzone-dev
