Migrate Cisco DocWiki to the Community

[Jonathan Schulenberg]

There is a poorly utilized public-facing Cisco Document Wiki. I believe that CSC would be a more useful, widely adopted, and better fit for the documentation content that exists in the DocWiki.

• CSC is already targeted at users seeking configuration and troubleshooting support. Users already come here - and ideally search - for content.
• CSC has a much larger user base - including contributors - who could enhance the BU-provided documentation.
• Jive SBS provides browser-based documentation creation and maintenance tools as well as spaces or groups to properly organize the content.

What do others think of this?

Are there any other advantages or disadvantages you can think of?
Are there any internal rules or policies that would prevent this from happening?

[Joe Clarke]

Thanks for the idea, Jonathan.  And thanks for your contributions to CSC.  The idea of merging Doc Wiki with CSC is something we have discussed internally.  However, there are some reasons why they are being kept separate for now.  One of the primary reasons is the organization of content.  As you know, CSC is structured on technologies categories or areas.  The Doc Wiki team wants to be able to categorize documents based on platform or specific technology (e.g. ASR9K, BGP, SNMP, etc.).  CSC can do this kind of classification using tags, but the ability to browse and navigate content on tags is not perfect right now in CSC.  We are looking at ways to improve this in the future.

As for enhancing CSC content creation, we have a big initiative going on in the TAC right now to get more internal participation on CSC.  You've probably already started noticing more docs and blogs by TAC engineers.  This is only going to increase, so CSC is definitely the place to come for good technical content.

[Jonathan Schulenberg]

One of the primary reasons is the organization of content.  As you know, CSC is structured on technologies categories or areas.  The Doc Wiki team wants to be able to categorize documents based on platform or specific technology (e.g. ASR9K, BGP, SNMP, etc.).

I have done some work with Jive SBS in another capacity. Personally I believe we should consider an expansion of the existing community hierarchy to find a common ground between both teams. This likely could match the Cisco.com product organization structure. The existing community structure and functionality could be maintained since users could continue opening discussions at the technology level (e.g. Contact Center) or the individual platform level (e.g. Contact Center Express). This would allow discussions and documentation to coexist in a single logical hierarchy.

Example:

• Collaboration, Voice and Video
  • Contact Center  <-- Existing community remains.
    • Contact Center Express and IP IVR <-- New platform-specific communities for documentation, videos, documents, etc
    • Contact Center Enterprise
    • Workforce Management
  • IP Telephony
    • Communications Manager
    • Communications Manager Express
  • etcetera

In my opinion, this would go a long way toward condensing the currently very disparate information sources. Official BU documentation could be locked to prevent editing as I sense that as another reason for holdout. It would also better utilize the other features of Jive SBS such as video, blog, and possibly even private projects for things such as EFTs.

[Joe Clarke]

We're looking at doing something like this.  That is, abstract the interface from the Jive platform so that we can take advantage of things like tagging, and present content in a more flexible way.

As for using content for EFT, absolutely!  We're also pursuing private community options where by we will enable communities for EFTs where customers can collaborate with other EFT users and BU representatives.  When the EFT goes FCS, the community can be opened up with all of the content that is still current relating to the product/technology rollout.