Talk:Using Categories

Great start on the wiki organisation documents!

Some nuts and bolts issues with regard to categories and refactoring existing pages/categories:

The site header is the main entry point to the wiki. It is currently structured in the following way:


 * Package Category
 * Projects which are links directly to a page.

If we compare the Pyrolysis Oil project and the Solar CHP projects as linked from the header, Pyrolysis links to a general page of information, whilst Solar CHP links to a development work template (DWT).

In refactoring each project should adhere to the same standards. One downside of the current approach is that there are lots of non-DWT documents full of information for each project that aren't directly or easily available. Not all projects currently have a DWT that I can see, and adding them in retrospect will need some refactoring no matter what approach is taken.

I guess ideally you'd want all of that supporting research linked from a DWT for the project, but it comes down to usage. What is the primary method of use of the wiki? Are people going to wade through the complete template in order to insert a link for an item they've just created containing subsidiary information for a particular project? Are they going to remember to do this? Are they going to go through the DWT to find further information?

One option for overcoming some of these issues is to create project categories for each of the projects and link directly to those from the site header. Then, in the top of the category page for the project we place a link to the project's work template. The downside of this would be that the work template is even less likely to be updated unless a person specifically intends to do so. Upside is that all docs relating to a project are collected at the entry point to that project (sort of thinking along the lines of portals here.) The layout would look something like:


 * Package Category
 * Project Category
 * Specific link to Development Work Template for project.
 * All other documents and subcategories for project.

Another option would be to link direct to the DWT for a project, and at the top of that template include a link to a category specifically created for that project (so for eg Pyrolysis Oil will have an associated category "Cat Pyrolysis Oil")


 * Package Category
 * Project DWT
 * Specific link to project category

This option keeps the DWT at the top of the tree, but also allows a category of associated documents to be maintained.

Having a project category allows information to be roughed in, included with the appropriate project, and then enthusiastic maintainers can trawl through the category and work items back into the DWT where warranted, and as and when time permits.

My view: If there is an existing Project overview page (that is not a Category page), no harm in linking to the existing overview page and refactoring it later. The general principle should be that the user drills down to increasing detail. Since the DWT has the most detail, it should be at the bottom of the tree.
 * Package Category page (overview)
 * Project Category page (overview)
 * Project DWT