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.