Provide an easy to use support system for contributors to ask technical questions
Open, NormalPublic

Description

NOTE: The documentation of this task can be found at https://www.mediawiki.org/wiki/Discourse

Previous description

Emerged from a discussion about annual plans at technical collaboration's team offsite.

The idea is to help solve the problem of duplicate queries that we get on mailing lists, make it easier for users to search through the existing queries and get answers, and enable new contributors to ask questions, etc.


Open questions:

  • Yet another forum or rather a Q&A system? See T31923: Install Q&A system at ask.wikimedia.org.
  • Which discussion forum would be best for our purposes?
    • Stack Exchange?
      • Own install or install on the StackExchange cluster?
      • Pros:
        • Would probably become a great way for attracting volunteer devs.
        • Answers searchable & updatable, unlike mailing lists
      • Cons:
        • Not open source (open content, though).
        • If we create a new site, we miss out on most of the network effects. If we use an existing site, all of them seem like awkward fits. (StackOverflow would be good for writing MediaWiki extensions; ProWebmasters and ServerFault for running your own MediaWiki; Web Applications for using MediaWiki as a service; SuperUser for using MediaWiki as a user. We want all of that but don't want to be fragmented into several sites.)
    • A StackOverflow open source clone which we host ourselves?
    • Discourse? (see also T124690)
    • Phabricator integrated forums - Ponder (or Nuance?)
      • Quim gave a small demo at the session in the Hackathon
  • What'll be the scope of the forum?
  • What's the timeline for this?
  • [Low priority] Migration of existing content from Wikitech-l at some point?

See also:

Related Objects

There are a very large number of changes, so older changes are hidden. Show Older Changes

I think the main drawback with StackOverflow is that we'd be splitting things over a number of different Stack Exchange sites: https://stackoverflow.com/ for programming, https://serverfault.com/ for sysadmining, https://webapps.stackexchange.com/ for MediaWiki administration, https://webmasters.stackexchange.com/ for general website stuff... there are more that would probably be relevant. Of course, some projects have their own stack exchange sites, e.g. https://drupal.stackexchange.com/ and https://wordpress.stackexchange.com/ spring to mind, so perhaps there's an option for https://mediawiki.stackexchange.com/ (I think it was proposed once, but they don't keep old proposals visible, or at least I can't find it).

I've enjoyed the small amount I've used Discourse in the last year or so. Seems that there might be a slight disadvantage with it in that we don't seem to have many developers active in the Ruby world, so contributing (and possibly sysadmin stuff?) is trickier.

Qgil added a comment.Nov 10 2017, 11:52 AM

I don't think the Ruby argument is very relevant or relevant at all, honestly. The idea of contributing to the project is nice, but does it hold in practice? There was an expectation for community contributions to Phabricator because it is written in PHP. In practice, we have paid for the missing features that we were missing most (and perhaps it is fine to do so, I'd rather have Wikimedia developers working in Wikimedia projects). The Discourse community has a pretty straightforward process to bid for paid projects in a marketplace.

Also, we know that the current developers of our community (and especially the ones that are so busy and have enough projects already) are more fluent in PHP than Ruby. What we don't know is how fluent in Ruby are other developers that would be interested in contributing to Wikimedia. For instance, could there be Wikipedia fans/editors in the Discourse developer community? And just as it happened with Phabricator, requesting features as Wikimedia might help prioritizing those requests in Discourse's roadmap. Since yesterday I'm in touch with one of their founders (I saw him as mentor in the new list of Outreachy projects) and his first request was to let them know if we find any blockers in our current discussions.

I think we should give it a try.

+1 to trying Discourse. Seems to be pretty good for our needs. What's the next step?

+1 to trying Discourse. Seems to be pretty good for our needs. What's the next step?

Getting https://discourse.wmflabs.org/ fixed.

Qgil added a comment.Nov 10 2017, 9:55 PM

I think a better next step is to get a fresh new instance up & running, so we can start customizing with the developer audience in mind, have the admins that will be in charge, and so own.

The instance that is still down is a prototype that was testing synchronization with mailing lists like wikimedia-l and a structure of categories per project (Wikipedia, Wikisource...). That is still an interesting experiment but I would not interfere with it.

Good point @Qgil, about not needing to stick to PHP.

What should the 2nd site be called? mwusers? mwforum? Should the current discourse.wmflabs.org be renamed, so the two sit alongside each other in an obvious way?

(Talking of Discourse, I just noticed https://wam.wmflabs.org/ is a Discourse site. Are there any others?)

Qgil added a comment.Nov 13 2017, 10:16 AM

It is time to start documenting all this in a wiki page, in order to communicate the plan and start a proper coordination around it. Let' s say that the first goal would be to have a wiki page with enough information to involve Operations,, so they know that there is a plan to bring a new tool to production in the future.

URL. We have a tradition of keeping the name of the tools in a subdomain. Therefore, I would aim for discourse.mediawiki.org as a final URL.

However, we will start in wmflabs. The subdomain there in the interim is less important. discourse-mediawiki.wmflabs.org?

srishakatux reassigned this task from srishakatux to Qgil.Nov 13 2017, 7:43 PM

I think it makes sense to keep the tool name in the URL. So we'd have discourse-mediawiki.wmflabs.org and discourse.wmflabs.org to start with, which would (if sucessful) move to discourse.mediawiki.org and discourse.wikimedia.org? @Niharika I think there's too much similarity between discourse and discuss for them to be used for different things.

I think the page at https://www.mediawiki.org/wiki/Discourse would be a suitable on-wiki place wouldn't it? It's currently all about the Wikimedia Discourse instance, but that's also well-covered in its proper place of https://meta.wikimedia.org/wiki/Discourse

Who will set up the new one? The existing instance's maintainers (@Andrew @Austin @EBernhardson @Tgr @yuvipanda) seem busy or not available? It sounds like setting up multiple sites on one host is possible, but perhaps we'd want to keep them more separate and just treat them as independent projects?

The very first thing I see on the test page at Discourse is it's allegedly missing RTL support? Isn't there a minimum set of requirements we should think about before picking a tool?

The very first thing I see on the test page at Discourse is it's allegedly missing RTL support? Isn't there a minimum set of requirements we should think about before picking a tool?

People can apparently create topics and reply in RTL languages. For example. It's just the UI which doesn't flip as it should. That's a relatively steep requirement and I don't think even StackExchange supports it.

Qgil added a comment.Nov 15 2017, 9:17 AM
  1. Log in to https://try.discourse.org/
  2. Go to Preferences > Interface
  3. Select Arabic (ar)
  4. Save preferences and reload

Enjoy!

Hebrew, Farsi and Arabic appear among Discourse's top 15 languages in terms of % of translation. There must be Discourse instances in these languages out there, even if RTL support has bugs .

This means that Wikimedia users willing to have their Discourse interface in these languages will be able to do so. We can expect discourse.mediawiki.org contents to be primarily in English just like all the other developer support channels that we currently have. A multilingual developer support forum is a beautiful idea, but (just like with Phabricator) not a goal in our current plans.

Tgr added a comment.Nov 16 2017, 7:24 AM

I am using Discourse as a user and as an admin. We don't have anything on-wiki that will provide the user experience at the level of this tool, and probably we don't aim to (our focus keeps being wiki collaboration, discussion is a side effect). Also, it is a very good tool to engage newcomers and to engage people who like to provide support, moderate...

I'd hope Flow aspires to eventually reach similar levels of user-friendlyness... but yeah right now not really.

In practice, what specific features of a Q&A would we really miss with Discourse? There is a lot of fuzz about upvoting, but Discourse allows to convert first posts into wikis, which fits more in our culture. And anyway, our problem by default is not to get enough answers to people asking, instead of getting so many that we need to upvote.

Upvoting is important on a large site with lots of people answering (especially when there is an incentive to answer so you get some low-quality answers). For MediaWiki there is no real need; even on StackOverflow voting is largely defunct in MediaWiki-related questions due to lack of interest - the original poster gives one vote to all the answers and that's it.

Some features of StackOverflow that I like:

  • The two-level system of answers + comments on answers works really well for clarifications, pointing out mistakes, etc. In a forum discussing an answer does not result in anything easily parsable.
  • A lot of effort goes into surfacing similar questions, both while you are composing your question and when reading existing questions. That probably saves a lot of human effort.
  • Every question and answer is basically a wiki page, users with high reputation can edit it, users with low reputation can suggest edits. Although I think Discourse has something like that too.
  • The review queues are also great: problematic questions/answers/comments/edits/whatever get sorted into a few categories like "low quality" and "probably needs to be deleted" by a combination of software heuristics and user flagging, and users with sufficiently high reputation can go through the queue with a custom interface and do stuff (reword low-quality questions for clarity, close out-of-scope questions, reopen wrongly closed questions, review suggested edits etc). There is lots of distributed decisionmaking cleverness (a question is closed after five close votes, but goes into the close queue after the first to make sure it receives sufficient attention) and the interfaces are hand-tuned for each queue and work really well.
  • The gamification features (badges, reputation-based access controls) work very well. I suppose Discourse has something similar though; and not sure we'd want it in the first place (the Wikipedia approach is culturally very different).

Making StackOverflow our official support site seems odd to me in many ways. Also, that site is mainly for sysadmins and we are talking about developers, there is little overlap currently.

StackOverflow is for developers (ServerFault is for sysadmins), but yeah, fragmentation is a problem (as mentioned in the task description).

I don't think the Ruby argument is very relevant or relevant at all, honestly.

I think the effort I've put into writing an OAuth plugin for it (three days or so) would have been enough to get it done, were it written in a sane language like PHP or Python.

There was an expectation for community contributions to Phabricator because it is written in PHP. In practice, we have paid for the missing features that we were missing most

We have written an authentication plugin, an agile stats plugin and probably other things.

I think we should give it a try.

We absolutely should; we probably want discussion forums (at least until Flow matures, but not sure it will ever serve the same use cases), Discourse is the best for that, using it for Q&A as well to cut down the number of things we maintain is definitely something we should consider. I just don't think we should use that as an excuse to not try other things.

Is Discourse OK from a safety/privacy policy POV? (Back to my "minimum set of requirements we should think about before picking a tool" point.)

Tgr added a comment.Nov 16 2017, 11:04 AM

Software on Cloud VPS has no security/privacy guarantees. Apart from that... probably? It's a professional project run by some well-respected people like StackOverflow co-founder Jeff Atwood. (In any case, it can't be less secure than Mailman that sends you back your password in plaintext every month and does not have per-user admin passwords... our standards for communication tools are actually not that high.)

Qgil added a comment.Nov 16 2017, 12:21 PM

@Tgr thank you very much for your analytical reply. And yes, there have been contributions from Wikimedia to Phabricator that were helped by the fact that it is written in PHP.

  • The two-level system of answers + comments might come officially in the future, and if we needed so badly there is at least one plugin out there that offers that (and also upvoting, see an example). However, I would advocate to start simple with a plain installation and see how that goes. Just like upvoting, nested replies for answers + comments make more sense in long threads with many answers. I still fear more the problem of not having answers to questions. ;)
  • When you are creating a topic, Discourse shows you similar topics automatically. It also has an algorithm that shows "related topics" at the end of the discussion, but I don't know how useful that might be to detect duplicates.
  • Currently first posts can be converted to wiki, not the rest.
  • There is no way that I can see to categorize automatically posts of potentially low quality. Again, this might not be a problem with a low traffic site. Needing heuristics to process the quality of new questions from developers would be a great problem to have!
  • Discourse has badges and achievement-based access controls, highly configurable. This is something that Discourse implements very well, and I see it as a strong factor to choose this tool over other, even our own. I believe defaults will work very well in our community. Achievement related badges are very good engagement tools. Access controls are obtained as the user accumulates actions and experience, which is a good way to offer simpler functionality to newcomers, prevent too easy spam and grant permissions automatically to those who clearly have chances to make use of it.

Another useful feature of Discourse is that it can export whole categories (to json, by the sounds of it). So we could make those dumps available, if desired. (I'm not sure how it handles private topics etc.)

Qgil added a comment.Nov 17 2017, 5:18 PM

First stab: https://www.mediawiki.org/wiki/Discourse

I'll try to complete a first decent draft later today an share it at wikitech-l. I am also planning to create a subtask about the creation of the new discourse-mediawiki.wmflabs.org instance to discuss technical details.

Qgil updated the task description. (Show Details)Nov 17 2017, 10:06 PM

I don't understand how the current proposal at https://www.mediawiki.org/wiki/Discourse fits with the stated purpose. Discourse is a forum system, not a Q&A system. It may compete with existing discussion venues such as mailing lists, IRC and Phabricator, but it's not a support system. I don't see any benefit in adding yet another forum.

The page https://en.wikipedia.org/wiki/Q%26A_software lists some criteria for a Q&A system (T31923). Askbot is the clear winner if we want a self-hosted instance.

Qgil added a comment.Nov 18 2017, 9:13 PM

Discourse can be used as a support system. We have discussed features that we would miss (T155678#3750581, T155678#3765636, T155678#3766315 ) and they don't seem to be critical for our goals.

We want to support developers, especially newcomers. The ultimate goal is not to answer questions, even if this is an important factor in the mix. The ultimate goal is to attract new developers and retain them. There is the hypothesis that a more flexible tool will be able to handle questions/answers properly and also become the nice and welcoming landing space for newcomers that we don't have. Strict Q&A systems are to be used for questions, and users leave when they get their answer.

Discourse can be used as a support system. We have discussed features that we would miss (T155678#3750581, T155678#3765636, T155678#3766315 ) and they don't seem to be critical for our goals.

These don't address the basic features of a Q&A system, described in the link I gave.

For instance, how do you even mark a topic as resolved, without clunky workarounds? https://meta.discourse.org/t/issue-resolved/28483
Even on-wiki discussion is better in that regard.

Let alone selecting the best answer among multiple which were provided, improving the best answer and so on. A forum system is a thoroughly inappropriate solution for the stated problem. If your goal is just to add another chatting venue it might be fine though.

Qgil added a comment.Nov 19 2017, 4:32 PM

@Nemo_bis if before or during the pilot (or at a later stage) we miss this functionality, we can install this plugin officially supported since June 2015:

Discourse Solved (Accepted answer plugin)

The Discourse Solved plugin allows users to accept solutions on topics in designated categories.

And how do you propose to gauge whether the functionality is missed? It's not about feelings, it's about choosing solutions which fit the stated purpose. Again, it's fine to just state you want one more chat/discussion system: people keep creating new ones all the time, it's not like it will be the end of the world.

Tgr moved this task from Backlog to Next on the User-Tgr board.Nov 21 2017, 7:05 AM
Qgil added a comment.EditedNov 21 2017, 9:23 AM

And how do you propose to gauge whether the functionality is missed?

What about continuing this conversation? :)

I'm not against adding Discourse Solved (Accepted answer plugin), not at all. I just think that any plugin added to the default install deserves a discussion.

In this case we are talking about a stable plugin officially supported. The options are:

  • Let's start without this plugin, and check again (say) after a few weeks of pilot.
  • Let's start with this plugin since the beginning.

Opinions?

There are many orgs. that use Discourse as a Q&A system, and help new developers navigate documentation/code. Here are several that jumped out to me, and there are many open source projects using this platform. Here are some of the boards I found, if people would like to see how others orgs. are using this:

Mozilla: https://discourse.mozilla.org/
Twitter dev: https://twittercommunity.com/
Glowforge: https://community.glowforge.com/
Discourse: https://meta.discourse.org/
Atom: https://discuss.atom.io/

More: https://www.discourse.org/customers

There are many orgs. that use Discourse as a Q&A system, and help new developers navigate documentation/code. Here are several that jumped out to me, and there are many open source projects using this platform. Here are some of the boards I found, if people would like to see how others orgs. are using this:

Mozilla: https://discourse.mozilla.org/
Twitter dev: https://twittercommunity.com/
Glowforge: https://community.glowforge.com/
Discourse: https://meta.discourse.org/
Atom: https://discuss.atom.io/

More: https://www.discourse.org/customers

https://discourse.phabricator-community.org/ :)

Qgil raised the priority of this task from Normal to High.

So I started to play with discourse. One thing I wonder is what scope should this new discussion tool should target to have good chances to be complementary rather than a competitor with existing canal – if there is no long term goal to close some of them.

What are the question one should ask in order to decide to post its thoughts on phabricator, mailling-list, discourse, IRC, or some wiki talk page? I willingly exclude third parties such as stackoverflow.

Some activity diagram might be interesting here. By the way, is it possible to create plantuml diagrams within phabricator?

Qgil added a comment.Dec 27 2017, 1:28 PM

@Psychoslave about scope, it is explained at https://www.mediawiki.org/wiki/Discourse#One_place_to_seek_developer_support

This new channel is for developer support. If you are a developer and you have questions, this will be the place to ask.

That's it. If someone wants to propose other use cases, they will have to be discussed and agreed case by case, taking care of eventual closure of channels used for that same purpose.

Qgil added a comment.Dec 27 2017, 1:32 PM

Let's consider the plan for a pilot approved. There has been enough support to start the pilot. Some concerns have been raised, but none of them are considered blockers for the pilot.

Let's continue the work at T180854: Create discourse-mediawiki.wmflabs.org (pilot instance).

Let's consider the plan for a pilot approved. There has been enough support to start the pilot. Some concerns have been raised, but none of them are considered blockers for the pilot.

You hijacked the "Discourse" page on mediawiki.org in November 2017. Now, in December 2017, you are declaring the page you wrote to be approved by yourself? This is a bit bizarre.

Tgr added a comment.Dec 29 2017, 3:23 AM

You hijacked the "Discourse" page on mediawiki.org in November 2017. Now, in December 2017, you are declaring the page you wrote to be approved by yourself? This is a bit bizarre.

Please don't troll.

Please don't troll.

I'd say that throwing the "troll" word is an act of trolling here.

Generally speaking: If you have specific and constructive criticism, bring up specific constructive criticism.
The change summary from Nov 2017 says "Taking the liberty to dedicate this page to the discourse.mediawiki.org plans, since meta:Discourse covers already the rest."
If you have issues with that, explain your issues if you are interesting in solving issues. Accusing folks of "hijacking" isn't explaining your issue.

If you have issues with that, explain your issues if you are interesting in solving issues. Accusing folks of "hijacking" isn't explaining your issue.

My "this" referred to declaring the page/plan approved, not to hijacking that particular page title on mediawiki.org. Closing a discussion as having consensus that you both started and heavily advocated for a particular outcome in, to me, lacks propriety. I see it as a clear conflict of interest and a violation of basic principles such as https://en.wikipedia.org/wiki/Nemo_iudex_in_causa_sua.

Skimming this task, it seems like no amount of arguments against pursuing Discourse were going to work, though plenty of valid points have been raised yet again by Tgr and others. A few people are convinced there's a real problem and that introducing another forum will be the solution.

Qgil added a comment.EditedJan 2 2018, 1:59 PM

The proposal was announced on November 17. There was an initial wave of feedback and then some more comments and questions. The result of this feedback was a more complete plan to start this pilot (see diff). Meanwhile, support for the pilot was also confirmed from the Wikimedia Cloud Services and the Operations teams, ans it also got green light from the CTO.

The conversation has been pretty much inactive since the beginning of December. While there arae potential blockers and questions marks to have such service deployed in production, none of them block a pilot. Some of the questions actually welcome a pilot to proof whether such new space is needed and more effective than the ones we have.

For all these reasons, I believe it is reasonable to decide that the proposal made 6 weeks ago has enough support to move forward and start the pilot.

The conversation has been pretty much inactive since the beginning of December.

Perhaps because people who were active in the discussion earlier saw no reason to repeat their arguments. For instance, the diff you mention doesn't address any of my points.

Qgil added a comment.Jan 2 2018, 4:40 PM

Your points made in this topic were addressed above. The plugins that would provide functionality that you were mentioning were documented in the wiki page.

Qgil added a comment.EditedJan 2 2018, 4:46 PM

@Nemo_bis, you seem to be concerned about using Discourse as opposed to a QA specific software. The decision to run this pilot on Discourse is compatible with T181377: Set up test instances for popular Q&A software. We can try different options, compare, and then see what technology selection we make for a service deployed to production.

Qgil lowered the priority of this task from High to Normal.Jan 9 2018, 2:28 PM

After the announcement of https://discourse-mediawiki.wmflabs.org/ , the test pilot starts.

He7d3r added a subscriber: He7d3r.Jan 15 2018, 7:09 PM

Sorry for the dance of tags. We are rearranging some things.

Let's consider this task a support request from the Developer-Advocacy team. I keep owning it and I plan to resolve it either way during this quarter.

saper added a subscriber: saper.Aug 27 2018, 5:38 PM
saper added a comment.Aug 27 2018, 5:40 PM

Maybe a solution could be solved with federated networks like T198363: Consider ways to integrate with federated social networks ? One might define additional activity to "mark answer as correct", or for upvote/downvote if such features are desired.

Qgil added a comment.Aug 27 2018, 8:34 PM

@saper Do you mean to build a web application for Q&A based on ActivityPub from scratch? Or to add features to i.e. Mastodon?

Search is a key functionality for any Q&A system, and search is probably the weakest functionality of federated networks, almost by design.

At least when it comes to the scope of this task, I still think the right approach is to continue with the Discourse pilot in the direction of T180853: Bring discourse.mediawiki.org to production .

Yes, but the search can be made better. Discourse is almost good, but it has a habit of limiting brand new user options, which is a big limitation of a Q&A system. But it can be configured not to do this (giving more options at the level 0).

Regarding the first question I'd think we could do it in a step-by-step approach: take something ready to use (Mastodon/Pleroma/whatever) and see how that could fit and work from there. Then we'd have at least a something to extend OR a pilot experience with requirements for a good custom system if needed.

Of course, if ActivityPub federation could be added to Discourse, even better - but I think this is hard since Discourse is very opinionated of the content that is being fed into it, so I don't think it can be made to federate easily.

Qgil added a comment.Sep 11 2018, 10:13 AM

Discourse is almost good, but it has a habit of limiting brand new user options, which is a big limitation of a Q&A system.

Those limitations can be configured via admin interface. In any case, developing a Q&A system based on ActivityPub (something that as far as I know nobody has attempted) sounds like an option well above our ambition here.

Back to Discourse, today I took a look to the admin dashboard and extracted some metrics:

https://discourse-mediawiki.wmflabs.org/t/past-the-50-users-mark/113/4

My quick & brief read is that Discourse is accomplishing its functions as a developer support space (most of the developers landing there with questions get a reply fairly quickly) but maybe it is time to promote this space decidedly.

I am going to work on it again, helping the Developer Advocacy team to bring it from pilot to production unless someone comes with a better plan.

(Possibly not a support task though? :) )

(Although not a pure support task because it mixes my previous responsibilities in Technical Collaboration, I am doing this work for Developer-Advocacy.)