I thing a roadmap might be a good idea... I also think that now is not (quite) the time. Leave the developers "heads down" (working hard, not looking up from their work). Picking through possible features to figure out what makes sense to do and not to do is *very* time consuming. That was why I boiled down the GE list to a short list of easily chewed morsels. That took my probably 100 hours of time, BTW - to read every email from the past 3 years or so and condense them into that list. Once that is done, the developers have to look at each one, decide if it should be done, think about how to do it, how long it will take and how it will impact the rest of the system. Believe it or not, there is no one else who can do that work. I suspect that it will take probably a month or two for all of those things to be decided, although that is probably optimistic. Then we need to figure out who wants to do what, what will make it into what release, how we want to define the next release, who handles bugs for each thing, etc. The R2 planning process is going to be long and arduous, I have every belief. Distracting developers from R1, right now, to have huge discussions and brain bashing sessions to figure out what R2 should look like would be a major distraction. On second thought, I won't even say for sure that a road map is a good idea. Maybe a "next release plan" might be a good idea, along with a "these were good ideas that we don't want to do for this release for time reasons". But a map is a well defined "promise". I vote with Fred Brooks - we can't accurately predict further than about 2 weeks into the future where code will be, so trying to predict the future in terms of features needed, release dates, etc. is probably a bad idea. It seems to me that telling people what we are working on is probably a good thing. Guessing what direction we might want to head in at some future point is probably less of a good idea. On 2005-07-27 at 05:07:42 [-0400], Helmar Rudolph wrote: > Mat Hounsell wrote: > > > From a marketing perspective; rather than just "A release will have X" we > > might be better of documenting "X is at S stage and targeted at release A" > > and "Y is at T stage and targeted at release B". > > > > Hopefully we can attract developers by talking about cool features coming. > > That's the type of thinking that IMHO Haiku needs more of. Nice one, Mat! > > Some on this list may now jump in and shout "vapourware", but I don't think > that's justified. > > Effective and efficient communication to followers and potential new members > is paramount. > > In addition, I suggest more regular updates from the programmers. While at > Opera I suggested to task someone with being a "runner" - someone who goes > from coder to coder and quizzes them about updates, snippets, stuff that > could be of interest. He would then compile that info and publish it, given > that the coders themselves wouldn't do that job. > > Giving away secrets? Well, I think it was Howard Aiken who said: "if your > ideas are any good, you'll have to ram them down people's throats." > > Helmar