WebsiteFacilitatorTaskTeam Talk page

This topic is used for discussions related to the Task teams (ideas, suggestions,etc). Everybody feel free to contribute! This is not a private topic.


To make our webs useful, we need to improve searching, improve Googleability, and reduce its volume to the currently active topic set.

Tasks pending definition

  • Develop automation and TWikiApps to make these manageable and shareable.

Registration and Topic creation policy for Main web

We need to have a well defined simple followable policy.
  1. We continue the requirement that real names are used
  2. We move all non-user topic / leftbar topic from the main web to sandbox - no exceptions
  3. Add plugin support to keep the CommunityGroup up to date (ie, if you are registered, you're part of the community).

To support this policy (or any other as discussion obviously should occur), we should write a Plugin that simplifies all the tasks - through a checklist style interface that lets other Team members know what topics have as yet not been verified, and to automatically move topics, and to email user's who's accounts are considered iffy.

Adding to this plugin something that makes it harder for users to create non-user topics, or possibly, to lock down the Main web so that the users only have write permissions to their own topic (unless they are in the TWikiCommunityGroup?) - with some way for users to comment. this would be a non-issue as soon as we split the Main web into Home and Users.

Taxonomy & Folksonomy

For TopicClassification, I propose:
  • We should revisit the TopicClassification used in the BasicForm, as there are some that may be redundant or not needed.
  • Admin topics should have a form on their own, so we can mark gateways, topic templates and forms. It is not safe so assume that all topic template names finish with Template or that form topic names finish with Form. AdminTopic should contain the list of these admin topics.

Regarding Folksonomy, the TaskTeam must define some "canonical" tags so we can all use them the same way. This should increase the signal-to-noise ration in those selected tags, or at least give us a common language to describe topics.


We also need to start putting in place the tools and systems to improve the refactoring of topics - and work on rewriting our Documentation to focus on simplicity.

Included in this is to use more plugins.

Increase topic refactoring

  1. We need to set an example on refactoring topics
  2. I'd like to also consider the use of a blockquote tag with styling for comment plugin - and perhaps to change how it works from being 'add stuff to the end' to 'annotate any location in the text'.
  3. Also, what if we stop adding 'sig's quite so much, and generate a topic editors list from the rev history.

Make a public TaskTeam Mailing list, and change the talk admin email to that


This user will be used to clean up topics without them appearing in the changes

We may be able to su-login to be WikiGnome though right now it would not work like sudo - everyone would need to know the extra password.

add a 'don't' allow users to create / move / modify topics function to the TWikiDotOrgTeamPlugin - such as the TWiki.NotExistingYet topic, which is used in documentation to show a non-existant topic.

-- SvenDowideit - 14 Oct 2008

This is looking good. Should maintenance of the various email lists fall under this Task Team also? Also, shall me copy over the basic list of tasks from TWikiOrgWebsiteFacilitatorRole and organize them here?

-- LynnwoodBrown - 23 Oct 2008

(Moved comments from WebTaxonomy in here.)

Hints and heuristics on how to get to a better taxonomy:
  • Try tagging first, then consolidate into categories.
  • Use cateogries + tagging.
  • Derive tags from keywords/most important words in topic text.
  • Derive categories by grouping tags.
  • Gather keywords from search logs.
  • Create a glossary that points regulary used terms to the supposed categories, thus consolidating common vocabulary.
  • Create tag groups that mean the same.
  • Webs are categories already.
  • All content should fall in one or more categories.
  • If you create a hierarchical taxonomy, don't create a tree deeper than 3-5 levels, never wider than 7-11 nodes. Everything else isn't usable easily without being a subject matter expert.
  • If one category gets too full, try to split it up by ballancing content among existing categories or creating new subcategories.
  • There is a natural boundary where a category is "full" and entropy starts within again.
  • If categories stay empty, remove them.
  • Rethink your taxonomy regularly by checking if new content still fits in. Plan ahead your next taxonomy reorganisation.
  • Create catch-all / or other categories, maybe per level, to gather all content that does not fit naturally into the existing taxonomy.
  • Let the subject matter experts review your CatchAllCategory regularly to feed it to the next taxonomy reorganisation milestone.
  • Each level of a category must be predictable.
  • All nodes on one level of a hierarchy should be diveded up using the same criterion.
  • If you have more content than fits into a 5 level / 11 nodes tree easily, then move over to facets where each topic has got approx 5 facets, each factet being a taxonomy again.
  • Be aware that you are in danger of losing information when the taxonomy gets too complicated and people fail to put content into the right categories where others don't expect them to be.

-- MichaelDaum - 10 Nov 2008 - 19:43

BasicForm edit

TopicClassification CommunityMatters
Topic Summary
Interested Parties
Related Topics
Topic revision: r2 - 10 Nov 2008, MichaelDaum
The copyright of the content on this website is held by the contributing authors, except where stated elsewhere. See Copyright Statement. Creative Commons License    Legal Imprint    Privacy Policy