Ross Gardler wrote:
...
> I've found that encouraging team members to use status.xml as an
> "engineers log book" produces much more complete documentation of their
> actions. Our status.xml file now forms the core of our dev documentation
> since it describes exactly how each action was accomplished, complete
> with class names, method references etc. It also acts as a design
> document since the task items describe how a dev intends to implement a
> feature. Upon commit to SVN other devs have the opportunity to comment
> on the plans.
>
> In addition, the project I specifically need this for has devs working
> on sites with no Internet connectivity so a web based issue tracker is
> not an option. They simply "forget" to keep it up to date.
I had some plans, months ago, about how to redo status.xml.
But because I suffer from volunteeritis [1], it never even started.
Some like status files, some don't... it's mostly a matter of being used
to one method or another, and the number of issues being managed.
status.xml has been one of my wierd creations, by putting todo.xml and
changes.xml together. This has created a file that is too big, and I
don't like it anymore, especially because it breaks the 'one source
file'-'one URL' rule.
ATM I'm more geared towards having a directory that contains all the
project status docs, and an index.html file in the main directory that
links to these. Each of these files coulod be in xhtml or in xml with
embedded css for quick viewing (I had done this years ago for POI, but
it didn't catch on at that time).
In this way each project can have a full range of files for project info:
index.html
project/developers.xml
project/description.xml
project/news.xml
project/changes.xml
project/todo.xml
I tend now to prefer the xhtml source for anything... not sure if it's
correct in this case or not.
> I have a dream of integrating status.xml with an issue tracker and thus
> having the best of both worlds, but it's a dream with no time at the
> moment
Cool, who knows, maybe one day... :-)
[1] http://article.gmane.org/gmane.comp.apache.community/904
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|