Simon and Greg have basically made all the points that are relevant. There's nothing inherent in the Wiki that makes it have poor technical documentation. A Wiki is only as good as its authors. If the Help Desk updated the Case Wiki rather than Right Answers, the only difference would be that it would have all those positive aspects that Greg mentioned. (Plus not as many javascript links to open a new window)

It's true that you have to kinda know things to update a Wiki. My mom couldn't update a wiki, but she couldn't update RightAnswers either. In some cases, there will be a technically knowledgable person who can update the Wiki though, and in that case, they can do so. Right Answers = :(

From a more practical aspect, it seems any sort of boilerplate "open a ticket" or whatever links could be placed in some Wiki template and inserted at the bottom of help articles. As mentioned before, maybe a Case only link to information on contacting the help desk.

Greg: How easy is it to make a Wiki page viewable by Case ID owners? Could it be a {{wiki command}}?

The main bad thing that I could see happen is someone vandalizing the wiki page. There are, I think, a number of people watching the Recent Changes page of the wiki who might notice such a thing, and if the Help Desk people are using it all the time, they might notice too. Because all Wiki edits are non-anonymous (you must have a Case ID), it is pretty trivial to ban a user for malicious editing, and I think it has even been done before.

+Chris

Christopher Hess:

A Wiki is only as good as its authors. If the Help Desk updated the Case Wiki rather than Right Answers

Which takes us right back to what I said before; the content matters. And I think it matters more than the bucket you put it in.

That said there are certainly a lot of differences in our bucket choices and they all have their pros and cons. One of the pros of Right Answers is the gobs of pre-written documentation for Microsoft Office and other common applications. One of the cons is the ease of updating. Yes, a Wiki would be easier to update. I love wiki's, though they still have cons of their own. For one they can't make a good cup of cappuccino and secondly they can all too easily become frequently updated repositories of incorrect information depending on who is adding content.

John knows a lot more about the project than me so I will bow to his expertise in all matters Right Answers.

Christopher Hess:

From a more practical aspect, it seems any sort of boilerplate "open a ticket" or whatever links could be placed in some Wiki template and inserted at the bottom of help articles. As mentioned before, maybe a Case only link to information on contacting the help desk.
Greg: How easy is it to make a Wiki page viewable by Case ID owners? Could it be a {{wiki command}}?

Well, since it is a wiki, there are no established rules for preventing someone from inserting a boilerplate template on every computer help article. The computer help template already has a link to the Help Desk article at the top of the list. Unfortunately, the Help Desk article isn't the best article in the world. I was kind of hoping a PerceptIS employee would eventually fix that...

The second question is about making a wiki page viewable only by Case personnel. We once had this feature enabled, but it was removed for multiple reasons, including security and the original intentions of the Case Wiki. There has been talk of establishing a wiki farm, which is a hosting environment for wikis. Basically, you can go to a site, fill out a form, and create a wiki that can only be viewed, edited, etc, by the list of people you see fit. However, before this becomes a reality, we need a way to manage groups of people. Jeremy Smith and I have been discussing this for a while. However, I'm not sure where it stands in the priority list.

Gregory Szorc:

The second question is about making a wiki page viewable only by Case personnel. We once had this feature enabled, but it was removed for multiple reasons, including security and the original intentions of the Case Wiki. There has been talk of establishing a wiki farm, which is a hosting environment for wikis. Basically, you can go to a site, fill out a form, and create a wiki that can only be viewed, edited, etc, by the list of people you see fit. However, before this becomes a reality, we need a way to manage groups of people. Jeremy Smith and I have been discussing this for a while. However, I'm not sure where it stands in the priority list.

So you CAN make a page Case-only? Is this something users can do or only administrators? Could you make a Category Case-only?

Christopher Hess:

So you CAN make a page Case-only? Is this something users can do or only administrators? Could you make a Category Case-only?

No, you can't. We had a patch installed that enabled this, but it was removed. I have entertained the idea of a Case-only namespace or category, but the fact is that MediaWiki, the software powering the Case Wiki, does not have a well-built security model. For example, there are patches that limit access based on namespace, category, etc, but editors can get around these limitation by moving articles or using the page tranclusion feature ( {{Case:Super Secret Page}} for example) to bypass the security. The solution is to patch MediaWiki to have a good security model or to deploy a wiki farm. As the former is not the intention of the MediaWiki developers (because it is a feature that would not benefit Wikipedia) and we wish to keep our MediaWiki code base as common as possible to the default, the latter is more likely. But, as I said, a groups web service is needed first...

Define "groups web service"

+Chris

Christopher Hess:

Define "groups web service"

It is a centralized web service that exposes a person's affiliations. You query a person, and it will list what groups (USG, staff, student, faculty, e-mail list membership, etc) to which a person belongs, much like LDAP does, except not LDAP because not all group membership is or will be stored in LDAP. Data will most likely be exposed as FOAF.

Thanks all for an excellent discussion!

One final comment - the Case wiki & RightAnswers are not mutually exclusive systems.

Ultimately, what matters is the quality of support available to the Case community. It is perfectly appropriate, in my opinion, to have both systems available as they each fill different but complementary roles.