This is intended to be a collaborative document putting the argument against the single hierarchy idea in TWiki. As it is a collaborative document, you have three choices as to how to contribute; you can

1. edit your opinions directly into the essay (please observe the rules of English grammar) and add your name to the list of contributors,
2. make counter-arguments in SingleHierarchyRocks,
3. simply express your support by using the comment box at the end and adding your name to the list of supporters.

Introduction

There's good evidence that two accepted organisational concepts in TWiki are bad for your wiki's health.

Multiple webs, and Parents.

Both of these concepts are what you might call "hierarchicalisms" viz. they foster a parent-child relationship between topics in the wiki. Hierarchicalisms are essential to comprehension; they collect and classify data into manageable bundles that our brains can cope with symbolically. This essay is not against hierarchy per se, but against the concept that a single hierarchical organisation, as fostered in TWiki, can ever address the needs of its users.

How does TWiki foster a single hierarchy?

When you first get TWiki out of the box, what you immediately see is a bunch of webs. As soon as you start creating topics, you get parent links created. The message is pretty clear; TWiki wants you to organise your data into webs, and index it on that basis. This is true to the extent (please correct this misconception if it's wrong) that none of the shipped documentation even mentions any alternative. From an end-user perspective, then, TWiki is single-hierarchy. Of course you can layer other organisations on top, but by the time you are mature enough to realise this, the damage has normally been done.

Why are single hierarchies bad?

It's a fact that hierarchies are usually set up by twiki adopters to reflect their reporting structures. Having your reporting structure reflected in your wiki is no bad thing; but we can use it as an example of why single hierarchies are bad news.

Reporting structure as a hierarchy model

Reporting structures are commonly referred to in corporate enviornements as "The Organisation", and are the usual starting point for any hierarchical structure. Reflecting The Organisation is traditional, it reflects a social need to reinforce where you belong, and it stems from some fundamental ideas:

1. The Organisation is a point of stability
2. other people in the same part of The Organisation are likely to be interested in the same things
3. other people in the same part of The Organisation are the only ones authorised to share ideas (security)

The Organisation as a point of stability

Here comes the first piece of physical evidence that hierarchy is bad for your health: in RenderListPluginDev PeterThoeny writes: " At work we have over 100 webs. After several reorgs the group pages are scattered all over the webs, the relation by org chart does not match the topic parenting since they cross web boundaries, hence the reason for this Plugin. ". Most people with experience in corporations will assert that hierarchies based on The Organisation are fragile because The Organisation changes over time, often at a whim. Reorganising your wiki every time The Organisation changes is not an option, and the data soon gets out of control.

Common interest in The Organisation

Organisational structure is usually market-driven. We can expect that (for example) US, AsiaPac and EMEA each have their own organisational structure. So working in EMEA, you would find yourself in the same hierarchical structure as accountants, salesmen and marketing people, on the basis that our common term of reference is EMEA. You certainly need to talk lots to people in EMEA, to understand what's driving your market. Sadly, you are probably an engineer, and spend most of your time talking to other engineers. And there aren't many of those left in EMEA, so you have to talk to people in the other regions far more often than to people in the neighbouring cubes. But the organisational structure gets in the way. The Organisation rarely reflects the way people work at grass roots.

Security in The Organisation

Making your security model follow The Organisation is often a good starting-point, especially in businesses where operating companies work under the umbrella of a coporate group. But again, the security model in most organisations does not, cannot, follow the organisational model. It doesn't make sense for finance and HR in one operating company to have access to eachothers data, but it does make sense for HR in two operating companies to cooperate closely. So, you cry, why not base the hierarchy on the security model? Well, because the security model isn't hierarchical, that's why. An individual in an organisation needs to have access to secure data from many areas - their own HR data, for example, or their divisions financial results, or their regions sales figures. Hierarchies are inappropriate for good security.

Other single hierarchies

So, making your single hierarchy follow The Organisation is a bad thing. Surely there are other hierarchies we can follow? Don't bet on it. Change is a fact of life in business, and businesses that can't change often die. Any single hierarchy is going to get in the way of business.

Some commonly expressed misconceptions

There are some other arguments for hierarchies. These are often expressed as rationales for single hierarchies, but in fact apply to multiple hierarchies as well.

Without a strict hierarchy, the amount of data would be unmanageably huge

Wikis can grow very large over time, and we all need some way to manage this growth. But why do wikis grow big? Here are some reasons, found through experience:

1. Users don't understand the wiki concept, and use the wiki as a dumping ground
2. Ghettos form as users drift in and out of active use of the wiki
3. Wikimasters are not proactive in managing content

Of these, the last is the single most important factor, as wikimasters must educate, mentor and guide other users in a cooperative, non-confrontational way. Organisations should recognise their wikimasters as a key resource, and develop and reward them appropriately. In an age of information overload, those who manage and organise information are more precious than those who generate it; they are often the synthesists who make the connections that others have missed. Unfortunately, hierarchical structures get in the way of the wikimasters. Moving topics between webs, linking across webs, reparenting topics, all are functions that a wikimaster shouldn't have to worry about. Organising content is hard enough; let's not make it harder.

Multiple webs in TWiki is currently an effective way of managing data volume such that the application performance remains good. However this alone is not a good enough reason, given all the counter-evidence for single hierarchices presented here.

There is no alternative to a single hierarchy that makes sense

Not true. There have been a number of alternative approaches to creating wiki namespaces discussed here on this web, some of them very viable and easy to get to from where we are today. Almost all of these ideas build on the concept of a flat namespace with different "slices" or "views" of the data being used to create multiple interleaved indexes. A crude example of this are Categories (see CategoryCategory) which simply use a search expression to categorise topics.

It's interesting to note that given a slicing model for the topics in a wiki, security actually gets a lot easier to handle as well. For example, you could create a category "PermittedToEngineeringGroup"; any topic bearing that WikiBadge would be accessible to anyone in EngineeringGroup. That provides topic-level, but also group-level security at a low management cost.

As a further counter point, the more complex the hierarchy automated in a wiki implementation, the more complex the implementation needs to be. Without webs, TWiki could be a lot simpler.

Society and the single hierarchy

It has often been noted that wikis are a mirror of society, and society is hierarchically organised. Most of the time it is, but there are many, many hierarchies, and which hierarchy applies in any given context is open to interpretation. Any attempt to impose a single hierarchy in any society of higher animals is doomed to failure. We've all seen the movie; just before the firefight, the green lieutenant tries to assert his authority over the grizzled old sergeant, and dies in a hail of lead as a result.

We see this kind of behaviour in wiki all the time. Users rapidly devolve to treating webs as "mine" and "yours", destroying the essential wiki democracy. Discussion dies because the audience exposed to the content is limited to those people "interested" in that sub-hierarchy.

Summary

In summary, single hierarchies are bad for your wikis health because:

• Single hierarchies usually model the organisation, and
  • Organisations change over time, often at a whim,
  • Organisational structure does not reflect the way the organisation works at grass roots
• Strict hierarchies are inappropriate for good security
  • They result in inappropriate access grants and denials
• Single hierarchies get in the way of the wikimasters
  • They make the job of synthesis that much harder
• Single hierarchies are a societal disaster waiting to happen

Finally, note that the argument is that single hierarchies are bad for your wikis health. We all need to be aware that TWiki is not just a wiki but is used in a number of other ways, some of which require strict single hierarchies. So this essay is arguing not for the abolition of hierarchy, but for the recognition that the current single hierarchy is falling badly short of users true needs.

And please note; this topic is classified as "FeatureEnhancementRequest". This is not a vague exploration of future directions, but a pressing flaw in current TWiki, and therefor FeatureBrainstorming is inappropriate. The first author of this topic almost classified it as a BugReport! Some would argue we should not release Cairo until this is addressed.

CategoryOrganizingPrinciples

Contributors

-- CrawfordCurrie

Supporters

- Walter commented security and having hundred of webs is true, but security is not driving wiki, scalability is. as you put more than a few thousand people in a web, the response time will suffer. The search scanning for results will prevent this hierarchy from going away, but this is a physical hierarchy , not a logical one. One or more logical hierarchies can overlay the physical. -- JohnCoe - 05 Apr 2004 - 12:34

- The hierarchy is implicit in the breadcrumbs being set up when a topic is created refering to the parent. A web is ... well, a web.

A topic can be refered to from many places, so the parent fixed when it is created is misleading. A "what refers to this topic" back tree does the job correctly, but in reality it would take up screen real estate and contribute little value.

A web is a web is a web. Given enough links, give a search engine, given some classification and tagging scheme and someone to fill it in, things aren't going to look like a hierarchy. -- AntonAylward - 05 Jul 2005

- At one time I wanted TWiki to mirror file system hierachies*. As I looked at the problem more deeply, mainly my and my compatriots existing file systems (a horrid mess, to be blunt), I realised this idea was not a good one. However the usual alternative of clumping everything into one big ball of spaghetti is at least as bad. It's not that hierarchy and multiple levels of categorisation are bad, it's that inflexible and hard to change systems are bad. Some bright soul needs to come up with a WikiWay of categorising things. Individual topics need to be able to added to, and removed from, grouping categories as easily as we now create NewWikiLinks. Assuming such a thing is even possible. I think it should be, but obviously it's a non-trivial problem or we wouldn't be having this discussion carry on over several years. -- MattWilkie - Tue Mar 2 12:45:20 2004

- I'd just like to note that I think webs are a good idea, but using them to foster hierarchy is not. Webs are useful for splitting off "system" bits of the wiki and keeping them from interfering with the content. Hundreds of webs? Gah! We need to discourage the creation of a separate web whenever a separate locus of topics in an existing web would do, but I don't think we need to get rid of webs entirely. Security is an issue we'll need to resolve for this kind of thing to work, though. -- WalterMundt - Tue Mar 2 09:10:47 2004