[...]
So it was not meant.

The benefit of a solution based system is that every idea is handled itself and no one is missed. And it does not only work with solutions which could all come true.
It should be easy to reject a solution because of "other solution for this problem got more votes" or "easier solution taken / to expensive".

This could also based on a automatic system. Only "Solutions" with more than 10 Votes and 66% positive of them could get in the proposal workflow. The other ones are rejected automatically. (by vote of the community)

When a Brainstorm is finished in real life. You have always to made the decitions on a Solution level. So the Brainstorm system and the workflow should work the same way.

The old question. One Brainstorm, 19 Solutions. The first, popular solution is implemented. So the Brainstorm reached the target? What about the other 18 solutions?

With this system it shouldn't be a problem to decide: "We would implement Solution #1, #3 and #8."
The rest of it are overlapping, blocking with one of the implemented, to expensive or some of them are still good ideas for the future.
I'm sure. It's going this way at the moment. But no one could see it at the current Brainstorm in a clear way.

To make it easier for everybody:
Call it Idea instead of Solution. Call it only a solution when the implementation is on scedule.

Beautiful. Sounds like semantics but as simple as it seems, semantics can trip up the best of processes.

Again, this supports the concept of solutions (or ideas) have semi-independent lifecycles.

We need to think of the model as project/task, and ask at each step: how would a project manager (or management tool) handle this?

Ack-- I really am dense. A picture just popped into my mind of how this should look, especially with regards to my own misunderstandings. I'll try to draw it up and post tonight.

I like it!

The way I was thinking was around the item I opened at the weekend:

The aim is 'improve the calendar'
The suggestions that follow are proximate objectives.

When the idea-shower stops (and we start getting fewer/no more suggestions) we move to methods/feasibility/resources. At that point someone has to take responsibility for moving on from generating ideas to finding solutions. In this case I can think of at least three methods, the choice from which which would depend on available resources. Which of the suggestions is feasible is going to depend on the method, which is in turn dependent on resources. (I'm not a coder, I have only those resources I can cajole from others).

The end result of the exploring, analysing and solving is that the community may produce a patch for the existing calendar, incorporating as many of the suggestions as is feasible. Or we may decide to create/enhance a second stand-alone calendar (One has already been suggested) so that it can be seamlessly integrated to Maemo5. Either way, we will have 'improved the calendar experience' even if certain individual objectives are not met.

In the worst case it will be found that the only method open is to persuade the clever people a Nokia to do this, in which case I shall brovrilise the suggestions down to a set of individual UI bugs, and submit them as such (and Andre will hunt me down with a shotgun). I will still have done my best to 'improve the calendar'.

That's why I like starting the process at the top with a woolly aim, then setting objectives, then looking at the methods/feasibility/resources. If you start at the lower level of objectives, you miss a great deal of creativity, and generate a sense of 'we opened all these ideas and got nowhere'.

The trick is to have someone pushing at the right points. Whether that's the task of the Brainstorm mods or the aim-starter is debatable: I think it should fall to the starter, because I think people can follow through on a good idea even if (like me) they have little idea how they're going to do it.

I think Kathy and I are sharing a brain.

The thing with TRUE brainstorming is that "no idea is a bad idea". We need to make that a religion.

I've done this in real life many times and not once did we ever start off hyperfocused. That came during the Norming stage.

True brainstorming means that not only can wild ideas irrelevant to the core topic pop up, they should. That's actually a hallmark of a receptive, empowered and creative group. It is up the the brainstorm facilitator(s) to make sure those potentially-orphaned ideas get grafted onto the appropriate tree or branch (depending on granularity) later.

The challenge, of course, is to make that work here. To help:

- identify a Brainstorm champion overall (is that Quim? should it be?)
- enable Brainstorm moderators to work both sides of the fence (I can't)
- draw up a model (I will start that)

EDIT: it also occurred to me that we should distinguish somehow between ideas that apply to current conditions vs those meant for future platforms, etc.

Short-circuiting the current brainstorming activity (since it seems to be converging on a consensus); the politics and technicalities of whether to change the Brainstorm Midgard module into more of a bug-tracker or whether to change a bug-tracker into more of a brainstorm and project management soluition will need to be looked at.

This also fits in, to a large extent, with Stskeeps' suggestion of a methodology for community development:

http://talk.maemo.org/showthread.php?t=41092

Ah, nice. Havent noticed about it before. Thank you.

So, naivly spoken there could be in the future a bug tracker, a Brainstorm system and a project management system?

COOL!

Parallel developed with a lot of energy and overlapping in some points?

For each system other persons responsible or the same guys?

I hope everybody would understand what I'm trying to say. We dont need 3 totally different systems. We need in the best case one big solution.

The Project Management should be a system after brainstorming. And the bugs should be a system to send something back to the project management system afther something developed has leaved the project management. One system have to work with the other. Integrated or with some kind of interfaces from one system to the other. But it should look and feel like one big system. Not totally different like Brainstorm and Bugs at the moment.

After but connected.

Man... it seems we may be growing up.

This thread has moved in a direction where afaik we are allready heading. => Integrated System - Bugtracker functions for dependencies and so on...

But what could we do for now to make this a better place? Access for the mods to brainstorm to have a hand there and make this subforum thread moderated would be my technical start. For a visible start I'd like to delete as many posts and merge as many posts as possible to get the discussions down to relevant stuff, maybe split out hijacking posts to new threads in the other fora or something alike would be handy too.

What do you think?

chemist I wish I had a general answer.

For me, I'm going to quit starting Brainstorms until I have a better idea of how it should work now and/or we have a better implementation of the tool & process. I'll do what I can to moderate in the meantime but I have to confess, I still am very fuzzy on how and what I should be doing...