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)
 * HakanIST (talk) 06:29, 18 August 2018 (UTC)
 * DuncanCrane (talk) 11:17, 18 August 2018 (UTC)
 * --Toniher (talk) 10:48, 18 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)
 * DuncanCrane (talk) 11:17, 18 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)

I'm using a wiki farm to provide a 'software as a service' environment to my users. Ideally they should have identical functionality with their content stored in unique wiki databases for each user (or group of users). The functionality I create uses templates a lot - Page Forms, Cargo, SemanticMediaWiki - so it would be great to be able to share templates in a straightforward way. Currently I am duplicating the functionality in each wiki which makes it difficult to maintain. Perhaps it would be possible to set a configuration variable to always transclude templates from a particular wiki? Alternatively, it would be useful if, when transcluding a template from another wiki, all templates referenced were also transcluded from the same wiki. If this is already possible it would great to know how? The suggestions I've seen so far appear quite complex to implement. DuncanCrane (talk) 11:18, 18 August 2018 (UTC)
 * You'd also have to transclude any modules the templates use. Rob Kam (talk) 16:18, 18 August 2018 (UTC)

Somehow this topic was split into several variations of the same topic. I guess I endorsed one of them. --&#91;&#91;kgh&#93;&#93; (talk) 08:52, 19 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)
 * DuncanCrane (talk) 11:19, 18 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)
 * Liuxinyu970226 (talk) 15:10, 18 August 2018 (UTC)

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

Replace this line with your response.

197.156.115.144 17:52, 18 August 2018 (UTC)

Endorsements

 * 197.156.115.144 17:52, 18 August 2018 (UTC)

Comments
I use Wordpress a lot and have noticed MediaWiki is lacking somewhat when it comes to management for non-technical people compared with Wordpress, even Joomla! can do it. I have experienced the following issues:


 * unable to install Visual Editor with dependency of Parsoid,
 * initially had issues installing Semantic MediaWiki due to dependency of Composer, I did find a workaround, but not ideal,
 * when updating it is very frustrating having to delete all the files from the server and reloading the latest version of MediaWiki, can this not be done similar to how Wordpress ad Jooma do it?

The fact that you need access to the command line to run maintenance scripts and other functions like composer, those on shared hosting environments won't be able to do this. I am using a virtual machine with access to the command line, but I have other hosting where this is not possible. Other opensource scripts such as Wordpress and Joomla allow easier installation of extensions, is it possible that MediaWiki could follow these examples?

The server I am working on is not Internet facing, so a lot of the time I am having to take the server off line, transfer the MediaWiki installation to a local server I have built on an Internet facing machine, do what I need to do, then migrate it back over. This entire process can take two days, that's two days where my contributors are unable to contribute.

--Squeak24 (talk) 12:00, 19 August 2018 (UTC)

Endorsements

 * Squeak24 (talk) 12:11, 19 August 2018 (UTC)
 * Rob Kam (talk) 12:34, 19 August 2018 (UTC)

Comments
I have tried to install Visual Editor a few times now, I was able to get it working without issue on my Internet facing machine, but when I tried to get it working on the server that is not Internet facing I was not able to get it working. I tried to migrate the internet facing version on my development server to my production, non-internet facing server, but for some reason it wouldn't work. It worked fine on the new pages, but not the legacy pages that require Parsoid. I tried in vain to get Parsoid working correctly on the non-internet server. Is there anyway it may be easier to use Visual Editor without Parsoid?

I did try the TinyMCE extension, this worked fine even with the old pages. Unfortunately it is still very buggy hence I was unable to have it on a production site. I want to make it as easy as possible for the contributors, I need them to edit the pages they manage, hence such a tool would be fantastic to have.

-Squeak24 (talk) 12:00, 19 August 2018 (UTC)

Endorsements
-Squeak24 (talk) 12:11, 19 August 2018 (UTC)