Wholly agreed.

The idea of a maemo.org Brainstorm was inspired mainly by two existing and successful experiences:

http://brainstorm.ubuntu.com/
"The Ubuntu community has contributed 17373 ideas, 106018 comments, 2246674 votes"

http://www.ideastorm.com/
"The Dell Community has:
* Contributed 13,477 ideas
* Promoted 712,580 times
* Posted 88,706 comments"

Browse those sites and you will see they quite match the equation "one problem = one brainstorm"

For entropic discussion there is the whole Talk already. Choose the most appropriate forum to kickstart a discussion. if someone wants to push a problem or a feature request with the clear determination to find the right solution, then Brainstorm is for you.

I think we should ask Oskari directly about the possibility to move existing solutions to other brainstorms, reorganize the meta-brainstorms and have a tighter filter in the jump from Sandbox to Under Consideration.

Doing a bit of math, and if I'm reading correctly the stats above::

One Ubuntu brainstorm takes an average of 6,1 comments and 129,3 votes.

One Dell brainstorm takes an average of 6,5 comments and 52,8 votes.

Maybe this average is actually not that frequent, and in fact there is a bunch of proposals with very few votes and comments and then "real average" active ideas with, say, double comments and votes (12 comments and 260/100 votes).

In any case these numbers reflect the profile of focused discussions gathering a significative amount of votes way above the number of comments.

Oh, okay. I tried to create a diagramm the last hour and finished it only 2 minutes ago.
But now I saw qgil's new post and have to familiarize oneself with his stuff.

So, okay. I just post my work without many comments.

My idea is not so far away from our current system. The only main different is at the moment the "in develop" and "implemented" state are at the Brainstorm level. At the moment any kind of posted Idea's from users in the Brainstorm System are immediately Solutions. We should change this.

This is related to my Post #61:
A not Implemented Idea could never become a Solution. It will still be a Idea! (as in real life)

This wouldn't fix all of our current problems. The main thing is still the posibility to move and rearrange Ideas from users to other Brainstorms, split them. Manage them. I fully agree. A "improve Maps" Brainstorm is awful to track. (and also to Vote)

It's even already handled this way. Here a example: portrait_mode_input
The decistion was on Solution Level. But the Users can't see it how it works. And a justified claim was to improve the feedback to the users.

Very nice Helmuth... but I'm going to avoid looking at it carefully (I'm thanking your effort for now). I want to finish what I have going, then see how close we are.

Uuuh... SOOOOOORRY! My fault.

Do not let yourself get confused by me.

It's only a fast drawing of my propagandized opinion here in this Thread. If you already read it last week carefully you know anyway everyting in this drawing.

But, let's compare when you're finsihed the master plan.

I guess you've got first a better toolkit and second a more precise imagination about the communication behind (to Nokia, talk, bugs).

Helmuth, no problem! I'm glad you worked that up!

Nice Helmut!

What about dependencies? 2 Solutions block each other when working on the same code in different directions, but what about dependencies? Another brainstorm needs the "not accepted" solution and not the one in development; accepted solution was just easy to implement and screws the other brainstorm which has much more interest, more votes. And that just because developers didn't recognize, other solutions also depending on the now blocked brainstorm where already implemented just to meet dependencies and are all screwed. This would mean to fork the program, but the new program has other package- and version-dependencies as the older fork and needs a lot of space for those...

just an example how it could work... not
this is worst case I agree but it could happen...

some brainstorms already depend on things not implemented yet, not even in development.

well its up to the developers but knowing details wont slow them down.

Brainstorm needs to be a tool for the folks to show developers what they like to be solved and a tool for developers to track work in progress. At this point normaly the garage would come to speak but the link is missing... Should garage and brainstorm be connected... all together? Maybe bugtracker also?

I am confused...

The picture in my head is just huge... lets get the first steps done by hand, a feature to mark single solutions as "under consideration", "in development" as well as "implemented" would be great to start with. So not the brainstorm changes state but the solution! (thats what Helmut says isnt it?) also a direkt linking for dependencies, for solutions and brainstorms, should be setup. (Maybe a bugtracker as brainstorm-solution backend?)

I hope I did not disturb with that kind of braindead post, its what left my brain on its own without further organising it.

First, let me confess I've little practical experience of the Maemo brainstorm infrastructure.

I ventured in a little around the time I first found maemo.org, and found it confusing. Since then, I've tried to look on a couple of occasions when it was unbearably slow (I gather it's faster now but haven't tried) but abandoned this in the face of browser timeouts.

Despite this, I have enjoyed an occasional dip into this thread! - it's exciting to see people sincerely grappling with such difficult issues and processes.

Anyway, I wanted to post here just to suggest considering a wiki environment as a repository for brainstorm material, either as a prototype, adjunct, or an eventual replacement for the current system.

The thought, essentially, is that by applying a layer of ("socially enforced") conventions over the top of wiki functionality, a brainstorm system can adapt better and more quickly to process improvements than if these improvements have to go through a software specification / design / implementation cycle. There is a very real danger there of getting something that is costly, tardy and unexpectedly dysfunctional.

I think if the edit rules are clear, the brainstorming community and on the whole, the maemo community at large, easily meets the required level of responsibility. (That's not to say a little bit of chaos is always a bad thing.)

The idea of a responsible person (for a particular brainstorm) also seems to fit rather well here - if a convention could be agreed that a given individual has editorial control of that brainstorm's wiki page (and responsibility for ensuring it meets the requirements of the operational system of conventions that is agreed.)

The whole business of linking to or including sections from other brainstorms, merging, and the like, can be done easily (if manually) by normal wiki edit processes.

Having conventions for layout and process that do not need to be specified and implemented in software creates the possibility for rapid experimentation and (mostly) easy reversion without the need for developer time.


It's quite interesting to compare these.

The ubuntu one is, I guess, structured pretty much similarly to the maemo one? The Dell one seems (on minimal inspection, admittedly) to be an article/comments system, and seems to exhibit quite a lot of the entropic qualities which people want to avoid here.

Though the structure of the ubuntu site is more similar to maemo's, it seems that situationally the Dell one has more in common, given that (well, I'm guessing, anyway) ubuntu is more, shall we say "amenable to democracy", whereas Dell, like Nokia, is a big, mostly hardware, corporate with an internal infrastructure that has had less exposure to processes typical of the open-source culture.

It would perhaps be interesting to research the actual effectiveness of these different approaches in creating solutions. I did notice a quote on the Dell site, that of 14th Dec last year they had "implemented almost 400 ideas" out of "over 10,000". That is actually a rather impressive 4% (I'm not being sarcastic), unless I did my arithmetic wrongly.

Guys, there are basically two useful approaches:

a) We agree on the perfect scenario and have the means to implement it reasonably fast.

b) We agree only on a pragmatic next step but have the means to execute it.

Less useful combinations:

1) We agree on a perfect scenario but we don't have the means to implement it.

2) While spinning around 1) we don't even come up with a pragmatic and feasible next step we agree upon.

And the worst of all:

n) We end up in such complex discussion that even the core promoters of Brainstorm get blocked and are unable to even get the whole picture.

At the end this is simple: Brainstorm is a tool that helps us finding and discussing problems that matter to the community and their potential solutions. Then developers can look at the Brainstorm, help finding out the good useful solutions and eventually implement them. That's it for today.

So here is a proposal for a pragmatic next step: work on the meta-brainstorms to convert them in focused brainstorms. For that the most important feature missing seems to be Can't move solutions to other brainstorm proposals

About adding brainstorm dependencies, bug tracker background, etc... Isn't this falling in an over-engineered tool? Remember: this is for discussing and highlighting potential solutions. The implementation comes from another way.

For instance, look at http://maemo.org/community/brainstor...all_recording/ : 3 ideas, two of them highly ranked. But then comes a developer, implements the one that got less votes and worst rank. Still it was the one he could address, he Just Did It and, guess what, everybody is happy now. One brainstorm implemented, mission completed (the call recording work continues, elsewhere) and what's next.

No more, no less.