Discourse

From mediawiki.org
(Redirected from Wikimedia Developer Support)
For the usage of Discourse as a platform for Wikimedia discussion, see meta:Discourse; for the skin, see Skin:Discourse ; for the extension, see Extension:Discourse .

Discourse is an open source web discussion platform.

There were two unstable Discourse prototype instances at Wikimedia:

If you have questions about the use of Discourse, check the Help page. See w:Discourse (software) for more information about the software itself.

The rest of this page documents reasons why Discourse was considered to be used more in the technical Wikimedia movement.

One place to seek developer support[edit]

Currently developers (and specially newcomers) have a hard time finding the right place to ask questions.

Project:Support desk is the only channel whose main purpose is to offer support. In principle, developers, sysadmins and users can ask questions about any topic. There are no categories or tags to organize the questions, and searching for previous questions is very hard. The software offers little help for avoiding duplicates or guiding help seekers to ask productive and informative questions. The Support desk is maintained by volunteers. We invite them to review this plan and to participate in the pilot. The Support desk maintainers will decide the future of that space if the Discourse pilot is successful.

Then we have dozens of channels of different types where requests for support are welcomed, even if support is not the main purpose of those channels:

  • In addition to the Support desk, there are many Talk pages that can receive questions potentially (i.e. Talk:OOjs UI). Find the right page to ask (or even understanding that it is OK to use Talk pages for this purpose) is not simple for many newcomers. It is basically impossible to "watch all the relevant pages" to assure that questions are addressed.
  • wikitech-l and mailing lists in general host discussions mainly targeted to established developers, and they might be daunting for newcomers. Search the archive of one list is complex, and searching all the archives even more. Even finding the right list to ask might be tricky. Most lists are plaintext-only, making extended discussion with log snippets, stack traces etc. a poor experience.
  • #wikimedia-dev and IRC channels in general rely on the luck of asking in the right channel at the right time, which can be problematic especially when adding timezones to the mix. Many newcomers don't know IRC or haven't use it to the extent of being aware of conventions like idling for hours until an answer comes. Answers on IRC are basically impossible to search and it is very difficult to recycle them when someone asks the same question again. Effective communication (such as posting a multiline snippet) requires external tools which many newcomers are not familiar with. IRC nicks are usually disconnected from wiki identities, making it hard to figure out whom to ask.
  • The StackExchange network of Q&A sites has a MediaWiki tag that is used mainly for sysadmin and user questions. However, that is a 3rd party commercial service disconnected from Wikimedia (except for Wikimedia volunteers who are willing to help there). StackExchange sites are scoped by audience (developer / sysadmin / power user / website admin / ...), not software, which often makes finding the right place to ask questions hard. The reputation-based community moderation mechanisms do not work very well for low-interest topics like MediaWiki. Active outreach to invite help seekers into the Wikimedia tech community would probably be against SE terms of use.
  • The MediaWiki Facebook page receives occasional support questions, which usually go unanswered. [A possible solution is to close the page.]

Meanwhile, the experienced developers willing to help suffer the same problem. If a question lands at the right moment in the right place, good. Otherwise it is lost. Community collaboration based on project knowledge or expertise area is basically none because of this fragmentation.

Scope[edit]

Anything that a developer needs to know in order to produce software for the Wikimedia movement. This goes from MediaWiki core and extensions to apps, tools, bots, gadgets, templates... Non-Wikimedia projects using our projects or APIs should be able to have their space as long as they come with maintainers.

Even if the initial target are developers, if the initiative is successful we could consider to bring in sysadmins and users, here too as long as they come with maintainers.

Languages[edit]

English is planned to be the primary language of this space, just like it is the primary language of Wikimedia technical spaces in general.

Discourse offers users the possibility to configure the interface to their preferred locale among a list of supported languages. However, Discourse is probably not good as a really multilingual site. Users can post in the languages they prefer, but there is no functionality to identify the language of a post, link translations of a same document, search per language...

Maintenance[edit]

As of early 2020, the maintenance and future is currently unclear.

In 2017, the idea was that the WMF Technical Collaboration team (which does not exist anymore) and the Wikimedia Cloud Services teams collaborate in the maintenance of the content and the infrastructure of this developer support channel.[citation needed]

  • Technical Collaboration would have taken care of the site content and the developer support. This means that they will cover what needs to be done and nobody else is covering. During the pilot phase, they are in charge of bootstrapping the space, point newcomers to the new space, recruit experienced developers to answer question, and define the processes needed as we go.
  • Wikimedia Cloud Services would have taken care of the site infrastructure and technical decisions, and of supporting the categories / tags related to their area of developer support.

We expect many volunteers to assume moderation / maintenance tasks, especially around specific categories or tags. Volunteers willing to get more involved can achieve any trust level up to administrators, just like in MediaWiki.org. In fact, Discourse is very well designed to promote users through levels of higher trust based on their activity.

Why Discourse[edit]

Discourse is very newcomer friendly, thanks to its ease of use, simple UI, and engagement features. It is also a powerful platform for experienced users, moderators and administrators. Currently MediaWiki doesn't have any alternative at this level. Specialized Q&A alternatives offer additional features like voting questions/answers and nested comments, however we don't believe such features will be critical with the volume of activity expected in our site.

Many software projects are using Discourse for developer support, including Q&A scenarios. The Discourse's community maintained directory features a category for Dev/Software projects. Examples include Docker, GitLab, Mozilla, NextCloud, Phabricator, React, Rust, Ubuntu, and Twitter Developers.

StackExchange is not open source, and we don't see the benefit of handling our developer support in a commercial 3rd party site.

Highlighted features[edit]

  • Welcome bot teaches to newcomers the basic functionality in an interactive way.
  • Users receive achievement badges and are granted new features and higher trust level roles as they acquire experience.
    • This also means that average spammers / vandals can do less damage.
  • Categories and tags + levels of watching and configurable notifications allow user to define with precision the topics they want to be notified about.
  • Similar topics suggested when creating a new one.
  • URLs in posts are turned into embedded previews (e.g. Youtube links are shown as videos) with Onebox.
  • Syntax highlighting for code.
  • Additional topics recommended at the end of threads.
  • Possibility for users to mark topics and comments with "likes" and "flags", collectively promoting or reporting messages.
  • First post can be wikified.
  • Private 1:1 messages with the possibility to add more users.
  • Possibility to create user groups sharing permissions and privacy levels.
  • Possibility to set topics as banners in all pages, with close window and expiration time.
  • Possibility to compose a new pre-filled topic via URL.
  • Official plugin to accept a reply as the answer.
  • Official plugin to post canned replies.
  • Official plugin to assign topics.
  • Official plugin for chatroom integration, plus other third party plugins for native chat.
  • List of official plugins.
  • All this mobile friendly...
  • ... and with emojis!!!!  ;)

Implementation plan[edit]

Responsibilities and future is unclear as of early 2020. This needs discussion with Developer Advocacy, Wikimedia Cloud Services team, and Wikimedia Site Reliability Engineering.

For potential implementation tasks or random feature requests, see the "Open Tasks" under phab:tag/discourse/.

Timeline[edit]

See also[edit]