View Single Post
benny1967's Avatar
Posts: 3,790 | Thanked: 5,718 times | Joined on Mar 2006 @ Vienna, Austria
#12
My problem with brainstorm is that I'm a 1|0, black|white person. That's a bad thing for brainstorms in general.

I also have to admit, before I write on, that I prefer bugzilla a lot over brainstorm: Bugzilla is easier to handle. You can search it easily. You can see status, dependency,.. plus, and that's the biggest advantage, you usually get some direct input from the Vatican. At some point you'll know: They'll do it in PR1.2. Or: They don't think it's useful and will never do it. A WONTFIX is a good thing because you'll know what's not gonna happen.

But there's two things in particular I simply don't understand (even though in principle I think I could like the idea... someday):

1) Brainstorm vs. Bugzilla - "no brainers"

There's this rule of "very specific and no-brainer enhancement requests" for bugzilla. Sounds nice. But then there's also bugs like 1889 (camera support for flash plug-in) that from my POV couldn't be any more specific than they are: Somebody switched flash support off for privacy reasons... and the bug is about re-enabling it. It's not the big "How to get camera support for the Flash plug-in"-discussion. It's plain and simple: Re-enable it. You took it away, put it back in. Will you? If not, WONTFIX.
I don't see how such bugs can be reasonably transferred over to brainstorm if there's only one possible solution, nothing to discuss or suggest, only those who say "yes" and those who say "no". - There would be something to discuss if the original bug would clearly be commented upon as WONTFIX. Then a brainstorm would make sense. Like: "Nokia will not let us use the cam on cam4.com. - How can we work around this? Any ideas?" - Do you see the difference?

So for me, brainstorm is a place where people can discuss the "How": Solution #1, solution #2, solution #3, then vote for one of them, discuss on t.m.o. etc.
If there's no reason to discuss a "How" (at least as long as Nokia doesn't comment on how they're gonna handle the problem), if it's as simple as "Please enable feature X in application Y" - what good is brainstorm? Why go to maemo.org and discuss with the community if I want Nokia to change code?

2) Responsibility, process, workflow,... or whatever you call it

Bugs are a beautiful thing. You report them, others vote, you're asked for more input, and eventually they'll tell you that they fixed it - or that they decided not to because Diablo's dead. Whatever. But the point is: When I open a bug report, I talk to somebody and get an answer. I start something that will be worked upon (reliably) and come to an end, even if this end is WONTFIX.

Brainstorm is different. You write there - and then what? Who is responsible? Will somebody look at it and say: Hey, this is a good idea, let's do it? Who? Is this something that should be done by community members? Do Nokians read the brainstorm? If solutions are discussed and solution #1 has 2 votes and solution #2 has 50 votes - is it OK to close the brainstorm as soon as you implemented solution #1? (Because somehow some kind of solution was implemented, just not the one people wanted.)

I don't understand it. I remember I proposed some solutions here or there, but I don't even follow what's going on on those pages because I don't know what to expect.
With bugs it's different. I actively follow many bugs. Because I know that there is a certain lifecycle of a bug and its story will eventually come to an end... either a happy end or not. Bugs are like books or films. Brainstorms, at the moment, are like advertising folders I get from the local supermarket every now and then. They don't have a timeline.... nothing happens... and you're not sure if anything should happen at all.


That's why I'm unsure about brainstorm. Maybe if somebody could help me about my point 2 (responsibility, workflow), I'd get a better idea of how to use it.
 

The Following 13 Users Say Thank You to benny1967 For This Useful Post: