The new Community site template in SharePoint 2013 provides some really cool capabilities to promote and encourage collaboration for organizational communities. I considered two alternate titles for this blog post: "Member, member - who is a Member?" and "Will the real Member please stand up?" The reason is because one of the key nuances for SharePoint 2013 Community sites is that Members in Community Sites are not the same as Members in Team Sites - and you need to understand the difference if you want to avoid the "security cliff" in Community sites. I've been working with a client to pilot Community sites and it turns out, that there are some definite best practices and "order of operations" requirements for leveraging Community sites so in addition to the Member nuance, I've combined the lessons we've learned into this list of 10 tips and best practices.
Tip #1: Use the Community Site template if it meets your business needs
Microsoft suggests that the Community sites are best for long-standing groups of like-minded people discussing topics of common interest. They also suggest that Communities are best when the group has at least 200-300 members. This is not a hard and fast rule, but the idea is that as communities grow in size, it becomes more difficult to keep track of who knows what and who can help with specific issues - and so the group will have more incentive to collaborate via the Community site. One point to remember: communities are groups of people, not websites. The Community site can help provide a "home" for community conversations, but setting up a Community site without a corresponding group of people is a little like the question: "what if we had a party and nobody came?" It's not impossible, but it's definitely better if the community exists first and the site comes along to enable it and not the other way around.
Tip #2: If you can't designate a Moderator (or Moderators), think twice before deploying
The heart of a Community site is the discussion list and to ensure that discussions stay active, you should only set up a Community site for communities where you can designate someone to serve as the Moderator. The Moderator's job is to monitor, facilitate, and manage - but also to promote content and people. I think you need a Moderator to ensure that you have a thriving community - and I have always recommended that someone serve in this role for any discussion list, even if it doesn't have the "souped up" SharePoint 2013 features. If no one steps up to this role, then I think the odds of making the site useful will be significantly diminished. One additional potential activity for a Moderator might be to re-write a collection of replies to a question to create a "combo answer" that can be designated as a best reply and therefore be featured at the top of a discussion thread. The Moderator does not have to be anywhere close to a full-time job, but it should be on someone's task list or, ideally, in their job description.
Another important role for the Moderator is setting up the community rules. The "out of the box" Community site has a good start at community ground rules on the default "About" page, but it's a good idea to spell out community norms and expectations.
Tip #3: Always set up your Community sites with unique permissions - and use the default groups the template sets up for you - because a Member is not always a Member
I'm sure there might be a one-off situation where you would want to inherit permissions, but I am convinced that is going to be the rare instance so believe me, you want to follow this recommendation. We didn't understand how important this was in our SharePoint 2013 pilot and as a result, we ended up with users who had permissions who accidentally destroyed a few views for everyone in the community. Ooops. Please just trust me on this one. Microsoft has built in some special permissions for Community sites and, unfortunately, changed the meaning of the term Member in the context of sites built using the Community site template. Actually, the term Member in the context of a Community site is probably closer to the generally accepted English definition of this term. The use of the term Member in the context of all other types of SharePoint team sites is extremely confusing because it is used to refer to a permission group, not the group of people who are actually members of the team. In the context of a Community site, there are actually two completely different types of "Members:"
- Community Members the SharePoint security group: Just like other team sites in SharePoint, when you create a new Community site with unique permissions, SharePoint 2013 automatically creates default security groups [Site Name} Owners, [Site Name] Members, [Site Name] Visitors, and the new [Site Name] Moderators. These default groups have Full Control, Contribute, Read, and Moderator permissions. This is actually different from "regular" team sites, where [Site Name] Members have Edit permissions by default. The primary difference between Contribute and Edit is the ability to create lists and libraries and in the context of a Community site, edit the pages (i.e. the home page and view pages) of the site. The lesson we learned the hard way at my client is that you absolutely don't want any "regular" users in your Community site to have Edit permissions or they can, as one of our users did accidentally, delete the web parts on a page and render the discussion list useless for everyone in the community.
- Members of the Community Site (who will be listed in the Members view in the default template): For the Community site, Member means someone who has explicitly "joined" the Community using the join button on the Community site. Until a user explicitly joins a community, they are not listed in the Members view on the site. When someone the Community site, the site is automatically added to their "followed sites" view. However, just to make things confusing, they might actually be in the Members security group but not Members of the Community. I guess it is fortunate that the only people who really have to understand these distinctions are the people who create Community sites and your help desk, who will get the calls when something is screwed up. However, I still wish that the Members security group on any site had a different name. It may be too late to change this because this term has been misused in every release of SharePoint (and I've been complaining since the first release), but the security group should be called something that means Contributor or Editor, not Members because it is possible to have Contributor privileges without being a member of a team and to make the assumption that all Contributors are also team members has never really aligned with the real world in any of the hundreds of organizations with whom I've worked. My best advice to solution planners is to be aware of this distinction and document it very carefully for your help desk. The only way someone becomes a Member of a Community site is when they explicitly join the community. Otherwise, they might be in the [Site Name] Members security group but not ever be listed in the Community site Members list.
Tip #4 Configure your site before adding users to the security groups
As with any new site, it is a good idea to set the site up first and then once the site is initially configured, add users to the security groups for the site. That way, you can take advantage of the ability to send out an email welcome to a site that is actually ready for use. This is especially important with Community sites because the "out of the box" template is probably going to need some configuration for pretty much any community.
Configuring your Community site means thinking about some initial Categories for your discussions and if and how you want to use the "gamification" features in the community site (points and badges). These features may be very appropriate for some communities and not for others so you will want to think about how you plan to leverage these features in your community. (I plan to post more about this topic as we get more real world experience on my current project.)
Tip #5 Don't assume communities are only about conversations - but think carefully about the messaging associated with storing documents in Community sites (and read Tip #6 before you do anything)
The Community site template comes with one document library - Site Assets. This library is best used for images and other controlled content for the site. Most communities don't just want to talk; they also want to share documents and, in the case of communities of practice, they may also co-create documents that might live permanently on the Community site or perhaps get published in another location when they are completed. Either way, your Community site will probably need a document library other than Site Assets. If you have a custom document Content Type for your organization, you will want to be sure that your custom document Content Type is attached to the Community site document library that you will create. One of the communities that I'm working with right now decided to call the library Resources (as in "resources for our community"), which seems much more meaningful than plain old Documents. (Of course, you can name the library whatever you want, but if your library name has two words, remember to create it with no spaces between the words to avoid the dreaded %20 in your URLs.)
Tip #6 Break permissions on the Site Assets library in your Community site
If you follow the recommendation in Tip #5, you will definitely want to break permissions on the Site Assets library and make it Read-only for all groups other than [Site Name] Moderators and [Site Name] Owners. Use this library to store the images for your discussion Categories and any other images you are using on the site, but when you break permissions on this library, all document content attached to discussions will automatically "land" in the Document library you created for Tip #5 and when the documents are uploaded, contributors will be prompted to enter the metadata associated with that library. One of my favorite features of SharePoint 2013 Community sites is that you are not able to attach a document to a discussion entry. I love this because it is a reminder that documents belong in document libraries and discussion entries should link to them. When you insert a document in to a discussion in a Community Site, you have the option of storing it in any document library where you have contribute permissions on the site. Once the document has been uploaded, it is auto-magically linked to the discussion post so that readers will be able to see the post and easily click to find the referenced document - but the document itself is more "findable" and certainly more organized because it is in a document library, not an attachment to a list item. You will still need to provide guidance to users that if the document already exists in a SharePoint document library on any site, they will need to grab the URL first and insert a hyperlink to the document in the discussion post. At least for documents that will live in the Community site, this is pretty easy way to make sure documents get to the right library with the right metadata. If you have multiple libraries on the Community site and your document somehow lands in the wrong library, you can move the document from one library to another on the same site and the link in the discussion post will not break, which is another pretty cool feature.
Tip #7 Think carefully about how you want to expose your community site
There are four different types of Community sites:
- Private - available only to invited members.
- Closed - read for all but only approved members can contribute. The owner gets an action request when someone wants to join or auto-approval can be enabled.
- Open with explicit action required to join (i.e. users click the "Join this community" button).
- Open with no explicit requirement to join. Anyone can participate without joining. Without joining, however, there is no automatic following of sites.
Microsoft suggests that most communities will be the third type - so that the discussions are visible to anyone in the organization who wants to "try before they buy" or "lurk" for a while before making a contribution. However, I think that there will also be situations where the first type (Private), will also be relevant - for example a site for Managers or Vice Presidents. If you chose to make your site Open but with no explicit requirement to join, you will lose the ability for users to have their communities automatically added to their followed sites list so this option will probably have more limited use.
Tip #8 Use the SHARE button to expose your community to prospective members
If you've followed Tip #3 and created your site with unique permissions, the easiest way to make sure that you don't screw things up is to expose the site to prospective users with the SHARE button. Assuming that you are following Microsoft's recommendation to use Community sites for groups of 200-300 or more, then you are definitely going to want to have an AD Group to use for permissions. If you are setting up a private community and you don't already have an AD Group for the community members, you will definitely want to create the AD Group before you share the site.
Tip #9 Think about creating each Community site as a new site collection
Microsoft recommends creating each new Community site as its own site collection for scalability, since you won’t always know in advance which communities are going to take off. If your community preceded your site, then you might actually already have an idea about how much content and activity the Community site will generate so you may be able to do a better job at predicting how much capacity your Community site will need. That said, you still have think about whether or not you will need or want to share site assets across communities because that can only be done easily if the sites are in a single site collection. The most important thing to remember is that the only way to have your community site listed in the new Community Portal is to create the site using the Community Site Template, which can be done whether or not the site is an independent site collection or a sub-site.
Tip #10 Watch out for Unanswered Questions
The Unanswered Questions view feels like a “not quite done” feature in the Community Site. A post appears in this view if the poster puts a check in the Question? attribute of a discussion entry. A question remains “unanswered” no matter how many replies it gets – until the Moderator or the original poster declares one (and only one) reply to be the “Best Reply.” In the real world, there is often more than one right answer to many business questions. Creating a single “best reply” for a question with more than one right answer means that the Moderator has to create a “compiled” answer and then declare it to be the best reply. This will take the question off the Unanswered Questions view (and move it to the Answered Questions view) but it will not award any reputation points to any of the people who contributed the answers that each became part of the official “best reply.” I think it will be more helpful (at least for the Moderator) to also create a “No Replies” views that shows questions that no one has answered and perhaps use likes or ratings to “bump up” answers that the community considers especially helpful. I would also like to see a way to “close” a question without having to specifically identify a single answer as the “best reply.” Right now, the only way to do most of this is to ask users to not check the box that indicates that a post is a question, which doesn’t seem like a viable strategy because it doesn’t really makes sense. My guess is that Microsoft will get a lot of feedback about the default discussion views so hopefully, we will see an evolution over time.
That’s my top 10 list for now, but I’m definitely going to update this list as we learn more and deploy to more communities. Please feel free to add your own tips to the comments. For additional information and an overview of the Community site template, I wrote a guest blog post on the presentation that John Pruitt and Robin Miller gave at SPC12 for Dave Coleman’s SharePoint EduTech Blog.