Talk:Discourse

"One place"

"One place" reminds me of <https://xkcd.com/927/>. MZMcBride (talk) 03:32, 18 November 2017 (UTC)

It does seem like it might be possible to start with clarifying and improving how existing systems are being used. I started a topic on this thread asking "How about Discussion on Discussion tabs?"

A forum (to me) is a step back from a well edited wiki page. It would be great if forum discussion outcomes could be fed back into MediaWiki documentation so that instead of searching a forum and filtering out the content that matters users, sysadmins, and developers can find information in the docs as they read them. GoodMagician (talk) 20:46, 19 November 2017 (UTC)

I'm on board

I'm definetly on board with this. I previously had some concerns about its QA suitability, but since I saw the Opensource design page, I think it definitely can work.

Would be nice, to have a MW extension, that can like show the lats 10 posts or something inside mediawiki.org, to make it easier to jump from one to the other.

Let's go ! —TheDJ (Not WMF) (talk • contribs) 11:55, 19 November 2017 (UTC)

An extension sounds great. I wonder if an extension to consume an RSS feed would suffice? Discourse produces feeds for categories etc. Although perhaps it'd be good to be able to view the status of individual topics too, along the lines of the BugStatusUpdate gadget; a Discourse gadget shouldn't be hard to make. Sam Wilson 23:45, 19 November 2017 (UTC)

Discourse generates RSS feeds from almost every list, and MediaWiki.org already has Extension:RSS enabled.

This is a very good idea. I can already see a MediaWiki.org homepage with some fresh updates. Qgil-WMF (talk) 17:07, 20 November 2017 (UTC)

How about Discussion on Discussion tabs?

How come Discussion tabs/pages wouldn't be used to discuss the Mediawiki technical documentation, which is written in Mediawiki? GoodMagician (talk) 20:03, 19 November 2017 (UTC)

My understanding (about 18 months into operating a Mediawiki site) is that the documentation for the software and project are in the MediaWiki Manual and Wikibooks and we come to wikitech-l “for discussion of technical issues with Wikimedia servers, features and development of the MediaWiki software, etc.” and to ask questions when answers to technical questions can’t be found. I wonder if instead of introducing a new forum tool it might be helpful to invest more time into updating the existing documentation and addressing old open questions on documentation Discussion/Talk pages? GoodMagician (talk) 20:29, 19 November 2017 (UTC)

Side note: I'm not sure if the sidebar changed recently, but today is the first time I visited the "Communication" link under the Support heading. It provides a nice overview of available support channels. I wonder if it might be worth making the purpose of the Communication page more clear, featuring it more prominently on the Main Page, or possibly renaming it to something like "Support Options". GoodMagician (talk) 20:44, 19 November 2017 (UTC)

How do you even find old open questions? That's one of the many ways in which MediaWiki talk pages (with or without StructuredDiscussions) are not adequate as a forum/Q&A/issue tracking system currently. Tgr (WMF) (talk) 21:08, 19 November 2017 (UTC)

I'd expect that people subscribe to both content and discussion pages for topics they help author. Page change notifications might prompt a person to check what's new on the content or discussion page.

Closed questions don't necessarily need to be discoverable, assuming the concern has been addressed on the corresponding content page. GoodMagician (talk) 19:49, 9 January 2018 (UTC)

A large part of questions are not actionables but people trying to figure out how to do something that's too specific or uncommon to put into the documentation. And ownership changes over time and can belong to a group and not an individual, and talk pages do not have a mechanism to handle either of those. Plus there most active support channels are non-topical (e.g. the support desk). Tgr (WMF) (talk) 21:32, 9 January 2018 (UTC)

Talk pages are great for discussion about the contents of the page to which they're attached. They're not so great for asking questions about things that you're not sure about, or that don't have an obvious already-existing place in mediawiki.org. And yes, from the answering-questions side, it's less than ideal having very many pages on your watchlist here and still missing where people are talking about things. Sam Wilson 23:05, 19 November 2017 (UTC)

Although it is a somewhat of an orthogonal issue, I agree that improving docs would probably help our users more than yet another support forum. It is not unusual to come across docs with information that has not been true for many years. Bawolff (talk) 08:22, 22 November 2017 (UTC)

That's a false choice, IMO.

• Running a forum and improving documentation are not competing tasks in any real sense; the first is sysadmin-type work, the second is developer / wikignome work. (Also keeping a piece of software alive is wastly less work than fixing bug 1.)
• Answering questions on a forum and improving documentation are somewhat competing indeed; they are done by the same people for largely the same reason.But
  1. at this point, you are not arguing against having "yet another support forum", you are arguing against having support forums at all. (Or at the very least making them easy to find and use, thus getting many questions, thus being able to spend much time on answers.) Which I don't think is an argument you'd be making in earnest.
  2. It is a lot easier to get people involved in something that looks like talking than into writing documentation (see e.g. the recent flop of StackOverflow Documentation). As unfortunate as that it is, not having a good support forum probably means losing volunteer effort because we don't make participation rewarding.
  3. Ideally, answers to frequent requests should be refactored into documentation; some support forum implementations make that easier than others. Discourse will be much better in that regard than IRC and email threads. Granted, wiki talk pages could even be better, but they suck in too many other ways :/ (Case in point: I just lost half my answer by pressing backspace at the wrong time and triggering some kind of JS error. I am sure Flow will be a great tool eventually, but there is no reason to put off user support until then.)

That said, encouraging interaction patterns that support improving documentation (merging similar questions, making questions and answers editable, reminding users to update the documentation) should be an important goal when designing the support forum. Tgr (WMF) (talk) 20:36, 22 November 2017 (UTC)

I agree that "docs or forums" is a false choice, that's why I described it as an orthogonal concern. And I am not opposed to running a forum (or forums)

But in terms of helping users, I think its important to acknowledge that forums is just one aspect of the beast, and shouldn't be the sole focus Bawolff (talk) 08:21, 27 November 2017 (UTC)

As a comparison, I think it's interesting that the main entry point for WordPress developers is https://make.wordpress.org/ which is neither a place for support nor for documentation: it's a set of blogs about what's going on in each of the various areas of development. For example, clicking through to Plugins gets to recent news about things of interest to plugin developers. Although it's worth noting that the top-level link to these blogs is a peer of links to both documentation and forums.

Also, there's DokuWiki's take on docs-and-forums, in which there's a slightly more similar set-up to us here: they have a wiki for documentation, a bug tracker, a forum, etc. and all are linked on every page. They have a bar at the top of every one of their sites (oh, not all actually: GitHub can't do it) linking to "Download, Wiki, Forum, IRC, Bugs, Translate, Git, XRef". I think that helps orient newcomers pretty well, because the same navigation is reinforced all over the place. Sam Wilson 08:38, 27 November 2017 (UTC)

A big driver for my team to choose MediaWiki is that the interface is relatively simple. I wanted to use GitLab Pages, but non-technical users balked at the learning curve for Markdown and loved the MediaWiki visual editor. While a dedicated support forum might work really well for MediaWiki software community stakeholders, it's worth considering that Discussion pages remain as the key support mechanism for the community stakeholders of all the content projects that MediaWiki is used to operate. Is there a way the efforts / lessons learned by this support forum effort can feed back into the design of Discussion pages? GoodMagician (talk) 19:54, 9 January 2018 (UTC)

I don't think there is a shortage of lessons learned for MediaWiki discussion pages, but the effort needed for installing third party discussion software and for bringing the StructuredDiscussions extension to the same level are wildly different. Tgr (WMF) (talk) 00:03, 10 January 2018 (UTC)

Yes, I think that's the crux of it. It rather feels like the old tension between wanting everything in a single system, and having systems that do one thing well. MediaWiki does "multiple people editing multiple pages" very well; it doesn't do discussion so brilliantly.

In an old job, we once had a wiki set up with no discussion pages, but a top-tab linking to a forum (I think there was some magic involved with creating a thread for each page or something). Not that I'm suggesting that for here, but it was an interesting way to do it. Sam Wilson 01:04, 10 January 2018 (UTC)

Making it possible to associate an external forum post with a page's discussion tab link is an interesting approach. It does seem like some sort of magic would need to help keep page names and forum posts in sync.

I do think the Discourse forum experiment this team is running is a valuable one, wherever the discussion pages roadmap may go.

Thank you both for replying & sorry I let so much time go by between my visits. GoodMagician (talk) 21:18, 10 January 2018 (UTC)

Discourse can also be easily embedded into other applications if one prefers that. Tgr (WMF) (talk) 07:57, 11 January 2018 (UTC)

Some details where Discourse might help:

• We know the questions we get, but we don't know the questions we don't get. By having one place easy to use for asking questions, I bet we will get more questions than the ones we are seeing / finding now spread in the different channels.
• Discourse allows to convert the first post in topics editable by many, wiki style. This might be useful for cases where several people improve the question / answer as the discussion happens.
• Discourse has tags. We could have a tag i.e. "pleasedocument" to identify topics that have been resolved with questions/answers that should be moved to the wiki. This way if the person(s) responding don't do this themselves (happens more often than not), then others (i.e. the own topic creator or other contributors interested in helping with documentation but not experienced developers) could help. This could be a good source of relatively straightforward documentation tasks for newcomers themselves i.e. in the context of Google Code-in. Qgil-WMF (talk) 11:01, 22 November 2017 (UTC)

Pilot plan approved

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). Qgil-WMF (talk) 13:37, 27 December 2017 (UTC)

fwiw, there is a new Discourse plugin on the scene. https://phabricator.wikimedia.org/T124691#3874322

https://github.com/bekicot/discourse-phabricator-connect

It is create by my intern. We could also investigate locking down the profile email field so it cant be modified from the email address that was obtained from Phabricator. We have already investigated adding Discource user profile flags to indicate roles a person has, based on information that can be obtained via Phabricator, such as repo 'committer', project membership, etc. Looks very feasible, but needs a bit of work to implement.

A Phabricator based SSO and profile may prevent some people from joining, but it will also allow many, many more to join with a few clicks. John Vandenberg (talk) 16:50, 4 January 2018 (UTC)

We are discussing the possibility to use this plugin at https://discourse-mediawiki.wmflabs.org/t/enabling-social-login/71. Feel free to join. :) Qgil-WMF (talk) 08:52, 15 January 2018 (UTC)

New Wikimedia Developer Support test pilot announced

https://discourse-mediawiki.wmflabs.org/ has just been announced.

Wikimedia Developer Support offers a support channel for all developers working with MediaWiki or other Wikimedia related technologies: APIs, extensions, skins, gadgets, templates, bots, tools, apps, data sets… If you need help with a technical problem, just ask.

This website is based on Discourse. If you have questions about how to use it, check Discourse/Help.

Your feedback about this website is very important! Bug reports, feature requests and other suggestions are very welcomed.

IMPORTANT

Wikimedia Developer Support is a pilot project running on a test instance. This is not the final deployment.

• Although the migration of users and content to the production server is theoretically possible, at this point it is not guaranteed (T184461).
• The authentication system for this test instance is not what will be used if this project makes it to production.
• If you have a Wikimedia account, use the same email when registering here. This is how your username and content will remain yours if/when Wikimedia single sign-on is implemented (T124691).
• Do not reuse your “real” passwords when creating an account in this test instance. Qgil-WMF (talk) 09:06, 9 January 2018 (UTC)