MediaWiki Stakeholders' Group/TechConf Input/Challenges

Gerrit
The Gerrit system for submitting patches is clunky, hard to work with, and generally unfavored in my office place. I was really hoping that with the moving to Phabricator another repository management system would have been implemented.

Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)

Endorsements

 * Alexia E. Smith (talk) 22:36, 3 August 2018 (UTC)
 * Corey Chambers (talk) 00:11, 11 August 2018 (UTC)
 * James Martindale (talk) 19:04, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:22, 14 August 2018 (UTC)
 * Kaldari (talk) 21:47, 14 August 2018 (UTC)
 * Winged Blades of Godric (talk) 10:28, 15 August 2018 (UTC)
 * HakanIST (talk) 06:28, 18 August 2018 (UTC)
 * DuncanCrane (talk) 12:23, 18 August 2018 (UTC)

Comments

 * I would also prefer a move to GitHub --Krabina (talk) 11:51, 6 August 2018 (UTC)
 * Gerrit is unnecessarily difficult for new users to get used to. Moving to a service such as GitHub would allow new users to more easily contribute to existing projects by taking advantage of things like browser editing. Corey Chambers (talk) 00:11, 11 August 2018 (UTC)
 * I find GitHub's code review interface far easier to work with than Gerrit's. James Martindale (talk) 19:04, 13 August 2018 (UTC)
 * Anything would be better than Gerrit. GitHub is obviously the best option as far as UI and existing community, although politically it's problematic due to its commercial nature. Kaldari (talk) 21:47, 14 August 2018 (UTC)

Access restrictions and wiki synchronization
I know that MediaWiki is not designed to be a full-fledged content management system with fine-graind per-page or partial page access restrictions and probably never will be. But anyway, there two extensions that came quite far:
 * Extension:Lockdown
 * Extension:PermissionACL

So a first wish is one of them / or both to be maintained better or another solution to this.

In corporate settings, there are also alternatives to access restrictions in one wiki, i.e. splitting content in two or more wikis. Therefore a better multi-wiki-management and content syndication between wikis could be a way to go. Here are some links to follow up on that:
 * Extension:SplitPrivateWiki
 * https://github.com/nischayn22/wikiImporter
 * extension:Sync
 * Extension:Push

Also, a very simple use case cannot easily be implemented: setting up 2 wikis with a shared user accounts (but different content). So single-sign-on between two or more mediawiki instances is important in this regard as well (without having to use several extension).

Krabina (talk) 12:01, 6 August 2018 (UTC)

Endorsements

 * Krabina (talk) 12:01, 6 August 2018 (UTC)
 * AdSvS (talk) 12:58, 6 August 2018 (UTC)
 * --&#91;&#91;kgh&#93;&#93; (talk) 11:20, 11 August 2018 (UTC)
 * RichardHeigl (talk) 12:09, 11 August 2018 (UTC)
 * (This challenge is related to my own below) Even Thorbergsen (talk) 20:28, 12 August 2018 (UTC)
 * --MGChecker (talk) 22:16, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:23, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)
 * Remco de Boer 15:23, 14 August 2018 (UTC)
 * --Felipe (talk) 07:31, 15 August 2018 (UTC)
 * Ike Hecht 02:29, 16 August 2018 (UTC)
 * Rob Kam (talk) 08:44, 16 August 2018 (UTC)
 * Tenbergen (talk) 15:40, 17 August 2018 (UTC)
 * Tfellows (talk) 19:05, 17 August 2018 (UTC)
 * HakanIST (talk) 06:29, 18 August 2018 (UTC)
 * DuncanCrane (talk) 12:25, 18 August 2018 (UTC)

Comments

 * This would be useful for hiding rough drafts of articles while they're being worked on, until they're ready enough. Rob Kam (talk) 10:07, 8 August 2018 (UTC)
 * for this you should look into Extension:Approved_Revs --Krabina (talk) 09:23, 10 August 2018 (UTC)


 * Indeed the "Lockdown" extension is more or less causing issues since MW 1.27 due to a bug apparently in core. --&#91;&#91;kgh&#93;&#93; (talk) 11:21, 11 August 2018 (UTC)
 * ACL is a missing core feature that does not contradict the Wiki idea, because you can - and should - deploy flat authorization hierarchies. But the lack of this configuration option complicates often development projects and the introduction of MediaWiki in organizations outside of Wikimedia.RichardHeigl (talk) 11:08, 15 August 2018 (UTC)


 * Maybe allowing restrictions by namespace may be enough. But then if a person needs to move a page from one namespace to a different namespace, there should be an easy way to update all of the references to that page.  Zzmonty (talk) 15:49, 15 August 2018 (UTC)


 * I have one wiki that's split private/public, and another that looks to be heading that way. It would be great if there was a very straightfwd way to designate a page public or private. Mind you, we also use SMW, and I can see where integrating properties and queries into this sort of thing would be hard. Tenbergen (talk) 15:38, 17 August 2018 (UTC)

Documentation needs a lot of improvement
I don't think I'm saying anything controversial here, but the documentation on mediawiki.org is often incomplete, outdated and sometimes misleading. I'll give one recent example: I was looking for how to view the current status of the job queue, other than just going into the database and looking at the "job" table. I went to the page Manual:Job queue, and the information there about viewing the job queue is in the section called "Special:Statistics" - which is odd because, as the text there notes, job queue information hasn't been available at Special:Statistics since 2010. The section then describes the API action to get the current number of jobs - which is helpful. However, there's also a script to see more information on the job queue, showJobs.php, and that one is only listed in the "See also" section. (And isn't there a way to call it from the web interface? I thought there was, but I don't see it now.)

Looking at the "Manual:Job queue" page, it looks like a lot of it could be overhauled. Why is a description of the asynchronous jobs setting contained in the "History" section? Why is there a "History" section at all? The average user has no interest in hearing about, for instance, job-related bugs that were fixed in 2014. This seems like it would be better kept in a subpage.

I think it would be great to have people whose full-time or part-time job is to maintain the documentation, and make sure that there's a consistent structure to it.

Yaron Koren (talk) 18:32, 6 August 2018 (UTC)

Endorsements

 * Yaron Koren (talk) 18:32, 6 August 2018 (UTC)
 * Bryandamon (talk) 18:14, 8 August 2018 (UTC)
 * Corey Chambers (talk) 00:12, 11 August 2018 (UTC)
 * --&#91;&#91;kgh&#93;&#93; (talk) 11:23, 11 August 2018 (UTC)
 * --MGChecker (talk) 22:16, 13 August 2018 (UTC)
 * — AfroThundr (u · t · c) 00:30, 14 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)
 * Alangi Derick (talk) 13:03, 14 August 2018 (UTC)
 * Remco de Boer 15:24, 14 August 2018 (UTC)
 * Kaldari (talk) 21:48, 14 August 2018 (UTC)
 * --Felipe (talk) 07:33, 15 August 2018 (UTC)
 * Winged Blades of Godric (talk) 10:28, 15 August 2018 (UTC)
 * Ike Hecht 02:26, 16 August 2018 (UTC)
 * Tenbergen (talk) 15:41, 17 August 2018 (UTC)
 * Tfellows (talk) 19:05, 17 August 2018 (UTC)
 * nBarto (talk) 22:48, 17 August 2018 (UTC)
 * HakanIST (talk) 06:29, 18 August 2018 (UTC)
 * DuncanCrane (talk) 12:27, 18 August 2018 (UTC)

Comments
This is a very key area in MediaWiki development and I must appreciate that of course there is a lot of documentation already which exist but since software changes are inevitable, it should be noted that as these changes are done periodically, their docs counterparts should be improved in order to keep everything up to date. It's a key way of technical contribution in the movement and while trying to do this, one will find his/herself navigating MW code and software etc. There are many advantages of improving MW related documentation especially to developers and newbies so it should be treated with priority. :) --Alangi Derick (talk) 13:07, 14 August 2018 (UTC)

For developers in particular, the documentation is often (usually?) missing or wrong. Sometimes developers follow the documentation and submit patches only to be corrected on code review. I wonder if there is more accurate and thorough documentation in Gerrit than in mediawiki.org. For each section of the MediaWiki code (or certain complex extensions, there seems to be a small group of developers who actually understand it. If somebody knows who these people are and has access to them, they may be able to encourage a representative of each of those groups to share their knowledge. That would make developing easier and code review more painless. --Ike Hecht 02:26, 16 August 2018 (UTC)

Keeping up with the upgrade debug cycle.
Every new release requires re-installation of extensions and checking that everything still works as expected. Most third party wikis stay at the original install version. Wiki users want to add content and keeping up with the upgrade debug cycle too technical a chore.

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

Endorsements

 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)
 * Alangi Derick (talk) 13:07, 14 August 2018 (UTC)
 * Rob Kam (talk) 17:18, 15 August 2018 (UTC)
 * Clump (talk) 15:55, 16 August 2018 (UTC)
 * Tenbergen (talk) 15:45, 17 August 2018 (UTC)
 * Tfellows (talk) 19:05, 17 August 2018 (UTC)
 * DuncanCrane (talk) 12:28, 18 August 2018 (UTC)

Comments
Perhaps users don't even realise they're expected to keep their installations up to date. --Rob Kam (talk) 11:41, 15 August 2018 (UTC)

As mentioned elsewhere, if these updates were further automated or at least facilitated that would be great! Making them like Wordpress where I don't even need to touch might be too much to ask, but turning them into something where I would at least be comfortable to hand it over to a less familiar technical resource would be great. I think if I left my work environment today our wikis' software might never be updated again. Tenbergen (talk) 15:45, 17 August 2018 (UTC)

Most people are not drawn to use wikis
Wikis needs collaboration to function well. The biggest challenge is lack of other wiki contributors with know-how to share. Most frequently when people announce (on email lists or forums) some information they’re organising and making available; even if they know of a wiki for that subject they do it their own way, e.g. posting on a forum, blogging, YouTube, file-sharing, Google docs, GitHub repository, etc. but rarely a new wiki article on an existing specialist wiki. While on the other hand some competent authors are repelled by the idea of writing on a topic and then having to allow anyone to make changes to their work.

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

Endorsements

 * Liuxinyu970226 (talk) 01:35, 14 August 2018 (UTC)
 * Rob Kam (talk) 17:19, 15 August 2018 (UTC)

Comments

 * I tried to contribute to Wikipedia, but I received threats, so I gave up. Now I am just a reader of Wikipedia, make an occasional small edit, but mostly working on my own personal wiki project.. — Preceding unsigned comment added by Zzmonty (talk) 15:53, 15 August 2018 (UTC)
 * Putting work into articles only to have them deleted because "not notable enough" also puts people off contributing to Wikipedia. Rob Kam (talk) 10:42, 16 August 2018 (UTC)

Guarding against link rot
The MW extension ExternalLinks is unsafe because of the risk of XSS. It was an easy and efficient way to easily maintain a wiki's external links. Wikis could/should have Special:External links where any broken external links get flagged up.

Rob Kam (talk) 09:47, 8 August 2018 (UTC)

Endorsements

 * Liuxinyu970226 (talk) 01:36, 14 August 2018 (UTC)
 * Rob Kam (talk) 17:20, 15 August 2018 (UTC)
 * Tenbergen (talk) 15:50, 17 August 2018 (UTC)

Comments

 * Would be nice if internal links to headings were included in such a feature. For a link like Page, if the heading is changed in the page, there is no way to list pages affected by that (that I know of). Tenbergen (talk) 15:50, 17 August 2018 (UTC)

Enabling public read access to specific pages of a private wiki
It should be easy to make specific pages of a private wiki publically available, while all other pages stay private. Setting a category display property is a possibility. This is related to Access restrictions and wiki synchronization above, and may possibly be solved by Extension:SplitPrivateWiki.

Even Thorbergsen (talk) 14:44, 12 August 2018 (UTC)

Endorsements

 * Even Thorbergsen (talk) 14:44, 12 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)
 * Tenbergen (talk) 15:55, 17 August 2018 (UTC)

Comments
In a private wiki not behind a firewall, you can add pages you want the public to see with $wgWhitelistRead on LocalSettings.php. To easily do this, you can load the InternalWhitelist extension which provides a Wiki page (MediaWiki:Whitelist) to which you can add all pages you want publicly available. Making the MediaWiki:Whitelist page protected can limit who can make pages public. Bryandamon (talk) 06:01, 14 August 2018 (UTC)
 * If whitelisting was made much easier, this would solve my public/private wiki issues as well. Putting it into LocalSettings means I can not ask a content writer to do it, it has to be a technical employee. Is there a technical reason the whitelist can't live in a namespace or special page, or riskier but more convenient, in a switch that comes up at page save time, near the "minor" and summary components? Tenbergen (talk) 15:55, 17 August 2018 (UTC)

Replicating templates and modules from Wikipedia to an Enterprise wiki
Could it be made easier to be able to copy over a template, its documentation, any of required templates, their documentation, those templates required template, their documentation, any requirement modules, and their documentation? I feel this could be done using Special:Export if you would specify the list of all of the templates and modules, but getting that list might be very time consuming and prone to errors. Thanks!

PhotographerTom (talk) 17:55, 13 August 2018 (UTC)

Endorsements

 * PhotographerTom (talk) 17:55, 13 August 2018 (UTC)
 * Liuxinyu970226 (talk) 01:37, 14 August 2018 (UTC)
 * Bryandamon (talk) 06:03, 14 August 2018 (UTC)
 *  ·addshore·  talk to me! 09:49, 14 August 2018 (UTC)
 * DuncanCrane (talk) 12:33, 18 August 2018 (UTC)

Work with documents within the wiki and export pages to PDF
Many organizations come from (MSOffice)-document centric environments. Even if they gradually migrate their content to web formats, some enterprize prozesses will keep beeing heterogenoulsly document based for years. Reasons are manifold and include complinace issues, local policies, system integration, personal content review preferences, need for physical printouts at work sites and a low digital literacy of staff in mission critical positions, slowing down transition.

Mediawiki should make its embedding in heterogenous environments easy and relaxed. These workflows would include intuitive upload interface and document previews (.xlsx, .docx, .pptx) within pages and full text search indexing.

When wikis are used for technical documentation, the creation of PDF-exportable "books/article collections" also is desirable. Optimally these would embrace mixed wikitext/document collections. -- 11-G3n (talk)

Endorsements

 * Planetenxin (talk) 07:36, 17 August 2018 (UTC)
 * Bryandamon (talk) 08:35, 17 August 2018 (UTC)
 * DuncanCrane (talk) 12:35, 18 August 2018 (UTC)
 * Liuxinyu970226 (talk) 15:10, 18 August 2018 (UTC)

Comments

 * Save article selections to different formats in the order the user selected needs to work. This would allow more use of a wiki as a workspace for later publication.  This should include save as PDF, epub 3.0, HTML, doc, and otd formats.

Wikimedia doesn't really support shared hosting.
Wikimedia doesn't really support economical shared hosting. Not everyone can afford to run a wiki on the infrastructure it seems to be written for. Trying to get e.g. Visual Editor running on shared hosting is so severe a challenge that regular wiki maintainers won't even attempt it.

Rob Kam (talk) 17:18, 15 August 2018 (UTC)

Endorsements

 * Rob Kam (talk) 17:18, 15 August 2018 (UTC)
 * Tenbergen (talk) 16:02, 17 August 2018 (UTC)
 * DuncanCrane (talk) 12:37, 18 August 2018 (UTC)
 * Liuxinyu970226 (talk) 15:10, 18 August 2018 (UTC)

Comments

 * We are also still using the old-school wiki editor because the new one is not shared hosting friendly; I haven't even looked at the visual one in months because the need to install other stuff that may or may not run on shared hosting has completely put me off. In a related way, some of the changes that were rolled out with the latest update this summer (recent changes improvements) are really neat, but they appear to have seriously slowed down parts or our wiki so I have not applied them to all our wikis yet (granted this may be an issue with our specific wiki instance, but that's how it came across to me). While the visual editor is at least a choice, some of the other changes are not, and that becomes a problem. If a new version of mediawiki needs more resources to run than the old one, that should be transparent, and ideally be in line with what shared hosting can handle. Tenbergen (talk) 16:02, 17 August 2018 (UTC)
 * Visual editor is definitely a huge step forward to encourage non-IT literate authors to add content to a mediawiki based site. I have to agree, though, with the author of this comment. Setting VE up in my environment defeated me, so much so we are are now using an extension that uses TinyMCE which works great for our purposes.  In order for mediawiki to thrive in the future we not only need to encourage content authors by making it simple and intuitive, we also need to make it easier for new (novice) technical authors so they don't bypass mediawiki for apparently more accessible alternatives. DuncanCrane (talk) 12:47, 18 August 2018 (UTC)
 * Another challenge with hosted environments is that a lot of the configuration is only available by editing the LocalSettings file. It would be great if it was possible to change more settings through the mediawiki interface, in addition to user based preferences, perhaps as a special page?  DuncanCrane (talk) 13:14, 18 August 2018 (UTC)

Considering spam and vandalism in feature design
Spam/vandalism management is harder than it needs to be due to the design of some major features, and it would be helpful if the need to address spam and vandalism was considered a critical, first-class consideration in future feature development. Tools such as the translation extension and flow, for example, obscure edits and histories and complicate the process of tracking and restoring revisions:

Translations Talk pages/flow
 * no history, let alone ability to revert is shown in the translation tool.
 * deleting translation spam/vandalism is awkward; specific translation units are not shown in a translated page's history.
 * no obvious way for users to indicate spam translations
 * reverting translation units does not fully restore the state---a removed fuzzy indicator is never restored
 * edits to individual topics are mixed together, making identification of topic vandalism difficult
 * flow page descriptions do not have history, and multiple edits cannot be mass reverted, nor is reverting to older versions easy
 * flow page descriptions cannot be protected (and no progress on has been made in 3 years)
 * topic titles, summaries, and visibility are trivially altered by vandals, and cannot be protected

These tools can be fixed (eventually, presumably) and/or replaced. More generally, though, easy tracking and tracing of revisions, access to histories and older revisions, and protection capabilities should be integral in the design of all features that allow user editing.

Clump (talk) 16:56, 16 August 2018 (UTC)

Endorsements

 * Clump (talk) 16:56, 16 August 2018 (UTC)
 * Rob Kam (talk) 18:47, 16 August 2018 (UTC)
 * Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)

Comments

 * Even when spam can be minimized with extension abuse filter the bots still fill the user list with noise. Rob Kam (talk) 18:47, 16 August 2018 (UTC)

stronger warnings when trying to edit old version
Our documentation process makes heavy use of the recent changes feature. Due to the breakdown by day, there is no easy way to only list a page's most recent edit, it will be listed for each day it was edited. This means that if I am away for a week, and then start reviewing changes from 7 days ago, I will likely look at a few diffs that have had additional changes since. It is easy to start editing the version that is not the current one, which is not usually what is intended. I make the mistake even though I am aware of it, and it is almost impossible to explain to less technical users that this is something to watch out for. This leads to later edits being clobbered, which is reducing buy-in in using the wiki. It would be nice if trying to edit a non-current version led to a far more "noisy" warning than that little line at the top. This might be something that I can change through interface edits, but I think the default should be more noisy in the first place. Tenbergen (talk) 16:24, 17 August 2018 (UTC)

Endorsements

 * Tenbergen (talk) 16:24, 17 August 2018 (UTC)
 * nBarto (talk) 09:01, 18 August 2018 (UTC)
 * Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)

Upgrading Scribunto

 * Upgrading Scribunto on a shared host. Extensions that are needed to easily copy and paste existing templates should be considered critical extensions. Zzmonty (talk) 16:00, 15 August 2018 (UTC)

Endorsements

 * Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)

Communication between pages
There is currently no satisfactory way to, when parsing a page, read data from a different page.

The PageVariable extension is experimental and appears to be no longer maintained. It is possible to achieve this with Labeled Section Transclusion, but the code will be inelegant, as it is not possible to embed &lt;section&gt; tags in a template. See T39256 and T179482.

nBarto (talk) 23:17, 17 August 2018 (UTC)

Endorsements

 * nBarto (talk) 23:17, 17 August 2018 (UTC)
 * Liuxinyu970226 (talk) 15:11, 18 August 2018 (UTC)

Comments

 * One situation where I was hoping for this functionality, is in creating more flexible page hierarchies: Organizing a set of pages using (multi-level) subpages is not very flexible: when a parent page needs to be moved, all subpages have to be moved as well. Also, it is not possible to assign multiple parent pages to one child page. By contrast, with an appropriate implementation of page variables, one could simply assign to each page a variable indicating one or more parent pages. The "breadcrumbs" containing the grandparents, great grandparents, ... can then be created by recursively reading the parent page's variable. --nBarto (talk) 23:28, 17 August 2018 (UTC)