forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ferdinand Soethe <>
Subject Re: Site-author organization
Date Tue, 08 Aug 2006 11:55:12 GMT

Sorry for being so quiet for long time. Had and still have some
pressing personal issues to attend to. But I'm still reading and I'll
try to explain what I had in mind when I started this restructuring:

The "Welcome"-Tab

Aims at giving a quick introduction to the Forrest-project the
software and its goals and capabilities.

Provides intro on an executive summary level plus examples to quickly
get the idea what can be done with Forrest.

The "Developers"-Tab:

This used to be the Project tab and that pretty well summarized the
content I found under it: All materials that are needed to participate in
Forrest as a project. Specifically

- in which ways I can participate
- where to find the tools and infrastructure needed to participate
- and how to go about certain tasks

I subdivided these tasks in a way that tries to minimize access
time to information while categorizing it logically by the kind of
info that can be found in it.

The idea being that I didn't have to dig through all documentation to
find all "best practice" documents or references to resources.

- Getting involved explains the different ways of participating in the
  project and yes - Tim is right - this could  be the tab-heading
  really if we don't go back to "Project" (see comments below).

  Creating a separate sub-section "Project" came out of renaming the
  tab from "Project" to "developers". It did not make a lot
  of sense to me at the time but since I was busy with other things

- Resources and Infrastructure lists the tools and infrastructure
  available for people working for the project. This could be a
  subheading to "Getting involved" but since it is needed quite often
  I left it at the top level to make it easier to find.

- Best practices and procedures
  This section is the howto-part of the project manual. And again I
  wanted these to be visible so that people realize that there are
  guidelines before they start working ...

In reply to Tim's comments:

> "Resources and Infrastructure" - Resources is way too ambigious to be
> a part of a navigation scheme I think.

Part of my motivation for creating this section is
that I wanted compact directory of all the tools, resources and
infrastruture urls in one place.

Perhaps you can suggest a better name for this.

> Infrastructure also doesn't
> carry much meaning when I think of an open source project.

To me infrastructure is quote "the underlying foundation or basic
framework (as of a system or organization)" and refers to all the
tools and resources that allow us to work together. Can you explain
why it doesn't carry meaning in an OS project? What would be a better

> It turns
> out that likely what most folks are looking for is really under here
> (mailing lists, code access, and issue reporting).

Is it really? And if so, do we really want to encourage that. Wouldn't
it make sense to read about how to get involved and understand the
best pratices before one actually using the issue tracker.

I agree that later on this might be the most often used category
(that's why I didn't make it a sub section of "getting involved".

Besides: I very much favour multiple ways of accessing the same
information. Such as links in the "How to get started"-section that
links to the user-mailinglist and encourages people to subscribe to it.

> "Best Practices and Procedures" - Again, I think it doesn't carry
> enough common concrete meaning to be a part of a navigation scheme.
> Do people know what they can expect to find when they click this?

It thought "Best practices" in the context of "Project" carries a lot of
meaning. And I wanted this to be top level to be easily found.

> "Project" - This is currently buried under "Getting Involveld".  It
> seems to me that there is some good information that should be given a
> better spot.

Yes I agree. Renaming "Project" to "Developers" has created a
unfortunate situation and made the project specific document a bit
homeless. Is it too late to argue against the renaming of the tab?

> If not,
> maybe we could kick around some alternative schemes on the mail list
> to improve it?

Please do, I'm curious to see what you come up with.

In reply to Ross:

> Your not the only one. I can't find anything either (see my previous
> post on this topic). Ferdinand said he was had not completed what he 
> wanted to do, but that was quite some time ago now.

Actually I was referring to the "Version Docs" tab as being
incomplete. And afair mentioned that the available docs did not
really match the structure that our grammar suggested because the
often mix instructional and background info. Anybody could fix that by
rewriting and spitting up certain documents.



Before I do, the Developers-Tab aka "Project" is not part of the
unfinished business really. The "Versioned docs" is because most of
our docs cross the boundary between instructional and background
documentation and did not fit the categories that aimed at separating
the how-tos from back

Ferdinand Soethe

View raw message