We were talking about generic Bugzilla voting and reasons why people might not feel very inclined to vote (on bugs or enhancements). So, yes, I'm also talking about bugs.

See, that excuse might fly if these bugs had been filed only a few months ago, but many of these bugs have been sitting ignored for almost as long as OS2008 has been available, only to be WONTFIXed recently because Nokia can't be bothered to triage their damn bugs.

Yes, I'm glad these wont be issues for Fremantle, but it's not particularly heartening that current device owners are still screwed.

It would be much less of an issue if new releases didn't invalidate old hardware, but they do. The same thing happened to 770 bugs when the N800 was released.

Clearly there isn't an easy way around new hardware invalidating old in the embedded market, but if Nokia would stop ignoring community bug reports and invest a little time in at least trying to push fixes and improvements for current releases the community would be a lot happier.

Clearly resources are limited, and clearly fixing every single bug and enhancement for the current generation isn't realistic, but a little effort in this direction would go a looong way.

WONTFIXed because Nokia didn't bother to look at the bugs while the window for fixing them in OS2008 was still open. If the bug missed that window because it was filed too late in the cycle, fine, but missing it because it sits dead for 8 months first isn't acceptable.

Problem is, Andre can only do so much running back and forth, and that running back and forth detracts from more useful activities like actually getting Nokia to use Bugzilla. . . .

Routing all communication between Nokia engineers and managers, and the community through one person is incredibly inefficient. The result seems to be bugs going ignored until the window of opportunity to have them fixed in the current release has closed.

I'm more optimistic about the future, but you'll understand my frustration with how things seem to be working now and how things worked in the past.

Anyway, this is somewhat off-topic.

And then, there's all the sad little bugs (like some of mine) that get zero attention...

Reminds me of a former job:

I used to manage change notices for a large American tool manufacturer. The engineering manager's philosophy was that FIFO need not apply-- the "big bang for the buck" CNs always took priority, no matter what was already in the basket.

So lesser CNs languished in the bottom of the IN basket for months... and months. Where accrued time alone eventually made them worth as much if not more as the $$$ changes.

But the manager would not budge from his philosophy. He was sure that SOMEday we would have enough free time to tackle those dusty "little" CNs.

Ha!

Out of frustration I finally came up with a proposal: most of the month the Big Ticket Things were attacked. No problem. But ONE Friday out of every month, employees would do nothing but incorporate the five-minute changes that had now taken sometimes 3 months or more to get to (I kid you not).

Lo and behold, the process worked. We spent 95% or so of our time on the Big Things, and the rest on breezing through the Easy Stuff.

Win-win.

And I think there's an applicable moral there for software bugs, too.

The End.

Would karma for votes be a good way to encourage people to vote? Seems like a little incentive might help. Perhaps weighted the same as favorites/buries. Although it could change the motivation from "I want to feature implemented/bug fixed" to "I want karma", which might not be a great outcome.

Are we more worried about motivation, or results?

GA, of course I understand the frustrations. And I really appreciate those (like you) going over them and helping to fix the problms.

Look, I wasn't in the Maemo SW team the day it was decided to setup a public bug tracker without having a process and resources to handle the feedback properly. I won't blame who did that either, because probably had not many other choices.

After many discussions and attempts, at the beginning of the year we got the budget to start breaking the wall by hiring a good external bugmaster. He landed when OS2008 was well cooked and served, with the kitchen preparing for Fremantle.

Since then a bugsquad team has been created and all the new feedback gets reviewed by many eyes inside Maemo SW and in the community thanks to bug jars and weekly internal reports including cloned bugs in the internal bugzilla. Also the hundreds of open bugs/requests get slowly reviewed thanks to their votes, priorities and slow but systematic scanning component by component.

Is this enough? Of course not. To me actually this is good training for Fremantle, and it's even probable that fedback handling in Fremantle won't be still good enough but it will be good training for Harmattan - which should bring The Right Thing without excuses.

Part of the right thing is to handle feature requests with the commitment of product managers and supported by a process making them follow the feedback when planning roadmaps. The lack of process and commitment was the original sin made with bugs.maemo.org and is what we need to avoid when giving birth to a potential Maemo Brainstorm. fyi I'm working with them anyway to get them in the loop through a Feature Jar and the current features in the bugzilla.

In the meantime, we focus our attention is what is new (to cut the trend you mention about new feedback not reviewed in months) and what is relevant.

For the later, votes are essential and just this fact should be incentive enough for people to vote (imho). However, why not karma for voting? People have 20 active votes max so there is no easy way to abuse that in a really harmful way. If people "abuse" the system by rising just any irrelevant bug two things might happen:

- The abuse is so spread in many bugs that it doesn't cause any effect on e.g. bug jars.

- The abuse causes irrelevant bugs to appear on the top, but because they are visibly irrelevant they get a quick resolution in any way, getting off the list.

I just wish more people would take the time to look, and vote.

I happen to believe that a couple of my languishing bugs/requests are really important, but they have received little or no attention. Some could reasonably say that proves my own sentiments wrong, but I am sure that if anyone took the time to examine them they would see the benefits in having them addressed. You know, the way I vote and comment on the bugs entered by others. And, yes, I have drawn attention to mine many times...

Well, if you are going to measure the success of this community involvement initiative by the number of votes, I think it's clear that the Ubuntu brainstorm-like UI will attract more users/votes.

In my own company we actually want to hear feature requests from fairly technical crowd only, so Bugzilla works as both bug-tracking and feature request-tracking tool for us. But if I was in your shoes, having your objectives, I'd definitely set up something nicer for end-users.

I'll be honest, I haven't looked at any bugs in Maemo Bugzilla, but for us a feature-request is manually split into a few bugs (UI, core, storage I/O) anyways, so someone would still have to work on getting the proper bugs created based on the feature requests.

Don't forget Launchpad is going to be open sourced end 2009.

If the plan goes well, there will also be a lot more users. You still want their feedback, but it will be of different quality than a good Bugzilla report. Therefore, I envision some kind of platform between Bugzilla and the normal end-user.

fwiw Ubuntu Brainstorm is open source already now and it's a Drupal module, not a component of the Launchpad 'suite'. I don't know whether it is or will be integrated with Blueprints and etc.

Feel free to send me an email and I see what I can do.