Wiki vs. KB

It’s been a hot topic of discussion internally: Should we start moving the data in the wiki to a more “manageable” solution? Will we alienate our users by removing the ability to create articles? Should we have both a wiki and a kb? How can we improve our online documentation?


Those are the questions that we’ve been discussing for a couple weeks now. . .and the discussion still isn’t over. We are not announcing immediate changes to the process. We still have some more internal discussion to take place before we implement full scale, however, some of you have noticed some the changes.

It’s important to us that we have an environment where users can freely post their hacks and tricks. . and document them for others. The recent wiki article from Drgath, JoseQ, Tk9O60, and Skyphyr about how to install Zimbra on Gentoo is a fantastic example of the community helping the community through the wiki.

We’re a very democratic company. Users post bugs and enhancement’s and the speed for which they are usually integrated based upon votes (Critical/Major bugs the exception). If we remove the wiki, then we would directly remove the ability for our users to create and write articles, lessoning the democratic process we set up.

The thing that we like about the wiki is that it is the ultimate democratic document source. The problem is, how do our users know if this is “Official Documentation” or not?

So, should we create a Knowledge Base? I decided to send out an e-mail to several people, and this started a pretty cool e-mail thread, in which many people gave their input. I also decided to ask some of our moderators, because it’s their community.

..the wiki is something of a jumble“, says one employee. “Today, the knowledge that does not make it as a general wiki page and is not discussed in a forum is trapped in each person’s head only“, says another.

The answer was pretty clear: Keep the wiki, and just improve it.

We’ve already begun to take action on this, and you’re gonna start seeing some formatting changes on the wiki.

As you know, we’re growing like crazy, and we want to be sure that the pages with hacks and tweaks are still in place. We also want to have a “live” updating documentation source. That way, as support tickets come in with issues, our support team can update pages, and make new ones as they see fit.

Here are the points we’ve decided on thus far:

1) Have pages that are marked as “Official Documentation” so that users know they are official. Lock them to prevent changes that may void support.
2) Allow users to continue to create their own pages with as many hacks, workarounds, and patches as they want. (ie no locked pages other than “Official” pages.)
3) Create colors with icons that display the status of each page (ie “Official”, “Out of Date”, etc).
4) Make the pages that have an informational header easy to find.
5) Get the support team more involved in creating and updating wiki pages.
6) On “Official” articles: create an editorial review process that ensures the articles are easy to understand, and accurate.

One thing that we’re conscious of, is our community’s ability to contribute to and control articles. That’s why only “Official” pages will be locked, with the logo/lock at the top. If you, or any member of our community, thinks an article needs changing or isn’t clear, you can use the talk page to let us know.

Here is the wiki page showing the different tags, and their usages.
ZimbraWiki Tags
We ask that you not use them quite yet, as we’re still trying to sort out what we want.

We’d want to hear your feedback on this!! Post a comment here, or pvt me in our forums: jholder

-jh

Comments are closed.

Copyright © 2022 Zimbra, Inc. All rights reserved.

All information contained in this blog is intended for informational purposes only. Synacor, Inc. is not responsible or liable in any manner for the use or misuse of any technical content provided herein. No specific or implied warranty is provided in association with the information or application of the information provided herein, including, but not limited to, use, misuse or distribution of such information by any user. The user assumes any and all risk pertaining to the use or distribution in any form of any subject matter contained in this blog.

Legal Information | Privacy Policy | Do Not Sell My Personal Information | CCPA Disclosures