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 <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
