MediaWiki Stakeholders' Group/TechConf Input/Conference topics

How can we create a governance model?
There is no clear decision making process for MediaWiki. I would love to see us start on a process whereby we could predict what was happening with the software in the next year. We have some vague ideas, but no unified driving force.

☠ MarkAHershberger ☢ (talk) ☣ 19:45, 3 August 2018 (UTC)

Endorsements

 * ☠ MarkAHershberger ☢ (talk) ☣ 19:45, 3 August 2018 (UTC)
 * Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)
 * --Krabina (talk) 11:47, 6 August 2018 (UTC)
 * --&#91;&#91;kgh&#93;&#93; (talk) 11:06, 11 August 2018 (UTC)
 * RichardHeigl (talk) 11:56, 11 August 2018 (UTC)
 * 「 ディノ 奴 千？！」? · ☎ Dinoguy1000 00:49, 14 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:19, 14 August 2018 (UTC)
 * Nischayn22 (talk) 08:31, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:50, 14 August 2018 (UTC)
 * Remco de Boer 15:22, 14 August 2018 (UTC)
 * Jayprakash12345 (talk) 08:11, 17 August 2018 (UTC)
 * MarcvHoof (talk) 14:04, 17 August 2018 (UTC)
 * Mglaser (talk) 21:15, 17 August 2018 (UTC)

Comments

 * As Facebook, Google, Youtube, and Twitter have demonstrated, the concept of a "private" company remaining neutral does not exist. It was good Utopian vision, but it is a false vision that cannot withstand the test of time.  The only solution is to accept that fact and form a representative body.  For issues relating to US Democrat party issues have somebody on the committee that handles those issues.  For US Republican party issues have somebody on the committee that represents those issues.  When issues will have opposing issues, for example abortion, allow one article to be created that is from the perspective of the Democratic view (liberal view) and allow one article to be created from the Republican view (conservative view), but require that those articles clearly state at the top (in a standardized format) that they were written under the guidance of those biased views.  Editorial articles are not a bad thing as long as the reader is aware that what they are reading is an editorial or biased or slated.  There should still be the original neutral view article.  This is the only way to ensure that freedom of speech is upheld and prevents either side from silencing the other as Facebook, Twitter, YouTube, and Google are trying to do.  If a person decides to read the article about abortion, they can make the choice if they want to the article from a neutral perspective, from the anti-abortion perspective, or the pro-abortion perspective.  Wikipedia is giving the information, and the end reader is deciding for themselves what they want to do with that information.  What I tell my children about research with wikipedia is that the most valuable parts of Wikipedia are the facts section (infoboxes) and the reference section (links to other sources).

The extension "NamespaceRelations" can be used to indicate that the article has related articles written from different perspectives. Main Tab: Abortion Tab 2: Anti-Abortion (pro-life) Tab 3: Pro-Abortion (pro-choice)

Maybe this is not the right extension, just something to indicate that there is a direct relationship between the articles based on different perspectives. Then everything is in front of the reader, and the end reader makes the final choice of what they want to read or not want to read.

Zzmonty (talk) 10:30, 14 August 2018 (UTC)

A text suggestion tool
It's helpful to have a text-editing tool that helps contributors write better sentences

Endorsements

 * Although I don't know who said this section, I support this. --Liuxinyu970226 (talk) 01:20, 14 August 2018 (UTC)

Comments

 * Activate Grammarly. Grammarly is the best grammar editing tool out there.  Zzmonty (talk) 10:34, 14 August 2018 (UTC)

Lack of templates in MediaWiki
Templates are missing from Wikimedia. These are a headache to disentangle, understand, install and maintain for the end user who would rather be concentrating effort on adding wiki content. Individual wiki admins are forced to either write their own templates or export them from elsewhere e.g. Wikipedia.org. This is a wasteful dispersion of effort in place of collaboration. The templates that are exported from Wikipedia or Mediawiki are not universal and the target wiki then includes references to these sites instead of to itself.

Rob Kam (talk) 08:21, 8 August 2018 (UTC)

Endorsements

 * 「 ディノ 奴 千？！」? · ☎ Dinoguy1000 00:49, 14 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)
 * nBarto (talk) 15:31, 15 August 2018 (UTC)
 * Rob Kam (talk) 17:22, 15 August 2018 (UTC)
 * Awangba Mangang --Awangba Mangang (talk) 04:37, 16 August 2018 (UTC)
 * • speedy • 🔔&#xFE0E; • 🚀&#xFE0E; • 13:24, 16 August 2018 (UTC)

Comments
This could be provided by a wiki repository, similar to Wikia/Fandom's Starter Wiki. This repository would have to be licensed as CC0, and there are open questions about maintaining multiple versions of templates, mostly in regard to whether the target wiki has installed features such as Scribunto or TemplateStyles. Since not all templates are of interest to all wikis, some sort of template pack feature, above and beyond just listing things on Special:Export, would be desirable (if designed/implemented correctly, this would also simplify and streamline selecting the correct version of templates for a given installation). 「 ディノ 奴 千？！」? · ☎ Dinoguy1000 00:49, 14 August 2018 (UTC)


 * or just add it to http://commons.wikimedia.org -- make a new section called "Template-repository:" and "Module-repository:". Although the templates would need to be organized between general use templates and templates with information specific to a specific project.  I like the infoboxes, but I do not need many of the other templates that get included when I say "export referenced templates".  Also, the export would need a feature to rename "Template-repository:" to "template:", so the end user does not need to do that themselves. Zzmonty (talk) 10:38, 14 August 2018 (UTC)

To expand on the OP, a lot of Wikipedia/Mediawiki templates are dependent on Scribunto (which users struggle to debug after importing). The Module namespace at Wikipedia has quite a bit of overengineered code as well. Think mobile too - all extension infoboxes on mediawiki.org look awful there. • speedy • 🔔&#xFE0E; • 🚀&#xFE0E; • 13:24, 16 August 2018 (UTC)

Release management unclear. Is there still one?
It appears that doing point releases when it comes to maintenance was apparently abandoned along the way. During the past nine months we have only seen two feature releases with unreleased fixes now piling up for both of them not to speak about the other older LTS branch and the regular branch still active sharing the same fate.

I suggest to reinstate doing point releases for maintenance purposes and to e.g. have a point release every quarter of a year - something somewhat predictable and plannable.

Endorsements

 * &#91;&#91;kgh&#93;&#93; (talk) 11:16, 11 August 2018 (UTC)
 * — AfroThundr (u · t · c) 00:26, 14 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:21, 14 August 2018 (UTC)
 * --Felipe (talk) 07:36, 15 August 2018 (UTC)
 * MarcvHoof (talk) 14:05, 17 August 2018 (UTC)

Comments

 * Figure out why scribunto has issues when trying to install from a 1.27 release to a 1.31 release on a shared host. Maybe I did something wrong, but if I can't get scribunto to work (requirement for using current templates and modules), I can't upgrade to 1.31.


 * Maybe the solution is to create two install versions. One is basic install with the bare bone minimums, and one is an enhanced version (the end user is planning to import templates, so they need all of the extensions that make the templates work properly).  If that was provided, I would upgrade from 1.27 LTS to the 1.31 LTS.  I am sure that I am not the only end user in this position.


 * Finally, have an auto LTS upgrade that will automatically upgrade the source code and extensions, similar to the way that WordPress does it. Maybe this can be restricted to just the extensions that are included in Wikipedia (and its sister project installs).


 * The easier the upgrade process (end user does not worry they are going to mess up their site and be down), the more likely the end user will upgrade and the less need their will be to maintain old releases. Thbis does not need to be done for every release. Just the long term releases, because those are the releases that less technical users should be sticking to.  Zzmonty (talk) 10:45, 14 August 2018 (UTC)

Improved Translate - VisualEditor integration
Extension:Translate is a great tool but it does not work very well with Extension:VisualEditor. VE can not handle the tags. As a result, the user can not edit text in WYSIWYG but in a little dialog box with wikitext...



This has also been reported by others more than two years ago. See:


 * https://phabricator.wikimedia.org/T131516
 * Lots of pages on mediawiki.org have " " and "" bits strewn about, making them hard to read and edit in source, and hard to edit in Visual Editor. Translation should not rely on making large parts of pages uneditable! Per discussion it looks like some small tweaks to VE's treatment of the extension tag may simplify things without introducing too much breakage, until a more VE-native solution is available.


 * https://phabricator.wikimedia.org/T55974:
 * … and the related … are currently un-parsed and shown as plain wikitext in VisualEditor because they're not recognised, per T50891; however, once that is fixed, the blocks won't be editable except as alien nodes (in wikitext), and won't be createable. Making a proper VisualEditor plugin to translate these in-page as a rich editor shouldn't be particularly hard (he says…).

Planetenxin (talk) 15:12, 16 August 2018 (UTC)

Endorsements

 * Planetenxin (talk) 15:12, 16 August 2018 (UTC)
 * Bryandamon (talk) 16:58, 16 August 2018 (UTC)

Comments
Solving this issue would also have positive effect on enterprise use of MediaWiki.