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 http://thread.gmane.org/gmane.text.xml.forrest.devel/21380/focus=21380 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). -David > - 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
