Community Configuration

Before you can start making communities you need to create one or more community types, each consisting of a permission scheme and optional components such as portals and theme settings.

Overview

The main aspects of a community type are illustrated in the diagram below:

When you create a new community, you'll be asked what type of community you want to create. Based on the settings for the community type, various defaults will be applied to the community space such as:

• Permission Scheme (mandatory) – this defines the default permissions applied to the space, for example which groups have view, edit and administrator permissions.
  • You can still customise permissions for each individual community, by editing the space permissions
  • The permission scheme also defines which Enrolment Settings to use – these control how people are added and removed from the membership group
• Portals (optional) – if desired, you can choose which portal will be added to the home page of new community spaces. Updates to the portal will be reflected immediately in all communities that use the portal.
  • The portal will display one or more widgets – community administrators can configure which widgets are shown and in which order
• Theme (optional) – if desired, you can choose which theme to use for the community type in order to ensure consistent design for all communities of that type
  • Layout – if you're using our Theme Builder plugin, you can also choose which layout to use
• Membership Group (optional) – if desired, you can define a membership group, which in turn allows community administrators to automatically apply confluence permissions to community members.
  • You can still give existing user groups access either via the permission scheme or using space permissions, but members won't get automatically added to these groups.

Best Practice

From experience we've found the following approach to work best for configuring community types. Set up a wiki page containing a table like the following to collate your ideas:

As you proceed through the following steps, fill in the table - but only for things that you are sure about. Leave blank cells if you aren't sure about something as those things should become more obvious later.

Step 1 - Community types

Before you can start thinking about any specific settings, you need to have some idea of the types of community that will benefit your organisation. Always think of the community type in the singular (eg. "Project"), and community spaces of that type in the plural (eg. "Projects" or "Project Communities").

Start by looking at your existing wiki spaces for inspiration:

• Are there several spaces for the same sort of thing? For example, you might have several project spaces which would indicate that a "Project" community type would be useful.
• Are you using "team labels" to group related spaces together? For example, a "department" team label might be grouping several departmental spaces which would indicate that a "Department" community type would be useful.

Think of any other useful community types based on these criteria:

• Where do you want to foster collaboration? For example, you might want people to share knowledge so you could create "Ask an Expert" communities.
• Which kinds of self-forming user groups would be useful? For example, wouldn't it be useful to let staff create "Job Role" communities so you'd end up with handy groups of people based on their job role?

Here's a short list of some of the community types our other customers have used:

• Conference Session - every session gets a community space, the membership group being used to track attendees and the space administrators being the presenters
• Country, Region, Town, etc. - now you can find people based on geographical location, etc.
• Market Sector - focus discussion of key sectors, and find out who knows about those sectors
• Product, Service - build communities around your products and services, quickly find people with specialist knowledge
• Supplier, Customer, Partner, Reseller - set up communities to collaborate with key suppliers, customers, partners, resellers, etc. The membership group makes it easy to control who has access
• Team - this type of community could be used for all kinds of things, a group of staff that are in a basketball team or ad-hoc inter-departmental teams set up to perform specific tasks. It's sometimes useful to have things like this so you can create communities that don't really fit in to any of the other community types you've considered.
• Recycle, Freecycle - most organisations have several recycling schemes, why not create communities for them? If you've got lots of offices worldwide, why not set up "Freecycle" (see http://freecycle.org) communities so that staff in each office can freecycle unwanted things?

Once you've got your list of desired communities, spend some time thinking about the titles and descriptions you'll use for the community types. The community type title, in particular, is important because it can be displayed in various macros. For example the join-community macro by default will display "Join this %communiytypetitle%", so for a community type of "Project" it would show "Join this Project".

Step 2 - Portals and widgets

When a new community space is created, it's useful to display something useful on its home page. The easiest way to do this is to use a portal to display one or more widgets. Don't spend too long defining the widgets though - you can easily change which widgets are shown in the portal at a later date, and all spaces displaying that portal will update automatically. Focus on the portals for now.

Don't go crazy and define a portal for each and every community type:

• If you've got several community types that are similar (for example Supplier, Customer, Partner, Reseller) then you probably only need one portal that displays a selection of widgets generally useful to those kinds of communities.
• Another approach is to list which widgets would be useful for each community type, and see if any patterns emerge - if several community types will use the same widgets, you can usually use a single portal for all of them.

Remember that the space administrator can customise the portal to some degree, depending on how you configure the portal. For example, you could include several widgets that aren't shown by default so that space administrators can show them if needed. Likewise, space administrators can remove any non-mandatory widgets from the portal and rearrange the widgets if desired.

Step 3 - Permission schemes

You can make one or more permission schemes available to each community type. When a new community of that type is created, the user creating it will be asked which permission scheme to use. Based on the permission scheme selected, default view, edit and administration permissions will be set. The permission scheme also determines which enrolment settings will be used - these control how people can enter and leave the membership group.

Rather than thinking about permission schemes at this stage, just list who should have view, edit and administration access for each of the community types you want. For some community types you might have two or more different permission scenarios, for example some projects would allow all staff to view them whereas others might be more confidential in which case only members could see them.

Once you've listed the different view, edit and administration permissions it should become more apparent what permission schemes you need to define.

Based on the permission scheme you should also be able to determine which enrolment model to use, for example you wouldn't want "Open" enrolment on a members only permission scheme so something like "Moderated" or "Closed" would be better suited.

Step 4 - Themes and layouts

This aspect of a community type is really outside the scope of this documentation... However in our, somewhat biased opinion, if you're using our Theme Builder plugin you can really enhance your communities.

Start by creating a master layout that defines the general design and navigation of your entire wiki. Next, for each of the portals you're planning to create, make a theme layout (as a child of the master layout so it inherits the general design and navigation) that has the same name as the portal. So, for example, if you've got a "PROJECT" portal, make a "PROJECT" layout - you can then add navigation and sidebars that are specific to projects.

Regardless of which themes you have installed, think about which will be best suited to each community type.

Step 4 - Putting it all together

By now you should have a table listing all the community types you want to use, along with information about their associated permissions and portals, etc.

First, ask around to find out what sorts of communities people think would be useful. They'll usually respond with an idea for a specific community, for example "I want a community for my paper recycling project", so you'll need to work out what type of community that would relate to. Keep a tally of how many people ask for each community type - if nobody is asking for a specific community type, it's probably not needed.

Prioritise your efforts based on the level of interest in each community type. We strongly suggest setting up a test server to play around with different approaches. From experience we've found that it's easy to spend a lot of time discussing what will work only to find that in practice some things don't work the way you expect them to whilst others work far better than you could ever have imagined. So, try things out sooner rather than later - you'll quickly learn what works and what doesn't, without investing too much time in the theory stage. At this stage do the absolute minimum to get your communities set-up, and only set-up the most useful community types to start with.

Work out what portals will be required - if several community types are using the same widgets, they can use the same portal in most cases. Set up at least one widget for each portal - the remaining widgets can be added at a later date. Creating a "Recently Updated" widget is a good place to start - it's one of the most commonly used widgets in any portal.

Permission schemes should be approached the same way - look for patterns in the permissions listed in your table and create the fewest possible permission schemes to accommodate them. Work out which enrolment model each permission scheme will need - if a permission scheme needs more than one enrolment model, you'll have to create additional permission schemes to accommodate. Be sure to give the permission schemes descriptive titles and descriptions.

Generally, we recommend leaving themes and layouts until later. Make sure everything else is working as expected before you start investing time in themes, layouts and widgets, etc.

Finally, set up the most useful community type definitions, selecting their associated permission schemes and portal, etc. Then start testing! Go through the process of making a new community for each of your community types - use the create-community macro so you see the same steps that end users will use.The key things to check are:

• Do the titles and descriptions for community types and permission schemes make sense?
• Did you remember to provide links to join the community, etc., where applicable?
• Is the membership group working as expected? Does it have the name you expected?

Once you're happy with the way things are working, start adding more widgets to the portals - experiment with the order in which they are shown, and different portal layouts (two columns, with one column wider than the other, usually works best). If you're going to use a custom theme layout you can also show portals or widgets in the sidebar and customise menus and other navigation to present a more consistent and meaningful user interface to members of the community.

You should end up with a process that feels very natural - when a user decides to create a community, they should intuitively know which community type and permission scheme to use, and the portal on the home page should show meaningful widgets and links. Ask a small number of end-users to try out each community and incorporate any feedback they provide. You can then apply the community types, permission schemes and other settings to the live site and start creating communities.

Creating communities

There are two ways to create a community:

• Administrators can click the icon on the Community Types screen
• End-users can click the link output by the create-community macro - note that they'll need the global "Create Space" permission to create a community space.

Alternatively, you can convert a normal space in to a community space using the Community Settings screen (which can also be used to change the community settings of any community space), however note that when you convert a normal space in to a community the space permissions, home page and theme won't be updated (as they will have already been manually configured). Refer to Creating Communities for more information.