- For the proposal to use Discourse as a platform for Wikimedia discussion, see meta:Discourse. For the skin, see Skin:Discourse
Discourse is an open source web discussion platform (Wikipedia article; demo at discourse.wmflabs.org). The Technical Collaboration team is planning to experiment with Discourse as a developer support channel.
One place to seek developer support
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 MediaWiki Facebook page receives occasional support questions, which usually go unanswered.
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.
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.
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...
The Technical Collaboration and the Wikimedia Cloud Services teams collaborate in the maintenance of the content and the infrastructure of this developer support channel. (Jokes apart, this hasn't been discussed yet although there have been suggestions from both teams)
- Technical Collaboration takes 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.
- FIXME NEEDS DISCUSSION Wikimedia Cloud Services takes care of the site infrastructure and technical decisions. They also take care 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.
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. StackExchange is not open source, and we don't see the benefit of handling our developer support in a commercial 3rd party site.
- 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!!!! ;)
Following topics and handling notifications
Discourse has a collection of features to help users follow the content that is interesting to them. Web and email notifications adapt to regular actions of the users (reading, replying, being mentioned, watching, muting...). For those willing to fine tune their setup to the extreme, Discourse offers many possibilities. Do you want to be notified only when someone mentions you? Do you want to receive an email for every action happening everywhere? Something in between? Discourse can do.
Five levels for tracking content
Discourse offers five levels for tracking topics, tags, and categories. Reading a topic entirely or during a certain time will set it to a higher level, and of course replying in a topic too. Users can refine these actions in their Notification preferences. These levels can be set manually through an icon at the right of topic, tag and category pages. The default options depend on the configuration of the site, and they can be changed via user preferences. From less to more:
- Muted: The user will not be notified about changes, and the topic(s) will not appear in their "Latest".
- Normal: The user will be notified when someone mentions them or replies to their post/comment.
- Watching first post (in tags and categories): Normal + the user will be notified about new topics created.
- Tracking: Normal + in tags and categories the user will track all topics + a count of new replies will be shown in lists.
- Watching: Tracking + the user will receive a notification for every comment.
Email and web notifications
Users will get email or web notifications depending on the defaults of the system and their user preferences. In addition to the notifications for new topics and replies mentioned above, they can receive other notifications, configurable:
- Notifications when someone likes their posts or comments.
- A periodical digest featuring the most relevant topics or activity, which will be sent only when the user is not active in the site.
- A "mailing list mode" can be set in user preferences, which will generate emails for every action respecting muted topics, tags, and categories.
To be discussed at least with Wikimedia Cloud Services and Operations. Big changes might and probably will occur.
- T180854 Start with a protoype in mediawiki-discourse.wmflabs.org as a way to experiment with the structure, maintenance, workflows... See whether current and new Wikimedia developers like it and see a future for it.
- T180853 Once there is consensus and inertia, move to production at discourse.mediawiki.org
Based on the Phabricator experience, there are some aspects that need to be thought out beforehand:
- Wikimedia single user login. Do we start without it in Labs? If so, how can we migrate users once SUL is available?
- HTTPS, is that a problem?
- Media files, are they a problem?
- Private message functionality, is it a problem? FWIW administrators can access to all private spaces and messages via UI in addition to checking the database if they have access.