On Mon, 2005-01-03 at 09:29, Matthias Bohlen wrote: > Hello Martin, > > Monday, January 3, 2005, 12:41:54 AM, you wrote: > > >> [CB] I think we should place them in CVS in the documentation section with > >> everything else, do them in the consistent xdoc format. Of course new > >> features should be added to JIRA as well. > MW> Proverbial problem this. First have to agree what the consistent format > MW> is and a process to manage the changes. Yes to cvs. Personally I would > MW> prefer using docbook/xml since this has tags to support documentation > MW> and has maven support ... > MW> http://maven-plugins.sourceforge.net/maven-sdocbook-plugin/ > > the design docs I have in mind are of temporary nature - they are more > or less a discussion between us about how to break a large feature > into smaller parts, assign the responsibilities to components and > build a work breakdown structure for implementation. I want to keep > the amount of time that we spend on these documents as low as > possible. They will contain text, a few diagrams and some sample code. > And they will have a chapter structure. That's it. Just sparkling > water, not champagne! > > Later on, when implementation has started, these design documents will > tend to become outdated and will be replaced by final docs at the end > of the process. > > So, maybe XML is a little too much overhead for a "sparkling water" > document that will become outdated, don't you think so? More than > that: When doing design, I want to structure my thoughts by writing > down words and images - authoring XML tags will distract me from > design.
okey doke, why not set up a wiki, jspwiki is quite a nice implementation. > > Is there a simpler way to do it? MS Word, for example? At the end, we > can extract chapters from the Word docs and put them into docbook/XML > if we want to, or we just throw away the old Word docs, then, and > write new and beautiful docbook/XML docs. > > About the process for the changes: I'd like to let us be inspired by > Extreme Programming (replace "feature" by "story" if you want): > > 1) Describe the feature in Jira. > 2) Write a short document to spark the design discussion. > 3) Meanwhile, finalize 3.0. > 4) When 3.0 is final, create a branch for 3.0 maintenance and > continue development for 4.0 on the main branch (HEAD). > 5) Discuss the design and develop a work breakdown structure. Record > them in the design docs, too and check them in each time. > 6) Approve the design and the resulting work breakdown > structure on the mailing list by mutual agreement. > 7) Play the "planning game": Estimate the amount of effort for each > feature and collect several features for a release that makes sense > to the users. Set a name and target date for each release. > 8) Plan iterations, i.e. divide the release into several > (four-week?) iterations and set the goals for each iteration: which > feature(s) should be working at the end of which iteration. An > iteration contains analysis, design, test, implementation and > documentation and will end with working, tested, proven code. > 9) Start iterating, measure progress and adjust the plan > after each iteration. > 10) Release the features you have reached in several iterations. Sounds good. > > Can you agree on this or would you prefer modifications? Carlos, > Wouter, Chad? > > Cheers... > Matthias > > --- > > Matthias Bohlen > "Beratung, die Projekte erfolgreich macht..." > > Internet: > http://www.mbohlen.de/ > [EMAIL PROTECTED] > > Post: > Luise-Albertz-Str. 25 > D-53340 Meckenheim > > Tel: 0170 / 772 8545 > Fax: 02225 / 945189 > > ------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Andromda-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-devel
