The majority or developers think new webs are a good idea. Personally I don't think new active webs are a good idea, though I do like the idea of an archive.

It has been pointed out that Codev has fulfilled too many roles - bug DB, encyclopaedia, brainstorming whiteboard, process documentation, collective memory. Interestingly enough most of the topics in Codev are classified in some way or another, fitting them into one or other of these roles. Unfortunately the Codev fixation on forms and drop-down lists have meant that that most of the classsifications are hopeful rather than useful, but there is still data there to help.

The overlap between these roles is such that searches are almost useless in Codev. Adding a new role, "Stale", can only make this worse - either because it does nothing to reduce the cruft, or because it requires the development of yet more arcane and unfriendly switches on search (it's already close to unmaintainable; let's not make it even worse).

I started CategoryCategory in the hope it would be adopted as a self-maintaining index. Peter has started tagging with the same goal. There are existing form fields and drop-downs that attempt to classify topics.

What I propose we do is leverage the existing classifications and roles to script a reorganisation of Codev. The script should:

1. Archive closed bugs, ideas etc. by moving them to an attic web (it can leave spoor)

By scripting a solution we achieve three things:

1. Something we can all agree on before the re-org starts.
2. A mechanical reorganisation that eliminates human error in the elimination process (yeah, right
3. A fast reorganisation (one script run on twiki.org)

The goals of the re-org are:

1. Move cookbooks and end-user supplementary documentation to its own space.
2. Identify and archive definitely stale content.
3. Identify probably stale content, and mark it for human review.
4. Reclassify topics under a single classification scheme.
5. Remove redundant or overlapping classification schemes; they just cause confusion.
6. Remove all forms, moving relevant content into the topic bodies. Forms are appropriate for a structured web, but Codev should be a freeform web. In a freform web, forms are difficult to maintain, difficult to search, unfriendly.
7. Minimise moves between webs.

In the following I have focused the re-org on categories. This is because that's what I know. If tags can offer a superior solution, I'm all for it.

Decisions and actions, in order of application.

If a topic has not been edited for at least a year, add it to CategoryStale

It would be nice to process the logs to check accesses, but probably overkill.

If a topic has RelatedTopics, create them as WikiBadges in the body of the text

Forms in Codev are evil, but the information in them isn't.

If a topic is part of CategoryCookbook, move it to Support web (leave spoor).

Cookbooks for doing various things with TWiki, and setting it up to work in different environments. These are the main "backup documentation" topics for end users. They tend to be quite specific to one version of TWiki, though are increasingly written to apply to any version. The reason for moving them to Support web is that they are key support resources. It is better for people looking for help to look in one place, and not be sent off to lots of different webs.

If a topic is part of CategoryProcess, move it to develop.twiki.org (leave spoor)

Anything and everything to do with the processes used in developing TWiki should be kept alongside the Bugs web, where it can be easily cross-linked and referred to, and we are not afraid of radical refactorings.

If a topic has a ChangeProposalForm, and CurrentState is UnderInvestigation, ConsensusReached or UnderConstruction, then create an Item for it on develop.twiki.org (leave spoor)

It is confusing trying to track bugs in several places. Let's focus on one. Note to avoid excessive duplication, this decision should only trigger if the topic does not contain an ItemXXX reference. The topic name should be used for the headline, and the TopicClassification should be used to map the priority:

Codev	Bugs
FeatureRequest	Enhancement
BugReport	Normal
CodeRefactor	Normal
DocRequest	Normal

If a topic has a ChangeProposalForm, and CurrentState is ImplementedAsExtension, ReadyForMerge, MergedToCore or NeedsARethink, then move it to Trash web

These are closed issues. There is little value in keeping them around. From a history perspective it is nice to remember them, but they can be remembered in Trash web just as well.

If a topic has a BasicForm with TopicClassification set to BrainstormingIdea or NextGeneration, then keep it in Codev, adding it to CategoryBrainstorming

The primary purpose of Codev web should be brainstorming.

If a topic has a BasicForm with TopicClassification set to DefineTerm, then keep it in Codev, adding it to CategoryGlossary

If a topic is not a Category and has a BasicForm with TopicClassification set to GatewayTopic, move it to Trash

This is yet another attempt at indexing topics that has never been maintained.

If a topic has a BasicForm with TopicClassification set to TWikiAddOnProduct, move it to Trash

As far as I can tell, this predates plugins web and tries to do the same sort of thing. There are a couple of topics in this classification that may want to be reclassified as cookbooks before the script is run.

If a topic has a BasicForm with TopicClassification set to TWikiCommunity, TWikiAdvocacy or TWikiVsOtherProducts, keep it and add it to CategoryMarketing

Most of the topics I can see in the community section are to do with user and developer communication e.g. user groups. These are - in my vocabulary at least - marketing activities. At least, it gets hard to separate "community" from "advocacy", suggesting the two should be the same.

Any topic that does not trigger any of the rules above, add it to CategoryStale

People with time on their hands (!) can perform a community service by visiting the old and lonely.

-- Contributors: CrawfordCurrie

Discussion

---