Cisco Blogs


Cisco Blog > Inside Cisco IT

Pruning Your Community Garden: an Approach to Community Lifecycle Management (Part 1)

All enterprise social collaboration platforms include gathering points whereby people can unite with others around a common goal; for example, a program or project, social interest, organization, market segment, product, corporate initiative, technology, etc. Within Quad – Cisco’s Enterprise Collaboration Platform and product – these gathering points are referred to as communities. The longevity of any given community will vary based on several factors, which include temporal needs, relevancy, and usefulness. Some communities will be required for a long time while others may only be needed for a short time. Without clear mechanisms to identify the usefulness of each community and manage those that reach end of life, a social collaboration platform can become difficult to manage from a community governance vantage point. The performance of the platform can be negatively impacted by excessive community clutter resulting from orphaned or unused communities.

Specifically, community administrators and owners need a way to access and manage their respective community gardens and prune away communities that are no longer useful. In this blog I describe the initial phase of community lifecycle management processes and tools that Cisco IT is introducing in partnership with the Enterprise Collaboration Platform Business Unit and the Collaboration Business Technologies team, to support community health in Cisco’s Integrated Workforce Experience (IWE) program.

Cisco IT’s current internal Quad release introduces a click-to-create community feature that allows a user to request and immediately receive a provisioned, ready-to-use community. For more on the community click-to-create request and approval processes, see:  http://blogs.cisco.com/ciscoit/fostering-collaboration-through-light-handed-community-governance/.

Our current approach to IWE community lifecycle management involves augmenting Quad’s inherent functionality with three new components: a Community Lifecycle Management portlet, a virtual community lifecycle state attribute (one initially with several others in the works), and configurable community end-of-life workflow rules to meet Cisco’s legal needs for intellectual property and data retention. The Community Lifecycle Management portlet provides community owners and administrators with visibility into their respective community gardens and the tools to prune as necessary.

There are three different community lifecycle states that can result from the click-to-create request process: Draft Mode Pending Approval, Draft Mode Approved, and Draft Mode Declined (see Figure 1).

Once a community is in the Draft Mode Approved state it can be promoted to a live community (launched) by any of its respective community owners, simply by activating the “Go Live Button” (see Figure 2).

Virtual community lifecycle state attributes allow us to augment the base lifecycle functionality provided by Quad’s lifecycle states. For our current internal Quad release we have established a virtual lifecycle state attribute framework and incorporated a single virtual lifecycle state attribute that will be used to reflect whether or not a community has been marked for deletion (see Figure 3).

Through the addition of the “marked-for-deletion” attribute we are able to provide community owners and administrators a way to safely prune the community garden in two steps. In the first step a community owner can mark any of their communities for deletion from the context-sensitive drop-down actions menu within the Community Lifecycle Management portlet; a community administrator can mark any community for deletion using the same mechanism. Once a community has been marked for deletion it carries this virtual lifecycle state attribute along with its actual Quad-specific community lifecycle state (Draft Mode Approved, Draft Mode Declined, Live, etc.) until the process is either reversed (the community is unmarked for deletion and the virtual lifecycle “marked for deletion” attribute is removed) or the community is actually deleted.

The second step in deleting a community can only be carried out by a community administrator for those communities that hold the “marked-for-deletion” attribute and that are eligible for deletion. For a community to be eligible for deletion it must have held the virtual “marked-for-deletion” lifecycle state attribute for a period of time that exceeds the time-to-live setting for the category in which the community is associated.

Cisco IT has just begun its journey to provide robust community lifecycle management capabilities into IWE. Some of the additional features we are working on include the creation of an archived lifecycle state, the ability for community owners and administrators to archive a community and restore a previously archived community, a second virtual lifecycle state attribute to reflect a community in terms of its activity levels, and the heuristics to auto-magically determine a community’s activity level based on some combination of community visits, visitor types (e.g., member vs. non-member), content updates, and the purpose of the community (e.g., reference or social). In my next blog I will describe the role that the Community Lifecycle Management portlet plays in helping us to keep our community garden pruned and healthy.

Tags: , , , , ,

In an effort to keep conversations fresh, Cisco Blogs closes comments after 60 days. Please visit the Cisco Blogs hub page for the latest content.

2 Comments.


  1. Hi Michael,

    Thank you for another informative article.

    Why must a community have the “marked-for-deletion” flag set for a period of time before it can be deleted? For instance, are there some cases where an administrator would want to delete a community immediately?

    Kind Regards,

    Gary

       0 likes

    • Michael Marquiz

      Thank you Gary for the kind words and the question.

      The marked-for-deletion flag provides a layer of protection against an accidental and immediate delete action in that it facilitates a two-step process before a community can actually be permanently deleted. However, you raised an excellent point about an administrator needing to sequester away a community for some reason. The challenge with immediate deletion is that there are corporate policies regarding content retention; especially since a community is a container for all types of social content (documents, discussions, wikis, blogs, etc.). To not completely handcuff the community governance processes, there is a “Deactivate” option available to Community Lifecycle Management administrators that will take a community out of the purview of all except for Lifecycle Management administrators. That is, a deactivated community and its associated content is invisible and sequestered away until such a time as it becomes eligible for deletion. The deactivate and reactivate options will be described in “Pruning Your Community Garden: An Approach to Community Lifecycle Management (Part 2)”.

      Best Regards,
      Michael

         0 likes