User:Ryan W/TODO/MediaWiki

v1.35 upgrade

 * Read ALL changelogs including future releases (in case something is already fixed, or declined and we have to either implement our own workarounds or coexist with the issue)
 * Some backend changes have apparently been major and may disrupt our activity somehow. These are background reading and not at all comprehensive:
 * Special:TrackingCategories shouldn't have red links
 * Does Special:LinkSearch include the external links without square brackets around them?
 * Disable special pages that we will never, ever use?
 * Icons in InfoBox boxes are way too small on mobile (and vary inversely in size with box height?)
 * Large changes to mobile parser have been afoot at WMF, so re-testing of this was deferred IIRC
 * In portrait orientation, the ones in Entryway's footer overlap the text


 * Do arrow icons now render for grouped recent changes on mobile? (See locally stored phone screenshot in "2017 upgrade" subfolder.)  If not, assume this is a doomwiki.org issue per an ancient IRC conversation that I cannot find
 * Special:MIMESearch should allow unknown/unknown (for maintenance) per . In fact, per Wikipedia's version, a drop-down should list all existing values.  If these aren't so, then file new bugs
 * Has title blacklist log been reactivated?   If so, you can test again &mdash; some screenshots are in local "mausoleum" folder
 * Does MediaWiki:Linksearch-text now omit the list of protocols? If so, get it back &mdash; that was really helpful
 * Edit buttons gadget can now fall back to MediaWiki:Edittools (Wikipedia's looks fine) for non-JS users.  Does that sound prudent?
 * A standard pop-up should be generated on a successful password change... right?
 * see local file "mismatched edit history time zones AGAIN 20180927.png" (LIFO 2018)
 * Figure out what we should be seeing based on latest circumstances of
 * I think Monaco should be showing my edit count rather than hers, given the rest of the rendered page has redirected
 * This shouldn't have worked without the movestable right
 * This might be a list of parameter-less wikilinks in Special:AllMessages. If that's so, any remaining redlink may need remediation
 * NUMBEROFARTICLES should actually work as of MediaWiki 1.32 . I could possibly test this, e.g.:
 * Coordinate with Xymph to know when a mass creation will happen, and be around to watch the value
 * With Fraggle's approval, mass-add something to choco wiki (I'm sure some task needs doing; writing documentation is crashingly boring after all)


 * see local file "20170814 wackass google related keywords.png" (LIFO 2018)
 * see local file "20180608 email reset system message I forget why.png" (LIFO 2018)
 * see local file "20170707 blacklist false pos on userpage I think.png" (LIFO 2018). Presumably related to one of the blacklist bugs I subscribed to on Phabricator
 * choco:Special:Version/Credits

Search module

 * "30uv" and "30nm" return NOTHING in the core search, not even in talk
 * keyword for CirrusSearch was supposed to be implemented, but isn't
 * Mobile search is case-sensitive (least astonishment anyone?)
 * E.g. "E1m6" returns nothing. Test "broaden this to a title search" option again though
 * Possibly related: searching for "Special:Cont" pops up two suggestions both of which are broken links
 * Possibly related: searching "2016" doesn't pick up Cacowards 2016 as a title match (wtf)

FlaggedRevs guidelines proposal
20200815: this is not nearly as fleshed-out as I remembered, sorry Quasar! Needs much more pondering, separation of the 3 approval dimensions if we want to retain those, and for maximal clarity, real historical examples (start with my mass review from the relaunch &mdash; no doubt there are howlers there)

For argument's sake I'm assuming there are still 5 rating levels, although that is configurable as is the number of user groups.


 * Level 1: body text is ONLY required to be on topic and not spam/vandalism. No categories, templates, headers, neutrality, bibliography needed.  Thus, when specialized  is difficult to research, unrelated basic content can still be approved at a lower level
 * Level 1: page title must have correct spelling/grammar/style, since they are hard to rename afterward
 * Level 1: content must conform to Terms of Use, as well as other rules we've adopted in a quasi-legal way per the wiki's potential community impact. Users who cannot commit to staying current with such constraints should resign advanced rights
 * Level 3: lack of POV editing on known controversies (Bobby Prince inspirations, Skulltag team schism)
 * Level 4: body text must have correct spelling/grammar/style. No point doing it before this since major content additions tend to scramble everything up again
 * Level 5: citations must be inline and fully formatted
 * Assuming consensus eventually forms, how to address backlog of totally unreviewed pages in a way that won't burn anyone out or confuse other contributors?
 * Use MediaWiki's patrolling feature to decrease approval time for certain edits?
 * If anyone remembers what the "manual stabilization" feature is (it's mentioned in my notes from the 2014 upgrade) and thinks it's important, incorporate it here also

Orthogonal to this proposal, but important and anyone should feel free to launch a separate discussion


 * Whether the topic of a new page is within the wiki's scope at all (that's handled by talk threads, including deletion nominations if someone thinks it's already hopeless)
 * Choice of namespaces subject to FlaggedRevs
 * Criteria for manually assigning Editor/Reviewer privileges
 * Autopromotion (parameters, existing consensus-building status if any)
 * Specific user permissions assigned or not assigned to each group
 * Required activity level for any Editor not autopromoted
 * Does the existence of a moderation process increase legal liability for the project as a whole, and/or for the user approving a particular change?
 * Severe and ongoing impact on newbie participation (together with related "features" like link captchas, edit filtering, blacklists)

Background


 * This proposal was tabled for years due to server stability concerns, which are now resolved
 * FlaggedRevs is unmaintained, and may well need replacement by a more compatible extension such as Moderation, especially if queueing all contributions is deemed necessary for legal reasons (which may or may not be possible currently)
 * Proposed criteria/procedures need to be worded in a general way in case the extension has had major backend changes. Since the last install on doomwiki.org, I thought it had, but it proved difficult to pick out algorithmic development from among the forest of i18n additions:
 * Details of criteria will be constrained by how many config changes the shell team is willing to make, and if that amount is none, whether they are willing to share the current applicable values (similar informational requests have been rejected on security grounds)

Phabricator submissions (test again on a supported device, preferably in Wikipedia sandbox since that's configured by PHP experts, and then search for existing reports obviously)
Disclaimer for phab posts going forward: link to veteran devs saying phab search sucks eggs


 * Desktop mode not retained when relaunching phone browser
 * For system messages that have been edited, the history shows the first diff size as though the default were empty
 * Special:WhatLinksHere omits links in file space (EDIT: I have a feeling this meant in *log summaries*, which are not really part of the page, so this might well be invalid)
 * There is apparently no way to shut off that watchlist banner linking to Special:OldReviewedPages. This seems like not a good idea, because it encourages ership of articles on one's watchlist
 * During testing after the mid-2017 MediaWiki upgrade, I said: "AbuseFilter triggers on rangeblocked IP users &mdash; checking for blocks FIRST would help with cond limit afaict". Which it would, but such an early exit condition would also prevent blocked users from editing their own talk pages, ESSENTIAL for due process.  So when you file this as an enhancement, note that caveat
 * Special:AllPages should support namespace -1, to make sure custom documentation is complete
 * Special:AllPages title range ignored if a prefix is specified in the URL
 * Phrase search results have a "create this page" link that inherits the quotation marks. Counterargument:
 * Xymph on IRC: "well search for multiple words while not requiring a fixed string combo can be useful in other situations, so i dunno whether something needs to change in that behavioir"


 * In preview mode, generate the template/category links *from* the new text, so they'll be current
 * Include default system message text in Special:WhatLinksHere
 * In preview mode, show HTML header blocks above the preview, not above the diff
 * doesn't affect drop-down menus
 * on mediawiki.org, advanced search doesn't completely implement . According to mw:Extension:AdvancedSearch, beta phase is now over so this is legitimately submittable
 * strikethrough tags applied across multiple lines of a bulleted list leave holes
 * feature request to suppress bot comments / logging entries in a bug's feed (upstream)
 * priority (none) always shows as null in change tracker feed (upstream?)
 * Good god. Autogenerated comment ID anchors can be off by one, mass-breaking links (upstream?).  E.g. "In T218207#5021141, @Nikerabbit wrote" but the hover link is 5021142
 * Oh, cuh-RAP. Revision IDs were scrambled too?

Editing Luke Brennan (Lobo) The text you wanted to save was blocked by the spam filter. This is probably caused by a link to a blacklisted external site. The following text is what triggered our spam filter: no-ip.
 * blacklist should be checked BEFORE presenting a captcha, so newbies aren't told their time is worthless:
 * Outdated, diffuse technical references which nevertheless pointed out that the above non-captcha text is in core: MediaWiki:Spamprotectiontext, mw:Extension:ConfirmEdit, mw:Manual:Combating spam, mw:Help:System message, m:Help:System message


 * An excellent question, and also the target field should match on the destination title as well as the original title.

After any upgrade (IIRC)

 * Before-and-after comparison of default prefs
 * Advise all users to check whether any prefs were force-changed to new defaults (like a mobile OS upgrade)
 * Check for broken links in Entryway headers/footers/sidebars, in all skins
 * Check for redlinks in interface messages
 * There currently isn't any efficient way to do this (as has been reported to Phabricator) although  looked 99% effective last time, so try mass-pasting that into a sandbox

Configuration

 * Delete obsolete system messages (existing in message space but not Special:AllMessages)
 * Needs explicit consensus as it may disrupt gadget development (and is unprecedented overall)
 * Actually, does AllMessages include everything in use? Translations titled as fake subpages, for example
 * There are thousands of strings now, so first pass may have to be compiled through the API
 * Some discrepancies may actually be caused by extension bugs/rot and should be reported there instead of flushed like this, but that can only be verified by searching the source code for the message (which isn't necessarily literal text)


 * Automatically purge deleted content after a set period, per previously expressed concerns about legal liability and disk space
 * Retain server-side IP logging for only a limited time, per previously expressed concerns about legal liability and disk space
 * Inactivity hardening (per Wikipedia proposals over the years):
 * Merge sleeper accounts (no database interaction whatsoever including deleted edits, oversighted edits, hidden log entries) into a blocked dummy account N weeks/months after creation
 * Block accounts after N years of complete inactivity
 * Remove enhanced account permissions after N years of never being used
 * Temporarily block users with weak passwords


 * Server-side implementation of best-practice ping spam countermeasures (found with an hour of googling, so our shell team can't possibly claim ignorance), thus this concept of emergency checkuser access should never again enter anyone's mind
 * Regularly audit external resources in publicly visible CSS/JS
 * Uninstall interwiki extension
 * Templated links have immeasurably more flexible syntax and formatting, are easier to organize, can be sandboxed, can be undeleted
 * Purpose unclear: open-content knowledgebases are indiscriminately lumped with random general references imported from Fandom. Apparently any domain with the required glob format can be added
 * Counterarguments: multiple languages (far future but has occasionally been proposed), search rank boost from implied endorsement of site as a trusted peer (is this real?), bot replacement of links would be a huge job with no reader-facing effect


 * Spring-loaded license selector for Special:Upload so it's not a monolithic list
 * Update categories of interest, remove exhausted categories, remove deprecated templates
 * Coding references from whenever I last thought about this, which may or may not still be relevant or even live:        
 * Templates have proliferated since the last overhaul. In fact a skilled JS programmer could presumably replace this whole thing with a tagging widget dynamically based on the template categorization tree, but we're all volunteers here so I'm not assuming one will drop by :>


 * Did we check existing YouTube embeds for minimum size?
 * See local file "uncategorized files hysteresis 20181112.png" (LIFO 2018). Xymph thinks this doesn't ever fully rebuild
 * Revisit inconsistencies and redundancies at Special:ListGroupRights?
 * Previous threads suggest effort is grossly out of proportion to long-term benefit and user appreciation, so very low priority
 * Editor permission should include movestable and skipcaptcha
 * Reviewers should be able to see Special:Unreviewedpages

Disambiguation extension

 * Quasar guessed that disambig links could be easily found via page properties. But for the particular case of disambig, the property is populated only by the __DISAMBIG__ magic word, which is part of the extension (per the extension documentation).  So *if* whitelisting is enabled at some point, we can perhaps revisit this as the utility may be enough to justify the server space.  Perhaps.  20190925: I have no clue what half these words even mean anymore
 * What was this and is it now relevant again?

Documentation

 * mediawiki.org needs a reference guide on setup and configuration for self-hosted sites
 * Help pages to draft or copy
 * Interface messages to customize
 * Redlinks to turn blue (terms of use, privacy policy, intellectual property reuse rules)
 * Config settings whose defaults are ludicrous for non-WMF projects
 * Disable entry of email addresses and real names, which I think are no longer used in core anyway after some Californian privacy law took effect
 * Recommended extensions
 * Recommended skins, and links to thorough references on CSS
 * Document which special pages are useful for non-WMF projects and which are not
 * Default interface messages on Special:SpecialPages are probably misleading to newbies
 * Help:Special pages should be migrated to this guide and decommissioned, with existing internal links retargeted. No idea why we poured so many hours into a document that would help people so rarely
 * Advice on caching times, or indeed whether a given page is worth auto-refreshing at all
 * Special:WantedPages: a red link in mainspace indicates a wanted article ( 1 2 3 4 5 ) but elsewhere it can mean . Counterargument: actually implementing a filter is Wickid Hard due to query tuning considerations. We have accepted without comment workarounds like creating fifty blank template talk pages to get them off the list
 * Advice for touchy admin actions such as rangeblocking, oversight, checkuser (even the Wikipedia help was godawful last I looked, written for and by programmers with an interest in network topology)
 * Advice on links tables updates and what to do if (as is quite likely) some lag must be implemented for server stability
 * Since I started this TODO, some WMF people have apparently launched documentation intended for backbench WMF projects, which could theoretically inform the front end aspects of this guide:
 * Small wiki toolkits
 * Small Wiki Monitoring Team
 * If I dare, big-picture discussion of possible governance models and a reminder that you don't need to imitate Wikipedia at all (for better or worse). If only an educated peer group is ever expected to participate, like an old "professional society" group on Usenet, maybe you can go in with an assumption of kinda sorta good behavior among rank and file.  If you're a console gaming wiki, you will see every conceivable example of unhealth, and won't be able to extend good faith to random people
 * Advice for sysadmins wanting to increase accessibility for end users who obfuscate their location/identity to protect their privacy (but I certainly couldn't write such a page)


 * Update help page if FlaggedRevs procedure changes
 * Anyone feeling brave could even start a rationale section, saying the ratio of active power users to all users nowadays is MUCH SMALLER than in 2005 so it's impossible to have immediate talk discussions of every edit that looks a bit off base. Never mind the paid IT staff of 12 to intercept malicious traffic.  So we have to be able to verify content asynchronously.  (Thanks to RjY on IRC for suggesting this part)