Bugzilla or else to handle feature requests?
 

http://wiki.maemo.org/Task:Brainstorming_new_features is a task still in the maemo.org backlog but there is one question that would have a bigger impact depending on the answer:

In the long run, where should feature requests be handled?

a) http://bugs.maemo.org as nowadays, making it more friendly to end users.

b) A specialized tool like http://brainstorm.ubuntu.com/

c) Else

A meta-question would be whether the answer depends who you ask to. For instance, would Andre (maemo.org bugmaster) and Reggie (InternatTabletTalk admin) have the same opinion? Would ITt and maemo-developers reach the same conclusions? Who to listen and where to discuss?

2 facts, already difficult to negotiate:

- Reusing bugs.maemo.org is easier (and probably cheaper) than adding a maemo.org brainstorm. However, in theory the community should be able to handle completely e.g. a Drupal instance with Ubuntu's brainstom software.

- A maemo.org brainstorm like Ubuntu's far from the bug tracking system would make happier non-technical end users and product managers, and perhaps a bunch of power users and developers tools. However, in theory
the bugzilla UI could be tweaked to be reasonably acceptable as well.

Opinions?

(The same question was posted few days ago in the maemo-community list)

Re: Bugzilla or else to handle feature requests?
 

Don't mix them! Bugs are one thing, new features are an other thing.

Those are the guys that'll use the system, so why not make them happy.

To file a bug one has to know a lot more about the system and how to reproduce the bug to make a proper bug report. The average user, who just wants feature X, it's too much to ask from.

Re: Bugzilla or else to handle feature requests?
 

Those voting options "with tweaking" please give a hint about the tweaks you have in mind.

maemo.org URL and layout is guaranteed. ;) What other changes to implement?

Re: Bugzilla or else to handle feature requests?
 

Tweaking - slight bit of moderation to apply layout or spell-check to make it more appetizing for people to vote on. Is login needed for something for this? May put off user incentive to vote.

Combine "bug jar" initiative - "feature jar" of upcoming features to forums/mailing lists?

Re: Bugzilla or else to handle feature requests?
 

Not cheerleading here, just explaining how the Voting feature currently works in Bugzilla.
You go to a bug report and click on "Vote for this bug". A table with all your (former) votes will be presented and an "Enter New Vote here →", see for example https://bugs.maemo.org/votes.cgi?act...ug_id=1#vote_1 .
One needs to be logged in for this - might be a burden to register first, might also avoid persons voting 20 times for their favourite bug. :-/

The UI is probably a bit confusing, at least one person told me.
Take a look at it, also take a look at http://brainstorm.ubuntu.com/ and add your vote to the ITt poll here or proposals how to tweak. :)

Re: Bugzilla or else to handle feature requests?
 

I prefer the bug tracker, because it's easier to follow the progress of an issue (and a feature request is an issue).
At least in theory, in practice....

Re: Bugzilla or else to handle feature requests?
 

My plan was always to have a brainstorm site for non-specific ideas like "Multiboot", "Add a recovery mode" or "Implement browser tabs" where we can work out the reasonability of the suggestion, then discuss the specifics of the actual implementation once it's decided that it's valid. Once a plan is put together, the specific steps will be moved to bugzilla in the form of enhancement requests.

It's not an either/or proposition, but a clear and straightforward feature development process from one step to the next.

Re: Bugzilla or else to handle feature requests?
 

That makes a lot of sense, GA.

Re: Bugzilla or else to handle feature requests?
 

Please find a better way, to make sure no one votes twice, than registration. Even usernames are unnecessery in my opinion.

I really think that online discussions in general would benefit from anonymous forums with the options to vote for each post and thread.

Re: Bugzilla or else to handle feature requests?
 

Do you have any suggestions?

Re: Bugzilla or else to handle feature requests?
 

IP
cookies
CAPTCHA
e-mail vote confirmation

Re: Bugzilla or else to handle feature requests?
 

Why?

Honestly, if you're not willing to take 30 seconds to register to vote or comment, I'm really not all that concerned about what you think. Let's leave the lazy consumer poling to Nokia, as they're certainly better at that than we are, and implementing a complicated voter-uniqueness assurance really isn't worth the time to get these people's input.

Re: Bugzilla or else to handle feature requests?
 

Add the options for every user to vote on each post and thread and you have the perfect comunity! ;)

Re: Bugzilla or else to handle feature requests?
 

I would like to see feature requests completely separate from bug postings. I'll bet bug wranglers would, too. ;)

Re: Bugzilla or else to handle feature requests?
 

While I'd certainly prefer not to see stuff like "Make tablet boot in 5 seconds" on Bugzilla, I think it's the appropriate place for reasonable, specific requests like "Enable the 'Refresh repositories' button in the Main View in Blue Pill mode".

Re: Bugzilla or else to handle feature requests?
 

I see your point.

How about distinguishing between completely new features versus enhancements/corrections of existing features (the latter staying in bugzilla)?

Re: Bugzilla or else to handle feature requests?
 

As someone who processes a lot of bugs, I'd prefer to keeping using an interface and process I already know as opposed to one I'd have to learn (and possibly help define). ;)

I see the distinction as one of scope, rather than one of 'newness'. Specific, resolvable enhancements (whether to existing features or for new ones) should be in Bugzilla, while more generic requests, or requests with much larger scope should be discussed on a 'brainstorm' site and turned into a series of specific requests to move to Bugzilla.

Re: Bugzilla or else to handle feature requests?
 

*votes*

Brainstorm, ftw. Easy, efficient, and user friendly. It encourages community input, and encourages more people to join the community, which encourages more input, which...

:D

Please, Nokia, Quim... Maemo Brainstorm! (With pretty graphics ;))

Re: Bugzilla or else to handle feature requests?
 

Being a bit provocative...

10 votes only in this poll? Is this also a statistic to read?

Starting a Brainstorm implies also high levels of participation. Currently the amounts of votes in bugs.maemo.org are not impressing either.

Re: Bugzilla or else to handle feature requests?
 

Better turnaround and communication from Nokia will help here. :)

There aint much point in voting on things that interest you if they just sit ignored or end up WONTFIXed.

Re: Bugzilla or else to handle feature requests?
 

11 now. You have to like a 10% increase. :p

Re: Bugzilla or else to handle feature requests?
 

Brainstorm, with the function being a bridge between end users (the ones GA doesn't wish to deal with) and the community, as well as a place where people come together to discuss issues; results & conclusions would be reflected on Bugzilla. Also, from this pool Nokia and Maemo community (or whoever) are able to draw data from, for example to add to Maemo Bugzilla. Bugzilla is too complex and hierarchical for normal end users.

I'd like to see one thing different/tweaked though: I'd like to see the option where people are able to make a bounty / pledge for a specific feature or idea. I'd also like to see that in Bugzilla.

Re: Bugzilla or else to handle feature requests?
 

Something like http://www.chipin.com/

Re: Bugzilla or else to handle feature requests?
 

I can speak only for myself, but I needed to find time to look at Ubuntu brainstorm before voting.* That now done, I'm backing this idea:


* Given the frequency with which Maemo is compared to Ubuntu and maemo.org is compared to the Ubuntu community, I feel as though I should be using Ubuntu, but I haven't yet been able to get past my dislike of fundamental choices made for the distribution.

Re: Bugzilla or else to handle feature requests?
 

I'll vote later, when I have digested all the input from the good people here..

Re: Bugzilla or else to handle feature requests?
 

Fair point.

There are reasons to think things will improve (or kep improving, depending how you see it):

- There is a trend of improvement already. Now we are discussing and disclosing sooner and more often than before.

- The Maemo SW team is bigger, and even if the amount of work has also increased there is more chances to get time to discuss with the community.

- Until Harmattan we are in these phases of consolidation of the platform, with a lot of novelties that come bundled with new hardware. New hardware means in practice a lot more confidentiality. But once the basics of the platform are well covered then it's easier to discuss about enhancements here and there.

- Also during Fremantle and Harmattan the Maemo SW team plans to bring that open dvelopment for the open source projects, and the discussion on features affecting the open parts should be quite transparent.

- The whole Nokia is moving slowly but steadly to a more open communication thanks not only to the small but relevant successes of Maemo but also thanks to the Symbian Foundation rollout, the assimilation of the Trolltech "spirit" and the overall trends of increasing openness and beta culture in the industry.

- Also very important, in the meantime the Maemo community has earned a big respect not only from the Maemo SW team but also from other parts of Nokia that are seeing that there is something unique going on here.

Bigger volumes would play a big role as well. Those of us swimming in bugs.maemo.org know that it's remarkable that a feature request gathers more than 50 votes. However, if we go to an average product manager that number is anything but impressive.

Promoting the more the current voting feature in bugs.maemo.org would increase the numbers. Having a more user friendly tool like Ubuntu's Brainstorm would increase them even more? We have good reasons to think that Fremantle and Harmattan will bring a lot more users to this platform, being the average profile less geeky but still heavy Internet users, social and open to get involved in exciting stuff.

All this makes me think that indeed a separate and very user friendly tool would be helpful. But it's more work, it's probably also a new engine, probably new headaches... and this is why we (all) need to be sure that this is the right thing to do, and do it well.

One comment, my gut feeling tells me that if we have a tool for feature requests, all requests should be handled there. This gateway between Brainstorm and Bugzilla sounds like too confusing to users and even our own product managers or developers in charge. But maybe I'm wrong. Anyway th first decision is whether a new tool would be needed or not.

Re: Bugzilla or else to handle feature requests?
 

Yes, I definitely feel we are moving in a positive direction (if slowly :(), I've certainly been very adamant about that fact to doubters, my point was merely to illustrate why people haven't been voting in the past. Whatever improvements are currently taking place, there's 2 years of inertia in the wrong direction to overcome first.

New hardware doesn't explain why so many perfectly valid and reasonable enhancement requests and bugs that were filed right after the first releases of OS2008 went totally and completely ignored until the clock for new OS2008 improvements ran out and they were simply WONTFIXed.

Not getting any communication for a while is one thing, but not getting any communication for a while until your bug is simply WONTFIXed for no reason other than Nokia's own negligence is a thousand times worse.

Re: Bugzilla or else to handle feature requests?
 

Two elements to consider here:

- In general, enhancement requests made after a final release won't make it in subsequent maintenance releases, since they concentrate on bugfixes or new features that were planned well in advance. One problem specific to these days is that the jump between major releases (Chinook-Fremantle) is being longer than usual.

- The size of the team in the Chinook times is simply not comparable to the size of the team nowadays, and as you see me insisting here and there we are still hiring. This means more people to process those enhancement requests, consider them in the context of our roadmap and plans and discuss them openly.

If you post examples of wontfixes in the lines you mention perhaps I will be able to come up with more reasonings. We are far from perfect, but I think we are far from unreasonable too.

But you have a point, totally. Brainstorm and silence simply don't match. Don't worry, there won't be any Maemo Brainstorm if the product managers don't commit to take care of the feedback and include the tool in their routines.

Re: Bugzilla or else to handle feature requests?
 

In no particular order, certainly not complete, and largely off the top of my head:

https://bugs.maemo.org/show_bug.cgi?id=2742
https://bugs.maemo.org/show_bug.cgi?id=2496
https://bugs.maemo.org/show_bug.cgi?id=2504
https://bugs.maemo.org/show_bug.cgi?id=2425
https://bugs.maemo.org/show_bug.cgi?id=2513
https://bugs.maemo.org/show_bug.cgi?id=1034
https://bugs.maemo.org/show_bug.cgi?id=1675
https://bugs.maemo.org/show_bug.cgi?id=2318
https://bugs.maemo.org/show_bug.cgi?id=2772

These are only the bugs that somebody (read: Andre) has taken the time to actually communicate about, I'm sure there's dozens of others that may never get an honest WONTFIX, but wont be fixed all the same. . . .

Re: Bugzilla or else to handle feature requests?
 

This thread is about how to handle feature requests and now you are mixing with bugs. A different battle even if in bugzilla they are so close. Still:

The common denominator of these bugs seems to be: won't be fixed in Diablo but won't be a problem in Fremantle because XYZ is refactored. The teams have to negotiate between the time they invest in the old components to be discontinued or building the new components with the fixes build in. In case of doubt they move forward to the next release, yes. Hopefully releasing early SDKs helps rising those issues before, while the teams are still investing most of their time in the current release.

These are enhancement requests fixed in Fremantle. Not in Diablo, again because the related components are being refactored and it would imply doing the work twice (while not doing something else new).

This is an enhancement request (potentially a bug) on a component discontinued after Diablo. The new component probably will have it integrated. Same kind of story.

So basically, all those requests will be satisfied in Fremantle even though they get wontfixes in Diablo.

Andre does his job as I do mine and others do theirs. Even if Andre is not a Nokia employee, he is being funded by Nokia and gets a good salary to be as efficient community bugmaster as he indeed is. As said above about the feature requests, in order to have a Brainstorm working the product managers need to be directly involved, agreed.

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

Are we more worried about motivation, or results?

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

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...

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle 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.

Re: Bugzilla or else to handle feature requests?
 

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.

Re: Bugzilla or else to handle feature requests?
 

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