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