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.
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:
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:
Community Type |
Description |
Membership group? |
Enrolment Model |
Administrators |
Editors |
View access |
Permission Scheme |
Portal |
Useful widgets? |
---|---|---|---|---|---|---|---|---|---|
eg. Project |
Collaborate on a specific project. |
Moderated |
Person who creates the space |
Members, Managers |
All staff |
|
|
JIRA issues, Recent updates, ... |
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.
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:
Think of any other useful community types based on these criteria:
Here's a short list of some of the community types our other customers have used:
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".
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:
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.
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.
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.
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:
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.
There are two ways to create a community:
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.