I think this is a nice document, but it can hardly be considered as a requirements document. There is way too much *how* things will work as opposed to *what* needs to be accomplished. I don't want to rabble-rouse (sp?), but isn't James simply documenting AntEater? I realize he has glommed onto the workspace concept introduced in AntFarm, but other than that, it looks more like a personal design document.
How should someone with a totally different approach submit their ideas? For example, I think my proposal has merit by being able to handle the concept of a workspace as simply another Task. And an optional Task, at that. Should I produce a more detailed design document similar to James'? Should *all* of the proposal submitters do the same? Why don't we spend a collective hour defining what a requirements document is? I was waiting to see a req. doc before spending my time on a design document in order to make certain I address each requirement fully. jim ----- Original Message ----- From: "James Duncan Davidson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, January 09, 2001 3:29 AM Subject: Updated design docs > I expanded a bit the docs I've been working on tonight. There's more to do > obviously, but what's there merits review and comment. They do go a bit more > into some of the details -- and sometimes in a way that expects you to have > a pretty good grasp of concepts (did I say that there's more to do. :) > > http://www.x180.net/Projects/Build > > Also, I'm on the road right now with intermittent net access and so won't be > turning around mail too quickly. > > > -- > James Duncan Davidson [EMAIL PROTECTED] > !try; do() > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
