This project has retired. For details please refer to its Attic page.
Forrest dream list (v0.9)
Apache Software Foundation > Apache Forrest
Font size:      

Forrest dream list


This is documentation for current version v0.9 (More)


This is the initial attempt to give focus to the Forrest project. This summary is a loose collection of items from the forrest-dev mailing list. Please add and re-arrange so that it can evolve into a focus document. The Forrest Primer provides an overview.

These are the email threads and documents that are currently being summarised. Please see those documents for further detail.

Draft dream list

  • Forrest provides a robust technological infrastructure for open software development for the Apache Software Foundation based on ASF software, ASF practices and experience, and modern software design principles.
  • a publishing system for documentation
  • analysis of logs and publishing of results
  • 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 bandwidth use dramatically
  • 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 that.
  • coherence: all the site should look coherent, same graphics, same look-and-feel, same information in the same locations, coherent and nice URI space (build to last! so that broken links are reduced!)
  • structure: the site should look professional, the structure should be flexible enough to fit every need but solid enough to guide users browsing and developers adding resources
  • scalability
  • functionality: everything you ever wanted to have in your project web site
  • logs and community rating: I want to have numbers to judge the value of a community/effort
  • Downloads, number of committers, numbers of people subscribed on the users/dev list, numbers of mail messages / week on these lists, CVS activity... These are the kind of parameters I use to "judge" an Apache project that I have not been looking into before.
  • Graphs of various statistics.
  • Having good site metrics will be a valuable aid to those involved in maintenance and future re-design phases. See some discussion in
  • Built-in search engine: users much have a simple way to find things. Lucene.
  • User-writable pages: people should have a way to add things to the pages. See the thread for more detail on this. FIXME: get MARC ref
  • short bios for the project committers, with pictures: gives a better sense of community. Having a weblog there would be great.
  • news, announcements, events and project calendaring: the news and the announcements will generate a RSS feed, events will be aggregated 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)
  • book-like PDF versions of documentation: easy to print out docs.
  • integration with GUMP: dependencies, runs, committer that broke the run
  • javadocs seemlessly integrated with the documentation and with the search engine.
  • mail archive seemlessly integrated with the search engine (one should look for something and get results from either docs, javadocs or emails messages)
  • coherent-looking CVS view
  • document translation using Google translation services
  • Integrated project management, task management, bug tracking, feature requests, process management. The idea is to integrate Scarab for bug tracking/patches and managing/feature requests. (As far as team management, this is a serious political issue and I do not want to tackle that one yet, not even on the dreamlist.)
  • overview doco for all projects ... CVS Usage precis, overview of opensource and links to relevant doco