I've just spent a short while going through https://features.launchpad.net/distros/ubuntu/+specs, again, and trying to get rid of things that have already been done or things that are superseded. Quite a number of specifications on the list should really be wishlist (or above) bug reports on the appropriate package; indeed, several of them were also filed as bug reports by other people, have since been fixed, and I've marked them as implemented. However, it's essentially impossible to find the few useful gems of interesting ideas that are likely to find design and implementation momentum among the vast morass of "I'd like this bug to be fixed" reports.
I'm not trying to say that ordinary plebs shouldn't be allowed to create specifications, but I do think that we should be steering people towards Malone a little more, and try to indicate that the focus of specifications is more for organising development activity than as a means for users to request changes. In particular, bug reports mistakenly filed as specifications don't get sent by e-mail to the people likely to be able to fix the bug. Could some text please be added to the +addspec page to clarify the purpose of a specification and when one should file a bug report instead?
Hi Colin,
bug 50788 might interest you. According to Simon that's exactly the workflow people should be doing. If they want new features, they should write a spec instead of a wishlist bug.
I don't agree with that and think that the wishlist importance is useful, but perhaps it should be a status instead of importance.