Topic on Talk:Growth/Focus on help desk

Jump to navigation Jump to search

Improve workflow and allow storing common questions / answers in knowledge-base

5
197.218.81.145 (talkcontribs)

Design issue:

The design emphasizes asking questions rather than retrieving existing ones. It also doesn't seem to facilitate storage of common questions.

Background:

The greatest flaw of the wiki concept is inefficiency. Consider this, what is the question always asked by users? How many times has it been asked? How many person-hours and resources and money has been wasted answering the same question over and over again over the 15+ year wikimedia projects have existed? Finally, how many times has it been asked in other language projects? The answer to all those questions is that nobody knows. As it stands this system will make things worse by making it too simple to ask questions without verifying first.


Concrete issues:

  • The design has a checkbox asking to include a title.
  • There are three basic types of questions asked, each needs its own flow:
    • Technical questions - without platform details.
    • Trivia questions - "Why is there a naked picture???", "Is blue pokemon tougher than green?", "Why can't I add my blog?". A good number of these are worthless, the rest should probably be directed to the article talk page instead of a help desk.
    • Topic related questions - These questions may be useful and may help improve the page.
    • Spam question - someone just writing random stuff there

Possible Solutions

  1. Never allow the user to ask a question until they search first.
  2. Never allow a question without a topic.
  3. Always include page title as always an important context, oldid revision is also important.
  4. Most importantly, it would be preferable to have a way for end-users to promote certain questions to the help pane. Maybe each newbie reply would come with a link that enables users to save the question with a standard answer. This would increase the pool of questions / answers, and overall reduce the eventual work.

Improving questions

  • Technical questions
    • These must always (not optionally) require platform details (OS, Browser, etc). It is a waste of time to ask users these questions as follow-up.
    • It should also never be simply unstructured because it will result in a lot of unactionable or invalid reports. See VisualEditor/Feedback for a lot of messy questions, see also T86956
    • End-users often break their own interfaces using badly designed gadgets/ userscripts and browser extensions. First advise them to try to access the page using safemode, for example, https://www.mediawiki.org/wiki/pagetitle?action=edit&safemode=1, and possibly temporarily disable the extensions.
  • Trivia questions - should be discouraged, and the interface should attempt to strongly indicate these are not the point before the user posts a question.
  • Topic related questions - may need to go to the talk page instead of a help desk
  • Spam question - Add some basic anti-vandal measures, e.g. don't allow single repeated character, e.g. "AAAAAAAAAAAAAAAAAAAAAAAAAA", have a sensible input length limit, maybe add captcha when questions include a link.
197.218.81.145 (talkcontribs)
MMiller (WMF) (talkcontribs)

Thanks for thinking about this -- it sounds like you have a lot of experience with questions from newcomers. I think you're right that there are several things we could do to help structure and store questions, and therefore improve efficiency in the future. And in fact, most of our user testers said they would try to help themselves by looking at existing help pages before asking their own question.

There are a few things about our approach and our learnings that have made us

We plan to release the help panel in Czech and Korean Wikipedias in January, and we plan to iterate on it over the course of at least six months (potentially adding additional wikis along the way). We're going to keep close watch on what kinds of questions are asked and how productive the help panel seems, and we'll be able to make adjustments as we go along. If questions contain trivia, spam, or topic questions, we can change the workflow to encourage other types of questions. But we don't want to spend too much time engineering that system at the outset before collecting some questions to see how they turn out first.

Another thing we're thinking about is the secondary benefits of newcomers asking questions. The primary benefit may be that the newcomer gets their question answered and figures out how to proceed. But our research has also taught us that newcomers are more likely to stick around when they make positive contact with other editors, when they see that there is a vibrant community behind the project, and when they feel like they belong. Because of those things, we're not sure if we want to discourage asking questions in favor of reading answers to existing questions -- we're figuring out how to balance that. It might become a different story if wikis end up overwhelmed with too many questions. Does that make sense?

And with respect to including page title -- we wanted to try making this optional (but checked "on" by default) in case it turns out that there are users who don't want to disclose the article they're planning on editing. We anticipate that most people will leave it checked. If we find that almost no one unchecks the box, we may revisit whether it's important to have it. If we find that many people uncheck the box, we'll want to look into why.

197.218.84.60 (talkcontribs)

> I think you're right that there are several things we could do to help structure and store questions, and therefore improve efficiency in the future.

Seems to be something worth doing in advance, to save end-users and the developers a lot of unnecessary headache. Consider the difference between these two questions:

How do I get a reference to work?

vs

Question: How do I add a new citation / reference to a page?
Attempted steps: 
1. Open 2010 wikitext editor 
2. Clicked on the reference icon in the toolbar
2. The editing tool added <ref></ref>
3. Waited for a dialog
Expected
A dialog or anything to add a link or book or resource appeared
Actual:
No prompt to add anything, no help .

If "Question", "Attempted steps", "expected" and "actual" are different form fields, then question 2 is much useful than just a generic question 1.

> If questions contain trivia, spam, or topic questions, we can change the workflow to encourage other types of questions. But we don't want to spend too much time engineering that system at the outset before collecting some questions to see how they turn out first.

..

>Does that make sense?

This seems like a risky proposition. You may increase the burden on users, and then if the burden is too heavy you'll fix it? The fact of the matter is that the project deals with two variables it can't control, volunteers and development time. If they find it annoying they can simply ignore the questions, or answer badly and chase away newbies, or simply add automated tools to block such questions.

The project can be interrupted for any random reason, and it will leave users with a very limited basic tool. As an example, the tool being used here (Structured Discussions) was also an optimistic endeavor, yet it was mostly indefinitely halted in live sites, without even a simple ability to search existing threads, forcing users to have to rely on external search engines to find stuff here.

A similar endeavor exists in the English wikipedia's project teahouse with a question archive that allegedly doesn't even update anymore, and no sensible ability to search (https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions/Archive_Index). So there's a lot of history of limited tools being abandoned in place.

> in case it turns out that there are users who don't want to disclose the article they're planning on editing

That's a legitimate concern only if users haven't ever edited the page. If they have already edited it, then the fact that they've interacted with the page will be known anyway. Perhaps, a compromise would be to only show the checkbox if they've never edited the page in question.

MMiller (WMF) (talkcontribs)

Thanks for pointing out some valuable things to keep in mind. I hadn't seen that Teahouse archive link. As we roll this out, we're going to keep close watch on how much of a burden we're putting on the experienced editors by counting how many questions are answered and how quickly. We're also in touch on a weekly basis with ambassadors in the Czech and Korean communities, @Martin Urbanec and @Revi (WMF), who are preparing their communities for these incoming questions, and who will be able to tell us whether things are getting too burdensome.

Reply to "Improve workflow and allow storing common questions / answers in knowledge-base"