>what we could do for the plasma ones is schedule an hour a week (or twice a >week?) and take them in batches and see if it is possible to work through them >quickly enough.
>we'll need to be brutal: only compelling and implementable > feature requests would be kept. ++ Being brutal the only way to handle wishlist reports in general. Even if it's a reasonable idea, if none of the developer team have any interest in implementing the wishlist in the foreseeable future there is absolutely no value in keeping it open. Otherwise you just clog up your bugzilla list from the information you do need to see. When I tried getting involved in the Plasma bug triage phase (last time this whole conversation came up) I found wishlists really frustrating as I kept thinking "That's a terrible idea, if I was the maintainer I'd close that", but didn't feel empowered to do that on someone else's project. I've heard bugsquad say before "we don't touch wishlist ideas" for the same reason. There were even several cases where the maintainer even explicitly said in a comment he disagreed with the idea, and then left the report open. Obviously it was never going to be implemented, so it just left things piling up. Worse it makes it harder for new devs to get involved as you can't just point them to the bug tracker to find a task, as it's full of things you don't want to do. I would happily help in any "hatchet" sessions. Regardless of the outcome of this thread about banning/moving wishlists suggestions a hatchet session is needed. David _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel