Question

The Company I Work For plans to transition a lot of the corporate Intranet to TWiki. The TWiki is already installed but has historically been used by only one team.

Being a very hierarchically, structurally organized sort of person, I want More Webs rather than fewer. I have proposed, at a minimum:

• Engineering (coding)
• QA (testing)
• Documentation
• PM (Project management)
• Customer Service
• IT (Internal Technical Support)
• Projects

where each functional area would have its own web for infrastructure sorts of topics and then there'd be a lot of mix&match under Projects (where all the teams work together).

I think I have my manager convinced but I may need to convince other people. Please help me with reasons for putting things in multiple webs rather than all plunked together.

Some of my reasons (aside from my compulsively hierarchical nature):

• webs are automagically placed in left-side nav bar (very convenient)
• more webs give team members a good idea of where to go first and where their content and team belong
• branching a wider tree at the top leads to less overlap by people who don't know where to go so they create new subtrees in another place without realizing an area already exists for that information

What things can/can't be done more readily on a per-web basis than within a web?

What are some reasons that you use to decide what should be a web and what should be a section within a web?

Environment

-- VickiBrown - 22 Oct 2004

Answer

When deciding how to split up the information, look at your target groups. What groups can you define and what information do each group need? I can imagine that project managers have a different information need than engineering, but there might also be a large overlap. When there is overlap, it is useful to put all this information in one web. Its probably also a good idea to make searching by default across webs.

-- ArthurClemens - 23 Oct 2004

I had the same preoccupations, and I decided to split the intranet by "teams": (TWiki->System), (Main->Users), IT, CAD, Admin, and one web per project (projA, projB, projC) rather than just a "projects" web. I also enabled multi-level menus ( HowToHaveTwoLevelsInLeftBar ) to have some kind of a logical hierarchy mapping on top of each web.

-- GillesEricDescamps - 25 Oct 2004

Sorry, but in my experience splitting up a TWiki into webs organised by teams is very bad news indeed. Wikis work best when everybody shares a common namespace, and doesn't feel "alienated" by being "in someone else's web". Of course it's necessary sometimes e.g. for managing protections and access levels, but in general, I have always found that the fewer webs there are, the better. Why bother introducing a communication tool, and then throttling communication?

You can still link information in fewer webs using other indexing techniques such a Categories and WikiBadges. In fact, it's a lot more flexible that way, as a page can be in more than one category.

BTW if you do split up by team, be prepared to have to re-organise all the webs on a regular basis, every time your regular corporate re-orgs happen

-- CrawfordCurrie - 30 Oct 2004

Thanks Crawford. Appreciate the feedback. I effectively did split in several webs. I did not follow the org chart, but rather the informal groups of people working together. It was a way of gaining trust for deploying as I heard: "What ? anybody can edit my pages ?" . I even went further by adding more webs to setup group-access write permissions for legacy applications (perl scripts which dump hundred of html pages) (see HowToIntegrateLegacyStaticReportingApplications ).

-- GillesEricDescamps - 02 Nov 2004