forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <>
Subject Re: Site-author organization
Date Wed, 09 Aug 2006 02:03:58 GMT
Ferdinand Soethe wrote:
> 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:

Thanks for taking the time to help.

> 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
>   ...

In the previous thread, Ross and i had strong opinions
about not making a distinction between "us and them".
We are all "developers". Some of us (mainly the committers)
make extra effort to do the tasks that keep the project
flowing. I have not yet heard any justification for making
a distinction. In fact i think that it would be dangerous
for the project health.

See the last section of:
 Re: Document restructuring - confused
and the subsequent messages.

The "Developers" tab includes a few documents under
the sub-section "Project". I reckon that these should
be moved up to the "Getting involved" section.

> - Resources and Infrastructure lists the tools and infrastructure
>   available for people working for the project.

I think that it is way more that just that little group.
Developers want to participate in the mailing lists, and
want to search and add to the Issue Tracker, etc.

>   ...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.

Perhaps we should merge these few resources into the
top-level section and rename it from "Getting involved"
to "Resources and Infrastructure" (or a better name).


> - 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
> term.
> > 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.
> hth
> Ferdinand
> 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