Mailing-List: contact forrest-dev-help@xml.apache.org; run by ezmlm
From: "Steven Noels" <stevenn@outerthought.org>
To: <forrest-dev@xml.apache.org>
Subject: RE: [RT] my Forrest dream-list
Date: Wed, 20 Feb 2002 23:34:41 +0100
Message-ID: <OKEDLKGMIPDOCJHOEDEFKEKKCPAA.stevenn@outerthought.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
Importance: Normal
In-Reply-To: <3C73EC92.8ECC8B36@apache.org>

Stefano wrote:

> So I need to give more focus.
>
> I call this a 'dream-list' because a wish-list is not enough, but as Sam
> once stated, "some people have no vision" and even if I believe the
> people that subscribed here are those *with* the vision, it doesn't hurt
> to throw more dreams in and get people excited.

Huh? I was just starting to get sleepy ;-)

>                                   - o -
>
> Ok, first of all: "it hurts my spirit" (I should TM this) to see the
> apache web sites with such a *poor* information infrastructure. Just
> look at sourceforge: it's not the best site of the world, but gives you
> lots of tools and information that we currently don't have (or have
> hidden someplace).
>
> I want Forrest to be the development infrastructure of your dreams,
> something that you'll be proud of showing your boss and say "if only we
> had this in place, we would save big bucks" so...
>
>        Dream #1: Forrest should make Sourceforge look obsolete.
>
> So, in order for this to happen, it must be dynamic.
>
>       Assumption #1: Forrest is a dynamic site.
>
> The staticity of apache web sites was mostly due to the quest for heavy
> mirroring, Forrest should allow mirroring, so
>
>         Dream #2: Forrest should reduce xml.apache.org bandwidth use
> dramatically
>
> and
>
>         Dream #3: Forrest should automate mirroring in a simple and easy
> way.
>
> My idea is to use the 'command line' features of Cocoon to generate
> static snapshots of sites and produce mirrors directly using a sort of
> rsync or other mean. Anyway, the goal is to make sure mirroring is as
> easy as possible. No, easier than than that.

Doing CLI where appropriate sure would alleviate the issues I listed with the
graph logs in my previous message: +1

> Ok, but what should Forrest give us:
>
> 1) coherence: all the site should look coherent, same graphics, same
> look&feel, same information in the same locations, coherent and nice URI
> space (build to last! so that broken links are reduced!)
>
> 2) structure: the site should look professional, the structure should be
> flexible enough to fit every need but solid enough to guide users
> browing and developers adding resources
>
>
> Ok, but the best thing is 'functionality': everything you wanted to have
> in your project web site.... here are the things I've been missing:
>
>  1) logs and community rating: I want to have numbers to judge the value
> of a community/effort

Downloads, number of commiters, numbers of people subscribed on the users/dev
list, numbers of mail messages / week on these lists, CVS activity...

The kind of parameters I use to 'judge' an Apache project I haven't been looking
into before. Unfortunately, not all of those are easy to get hold off.

>  2) built-in search engine: users much have a simple way to find things

Lucene sure is an option, but maybe we can bug Google to index the
xml.apache.org pages (even) more often, and reuse that search functionality
instead.

>  3) user-writable pages: people should have a way to add things to the
> pages.

As in WikiWiki? Hmmm.
As in 'Comment on this page' deferred to some discussion board?

I'm quite opinionated (as Stefano already knows ;-) on the how and when of
in-place-editing XML content across a web interface, so please explain what you
mean here.

>  4) short bios for the project committers, with pictures: gives a better
> sense of community. Having a weblog there would be great.
>
>  5) news, announcements, events and project calendaring: the news and
> the annoucements will generate a RSS feed, events will be aggregated

You can count me in for the RSS stuff.

> into a project-wide calendar, or an effort-specific calendar, the events
> will also be overwritten on the logs, to indicate how logs were
> influenced by the events (say, a release or a new committer added)
>
>  6) book-like PDF versions of documentation: easy to print out docs.
>
>  7) integration with GUMP: dependencies, runs, committer that broke the
> run
>
>  8) javadocs seemlessly integrated with the documentation and with the
> search engine

Java Doclet? http://www.sun.com/software/xml/developers/doclet/

>  9) mail archive seemlessly integrated with the search engine (I should
> look for something and get results from either docs, javadocs or emails
> messages)
>
>  10) coherent-looking CVS view
>
>  11) document translation using Google translation services
>
>
> Ok, I think it's enough for now.
>
> throw your comments in the lake.

Swimming :-)

</Steven>