I second this thought, being able to extract a single solution from those "enhance them all" proposals would be strike against loosing good ideas! Opening new proposals with the "hot" solutions for one topic as digest of those "enhance them all" items. (may call it "move to new proposal allready [Under consideration]"-process)

People try to merge topics to one as they have dependencies, having them not merged but creating dependencies and proper linking like "this bug depends on bugXXXX" would be another feature I like. so workflow could be - split "enhance them all" items into topics but show dependencies and keep the 'enhance them all' items to show what is already proposed and where to find. Structuring in categories maybe? Not like forum categories, more like a 'mother' proposal with 'children'.

I'm not sure I have the same understanding of 'brainstorm'. In my experience a brainstorm does tend to be something wild and woolly that generates a shower of ideas. After the 'brainstorm' bit has finished, you start that hard process of picking over the ideas to assess them for feasibility, resources and what methods are appropriate. At that stage, some of the ideas will get left behind, because they're not feasible, need unavailable resources or simply don't fit into the method adopted for the overall process. I don't think I've ever been in a brainstorm event that didn't end up leaving some ideas in a puddle on the floor for one of these reasons. If they were particularly good ideas, they generally get picked up again in another process. If you want to create a procedure for ensuring that good ideas that don't fit one process don't get forgotten entirely, that would be excellent.

But the feeling I get from this discussion is that you want to start the process further down the process, after the actual 'storm' has finished, so that you can concentrate on the feasibilty, method and resources aspect.

If that's what you want, fine - but I'm not sure you should call it 'brainstorm'?

you are just right, intention was not to split out the ideas taken for development and keep the related, it was split out the ideas taken plus the related but leave the unrelated still active.

For example, you got an "enhance phone-app" proposal that got everything in it from answering to recording calls and so on.

You split out the whole solutions (brainstormed solutions) created for "recording calls" and put it into a new but allready [In development] item showing what was picked for development and what was not. Still linked from the mother item so people know that it is there and work in progress.

The "enhance phone-app" item now shows everything but recording features (they are linked now) and is still active as [Under consideration] for the remains.

Why not simply "pick" the logical implement-worth and voted solutions for processing and reset the brainstorm? change the name too if it's necesary...

Bingo, thank you Kathy!

You just nailed the root of my continued confusion.

IMO Individual solutions need a way of being escalated independent of the proposal or other solutions. The proposal, being a parent object, would be in an Open state until all child objects were resolved one way or another.

That's what I had thought we were going to with the last work done on the Brainstorm system. Guess I misunderstood. But IMO that's the way to do this: allow child objects to have independent states and lifecycles.

Either than, or we're going to have to go to one proposal, one solution-- and that introduces its own set of problems.

Bottom line, this needs to be treated as a true workflow/project management process. Right now it seems to be in some sort of quasi state that's not viable.

After Kathy confirmed my understanding of what an actual Brainstorm process is supposed to be, I did a little more thinking about this. I have a suggestion:

- Start Brainstorms here, instead of at the formal Brainstorm site (Forming stage).

- Foster discussion here (ie, true brainstorming) before even creating a formal proposal.

- At some point, the proposal creator and/or moderator(s) declare the Storming portion over and begin the Norming process (creating the formal proposal, adding solutions)

- Voting is opened to the community along with further discussion

- Voting is cutoff at some point and prioritizing done for action (Performing)

At the moment I don't know how to define cutoff points... number of posts? Time elapsed? Consensus? Lack of steam? Not sure. But I think something like this better matches real life brainstorming and manages the process better given the lack of proper structure and dual "homes" of the system tools...

That's fine in theory but how do we prevent it from becoming utter chaos if we aren't imposing some kind of higher order on the threads here than in the rest of Talk?

I still think we need some kind of limit or quota to focus efforts enough to actually make headway.

We have chaos now. I realize what I am suggesting may not diminish it, but if we found a way to make cutoffs work, it should make the chaos more manageable. I think.

*Mumble mumble - this is just random reflections while I reflect them - not fully thought through yet...*

We seem to be missing the element of responsibility. Who is responsible for seeing a project through? Right now, Brainstorm is a place and a process where anyone with a good idea can throw it out there and see if anyone else is interested (which is good) but they don't have any responsibility for what happens next (which I think is maybe not good). This is especially noticeable when the ideas are coming from people who lack the skills to enact them.

Right now, I have two 'pet projects' as I would see them: I don't actually have the skills to make them happen - but I do see it as part of my responsibility to see them through and keep them happening, find skilled people, co-ordinate, encourage, enthuse, test, etc. To me, that's what I can put in (in the absence of any actual ability), and a responsibility I take on when I launch the idea. It's one of the main reasons I didn't start a Brainstorm till this weekend: I wasn't in a space for the responsibility. In addition, it will be up to me in my head when I feel that they've gone about as far as I can take them - if other people pick them up and run, that's fine - this isn't meant to be exclusive in any way. I won't stop till I feel I've completed the process - even if the end is some project equivalent of WONTFIX.

My feeling is that we have lots of people who think generating ideas and asking for stuff/features/apps is all they need to do and then it's someone else's problem. Can we somehow encourage people to take responsibility for their projects?

When it comes to things where the implementation comes down to "would Nokia please consider implementing xxx", either becuase it's a closed component or it's basically driven by Nokia staff, I'm not sure how to take responsibility for it as an outsider after the ideas stage.

I've avoided much with Brainstorms so far because I feel like some have said, that it could be a /dev/null where ideas go to die.

And also because my ideas so far have tended to be "the following 30 little UI tweaks would make it that much better" and I get the impression I am supposed to create 30 separate brainstorms? That seems way too likely to get bogged down in non-productive committee-itis ("little tweaks") and unlikely to achieve coherent results anyway.

Some of my instincts at the moment tell me I should fork Fremantle to make a personal version, and just patch a few things to see if I like my UI tweaks after all, and if so make them available to others as patched packages. That may be a more direct route than slow, scattered exchanges on t.m.o.

I'm not sure if that's a good idea or not, and I'm sure it isn't that easy, but it seems more useful than /dev/null. Especially with the uncertainty about whether discussed changes will make their way to the N900 anyway, or only to future Maemo6 devices which I may not want to buy (due to the DRM or other factors).