I would add that the most irritating, annoying, and utter show stopper issues are regressions.

Canonical is doing tremendous innovative work with evolving the collaborative / problem solving – please keep it up.

Regressions are the worst evils of this entire process. There is nothing to suggest any concept of evolution if we constantly retract every single release.

If it worked once, let’s get the damn thing to work forever. Is that too much to ask? We absolutely must stop this ‘treadmill-headed-to-nowhere’ we find ourselves in with regressions.

No easy solutions, and perhaps that is part of the problem – we haven’t yet invented a process that fixes the core issue of regressions…

How about a Bug Interchange Format while we are at it? One bug standard to rule them all so that the information can flow better?

However, when reqesting new apps etc (Enhancement Requests, I’d call them), maybe more use could be made of forms to capture the info.

Just that it seems to be “Ask a question of the community”, rahter than if someone is a rawer beginner… instead of telling them to raise the big, have the Triage team look at stuff which might be worded more as a support ticket would be.. and then be able to generate a “bug” from it..

However, if it was to become more of a “support ticket” and Knowledgebase mechanism.. would also mean you immediately have metrics…

Also – there was talk around about getting end-users to talk to Upstream more.. surely you want experienced triagers and liaison people doing that…

——————–

I was wondering about wishlist requests – perhaps the way to deal with it is to

a) Define the vision for the platform and understand the vision of the application team.

b) Review the wishlist items at a high level to identify trends in the gaps identified by users to help clarify future objectives (how are we not meeting their needs)

c) Review the objectives for coming couple of release cycles

d) Then either add the wish list item to the specs, or close them as won’t fix.

note: the coming release could be a maintenance release (thus small gaps, minor issues might be fixed), or new functionality (major gaps, trend issues, could be addressed).

Either way, there shouldn’t be wishlist items over a year old. The world and the context of the issues will just keep changing, so why hold onto old issues?

(This is really an optimist and perhaps naive stance, but one that is based on just making a decision and moving on. If something is truly a gap it will come up again. Oerhaps someone with large application experience could weigh in)

Both systems are open to everyone, and bug reporting seems to be more popular at the moment. One possibility would be to restrict bug filing and direct more traffic to Answers, but this runs the risk of discouraging knowledgeable users from filing otherwise valuable bug reports.