>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
On 1/5/01, 11:55:42 PM, <[EMAIL PROTECTED]> wrote regarding Re: 
[midgard-user] Midgard Web site redesign:

> IMO: Bad information detracts from good information. We need to delete
> everything that's dated. 

True.

> >     * Who's who, a listing of project participants and their tasks

> A list isn't a good solution, nobody is going to read a list and the
> people that are doing the work aren't going to recieve their due credit.
> View the following page and click on the colored things, replace the 
build
> information with reports on snippets, features, who is writing them, 
state
> of development, anticipated completion dates, etc.
> http://community.roxen.com/developers/autobuild/pike71.html

While it gives me great ideas for representing nightlybuild reports, I 
have a hard time envisioning what you are proposing. Perhaps I need to 
get a clearer view first.

> >     * Documentation and annotations

> I think we should consider Commentext as the solution for documentation.

At any rate we need to rethink our current documentation method. The 
pro's don't outweigh the cons, at least that is my opinion lately.

> I don't imagine it's feasible to use Repligard in a qausi CVS
> strategy, allowing many people to work locally, commit updates, update
> local instance.

Sadly, not yet. Some discussions about this are going on on 
[EMAIL PROTECTED] Repligard can take up an important role here, 
but in itself it is not enough. Alan Knowles has a versioning system 
incorporated in the framed admin interface, that is also a few points 
short from fullfilling the requirements in named situation. Hopefully we 
will be able to make a combination of Alan's version implementation 
(which is base on CVS) and repligard to address this issue.

> > Replication issues:
> >     * Full Midgard site handled by Repligard

> What happens if we decide to run some applications from the filesystem?
> Will we be able to?

Running an application from the filesystem is not a problem, pulling in 
'old-fashioned' html, or output from cgi scripts is. There is a challenge 
here to keep those things to an absolute minimum.

> Speaking of instructions, how about instructions for the people that are
> going to maintain the site one or two years from now? I hope the new
> site will be friendly and flexible.

Indeed. VERY important.

> If enough of us are on the same page with the need to prune dated
> content and replace it with current material or simply remove it, I'll
> inventory the site and write a report.

I am all for it. Actually, redesigning and developing the site is a major 
project that will take a significant amount of time. I think we should be 
working on the current site in paralel in order to stay current, and 
pruning dated content is absolutely part of that.

Armand.

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to