Roadmap development

A few weeks ago, this community adopted (if only passively) a feature
roadmap[1]. This was a very high-level document. *Very* high-level. I get
the sense that all the items on it are backed up by some at least
func-spec-ish ideas in the minds of one or more developers, and some of them
may even have design thoughts behind them. (We in NYC even traded some of
that information as we discussed the roadmap.) But I also get the sense
that much -- perhaps *most* -- of this knowledge resides in our individual
heads rather than in a place where others can comment, refine, critique, and
even ultimately take up the baton of implementation. This works against our
stated goal of encouraging more contribution from non-core-committers, and I
want to see that remedied.

But how? And how can we fix this without causing the 1.7 work to grind to a
halt?

I think we need to invest *something* in this effort today, or it will never
get kicked off. At a minimum, we should ensure that there are issues filed
for every roadmap item. Even if some of those issues become umbrellas for
smaller task issues later, at these there's something for the public to
follow. I will undertake this task myself as a first step, updating our
roadmap page to point to issues for every item. If there are notes/
documents that can be referenced from the issues, I'll try to locate and
record those facts in the issues, too.

But what beyond that? Would folks benefit from issue keywords such as
"needs-func-spec" and "needs-design"? (I'm a big fan of keywords like this
because it facilitates posting static URLs: "Click <here> to see all the
issues that need their functionality defined better.") Oh... heheh, we
already have a "needsdesign". Cool.

Thoughts?

-- C-Mike

[1] http://subversion.apache.org/roadmap.html

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand