== Integrate a modern php REPL shell with MediaWiki ==
{{tracked|T117661}}{{../buttons|task=T117661|title=Integrate a modern php REPL shell with MediaWiki}}
Currently MediaWiki provides a custom console via eval.php, which is integrated with the wiki's environment but otherwise rather poor (no proper readline support, no fatal error handling, the P part of REPL is missing, no tab autocompletion, no reflection...). Vagrant provides phpsh / hhvmsh which is somewhat better but still mediocre. It would be nice to replace these with a great REPL like [http://psysh.org/ PsySH] or [https://changelog.com/meet-boris-a-tiny-repl-for-php/ Boris].
=== Endorsements (T117661) ===
#
=== Support (T117661) ===
#
== Remove IE8 hacks/workarounds/etc. from extensions ==
{{tracked|T123218}}{{../buttons|task=T123218|title=Remove IE8 hacks/workarounds/etc. from extensions}}
As of [https://phabricator.wikimedia.org/rMWdf1019c49d30b8c87b144ecfeea200684c5b4a73 rMWdf1019c49d30: startup.js: Move IE8 down from Grade A to Grade C], MediaWiki no longer serves JavaScript to IE8 users. There are a lot of IE8 hacks lying around that can now be removed. grepping for "IE8" will likely find a lot.
== Automatically add "patch-for-review" tag when `arc diff` ==
{{tracked|T150510}}{{../buttons|task=T150510|title=Automatically add "patch-for-review" tag when `arc diff`}}
=== Problem ===
In contrast to Gerrit patches with "Bug: TXXXXXX" in the commit message, there is no "patch-for-review" tag added for Differential patches on <code>arc diff</code>.
=== Who would benefit ===
The tag is helpful to maintain better overview on the state of tasks for developers and product managers in workboards, like for example [https://phabricator.wikimedia.org/tag/ui-standardization-kanban #ui-standardization-kanban]
Currently you have to manually add the tag, see <s>[https://phabricator.wikimedia.org/T147612 T147612: Variable naming in WikimediaUI Base]</s> as comparison.
=== Proposed solution ===
Add [https://phabricator.wikimedia.org/tag/patch-for-review #patch-for-review] tag when triggered trough valid commit message at <code>arc diff</code>.
=== Endorsements (T150510) ===
#
=== Support (T150510) ===
#
== MediaWiki.org: Generate infoboxes from extension.json in git ==
{{tracked|T155029}}{{../buttons|task=T155029|title=MediaWiki.org: Generate infoboxes from extension.json in git}}
=== Problem ===
There are some widely used information templates on mediawiki.org which display some software information that could be easily extracted from the source code, but those templates are currently created and maintained manually. This is inefficient and ineffective - it's a significant amount of manual work and often not done, or not updated when code changes. Example: [https://www.mediawiki.org/wiki/Template:Extension extension], [https://www.mediawiki.org/wiki/Template:ExtensionInstall extension install], [https://www.mediawiki.org/wiki/Template:MediaWikiHook hook] and [https://www.mediawiki.org/wiki/Template:SettingSummary config variable] templates.
=== Who would benefit ===
* Developers who don't need to spend time on creating or updating hook/config var pages whenever they
* Extension maintainers (especially people who routinely change others' extensions) who don't need to track things like required MW version in two different places
* Developers and site admins who will gain access to correct and complete documentation
* Possibly site admins running older MW versions because this would allow a much more user-friendly presentation of MW compatibility information
=== Proposed solution ===
# find a place to store structured mw.org infobox data - there are several possible approaches, see [https://phabricator.wikimedia.org/T155024 T155024: Store structured needed for MediaWiki documentation] for discussion
# write a bot to extract the data from git (<code>extension.json</code>, <code>hooks.txt</code>, <code>DefaultSettings.php</code> phpdoc) and upload it
# fetch the data in the infoboxes
# for hook/configvar pages, make the bot create them automatically with stub content when they don't exist
# run a bot with some regular frequency (e.g. weekly) to update the pages accordingly
=== Endorsements (T155029) ===
#
=== Support (T155029) ===
#
== Structured data side channel for wikitext ==
{{tracked|T156876}}{{../buttons|task=T156876|title=Structured data side channel for wikitext}}
The problem of passing structured data from wikitext to external applications comes up in a wide variety of contexts, and a garden of ugly workarounds has grown around it, usually consisting of encoding the data in the HTML rendered from wikitext in some way, then external applications parsing it out and restoring the structure. Examples include [https://phabricator.wikimedia.org/tag/CommonsMetadata #CommonsMetadata], the various services (#mcs, all kinds of Tool Labs tools) exposing mainpage/featured content (article/picture of the day, anniversaries, in the news etc), article maintenance / warning templates, infoboxes, using Wiktionary for word translation.
Eventually these issues should be handled by separating wikitext and structured data (e.g. with [https://phabricator.wikimedia.org/T107595 T107595: [RFC] Multi-Content Revisions]) but that's a huge project and will take a while. A quick win that would be possible right now and would make the life of developers mining structured from wikitext (and editors maintaining the wikitext) would be to create a side channel where wikitext code can output structured data (with a dedicated parserfunction Lua method), in a simple hierarchic key-value format. The data could exposed by the parser and the parse API, and eventually morph into a virtual MCR slot.
=== Endorsements (T156876) ===
#
=== Support (T156876) ===
#
== Choose a recommended IDE for MediaWiki and maintain a plugin for it ==
{{tracked|T156873}}{{../buttons|task=T156873|title=Choose a recommended IDE for MediaWiki and maintain a plugin for it}}
Good IDE integration convenient for everyone but especially helpful to new contributors who are not experienced coders - they have to learn a thousand new things from code review / distributed version control workflows to security back practices, and if we can avoid adding "learn how to tweak your IDE configuration" to that pile, we can make the learning curve significantly smoother.
A well-integrated IDE would
* ensure that the right coding conventions are followed
* do some of the CI checks in a much more user-friendly way (banana, autoloading etc.)
* provide docs / typing / code completion / clickthrough navigation for systems which IDEs cannot figure out by default (e.g. hooks, global variables, extension-provided services, ResourceLoader modules)
* maybe show docs/help from mediawiki.org
* maybe warn when some MediaWiki best practices are not used (e.g. extension with PHP endpoint)
This does not mean that MediaWiki would be optimized to work with one IDE to the detriment of others, but it's nice to have a default.
PHPStorm integration already seems to have [https://github.com/reedy/phpstorm-plugin-mediawiki some momentum] behind it, but which IDE we focus on is secondary to agreeing to focus on a single one.
=== Endorsements (T156873) ===
#
=== Support (T156873) ===
#
== Showcase how the separation of concerns should work between MediaWiki API and web ==
{{tracked|T156872}}{{../buttons|task=T156872|title=Showcase how the separation of concerns should work between MediaWiki API and web}}
MediaWiki API modules and special pages contain lots of business logic, often duplicated between the two in similar-but-not-quite-identical ways. The business logic in these pages also tends to be inaccessible internally (so MediaWiki code that wants to access the functionality does horrible things like instantiating a <code>SpecialPage</code> object or making <code>FauxRequest</code> calls to the API). Everyone agrees the current situation sucks; no one seems to be sure how exactly the right way would look like, so newly written code does not necessarily end up in better shape.
We should pick some special pages and API modules (probably two of each since the answer will look very differently for something that does paged queries and for everything else), refactor them and turn them into a showcase that can be used as a guidance for future work.
=== Endorsements (T156872) ===
#
=== Support (T156872) ===
#
== Core should be aware of the domain it is running on and render mobile domains where necessary ==
{{tracked|T156847}}{{../buttons|task=T156847|title=Core should be aware of the domain it is running on and render mobile domains where necessary}}
Whenever a link to a desktop url is rendered on a mobile page, clicking it can take you to the desktop site (or cause you to go through an unnecessary redirect loop)
This impacts Flow, Echo, MobileFrontend (languageS) and causes lots of development pain (see child tasks).
A call to getFullURL or getFullRequestURL should be aware of the domain it is running on and give the correct result.
Essentially this means doing mobile site detection in core.
[I hope this doesn't turn into a bikeshed of responsive sites vs separate desktop/mobile sites. Both are useful and up to a sysadmin to decide and we should support them both.]
=== Endorsements (T156847) ===
#
=== Support (T156847) ===
#
== Introduce and document a minimum rights hierarchy ==
{{tracked|T156789}}{{../buttons|task=T156789|title=Introduce and document a minimum rights hierarchy}}
=== Problem ===
There seems to be an undocumented and inconsistent hierarchy of rights. For example, if I cannot view a page, I cannot edit it. But: if I can't edit, can I still move? In particular, the API has no concept of a hierarchy of rights. This leads to potential security issues in read protected MediaWikis.
=== Who would benefit ===
Extension developers and MediaWiki maintainers will have a more clear cut security model.
=== Proposed solution ===
We should add a minimum hierarchy in our rights, such as read > edit > other actions, similar to the way we have a hierarchy in the user groups: * > user > other groups. If one cannot read, they cannot do anything else. If one cannot edit, they cannot do any other modifications. I know this is too simplistic, so we need to sketch out a proper hierarchy. The hierarchy should also be documented.
=== Endorsements (T156789) ===
#
=== Support (T156789) ===
#
== Improve support for read access restriction / access control ==
{{tracked|T156788}}{{../buttons|task=T156788|title=Improve support for read access restriction / access control}}
=== Problem ===
There are a lot of extension using the userCan hook for access control. Yet there are still parts of the core where userCan is not considered. This is true in particular for read access. For example, afaik, QueryPages do not consider read access. Quite often, this is as simple as adding a userCan hook call. I'm not proposing to make Mediawiki read access bullet proof, but to fix the most obvious read access holes.
=== Who would benefit ===
Extension developers who need to implement access control for their mediawikis
=== Proposed solution ===
We can use this list as a basis: https://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions . It needs to be updated to the current state of MediaWiki. Then the open questions / issues can be addressed in the code. Ideally, at the end we have a positive list of which pages / actions consider read access.
=== Endorsements (T156788) ===
#
=== Support (T156788) ===
#
== Add examples of the three security review processes ==
{{tracked|T156757}}{{../buttons|task=T156757|title=Add examples of the three security review processes}}
=== Problem ===
[https://www.mediawiki.org/wiki/Wikimedia_Security_Team/Security_reviews Wikimedia Security Team/Security reviews] lists three separate processes which are either recommended or required in order to get an extension deployed on Wikimedia servers.
For non-WMF developers it can be unclear what is needed for each review step and how the Security team expects the information to be presented.
=== Who would benefit ===
* Anyone unfamiliar with the current review practices, likely meaning extension developers outside of the WMF.
* The security team: Clearer expectations/instructions should hopefully help streamline new external review requests.
=== Proposed solution ===
Identify one or a few good real-life examples for each process (or at least the latter two) to promote as case studies.
=== Endorsements (T156757) ===
#
=== Support (T156757) ===
#
== Add a maintenance script for complete cache reset ==
{{tracked|T156695}}{{../buttons|task=T156695|title=Add a maintenance script for complete cache reset}}
=== Problem ===
There seems to be no way to reset all caches programmatically. One example is the Resource Loader minification cache. In extension development and when updating mediawiki installations, I ran into issues with improper cache invalidation. A complete manual reset of all caches helped, yet a script would be very helpful.
=== Who would benefit ===
Developers and MediaWiki maintainers
=== Proposed solution ===
Create a maintenance script which invalidates all caches. Preferrably with the option to selectively invalidate some types of caches, e.g. Resource Loadere minification.
=== Endorsements (T156695) ===
#
=== Support (T156695) ===
#
== Complete documentation about different types of caching for extension developers ==
{{tracked|T156693}}{{../buttons|task=T156693|title=Complete documentation about different types of caching for extension developers}}
=== Problem ===
As an extension developer, I often ran into issues where my code would not be executed / updated due to some cache hit in earlier parts of the code. Documentation is spread out all over MediaWiki, and incomplete.
=== Who would benefit ===
Extension developers who write code that dynamically changes page content and need to know when and how to invalidate the caches.
=== Proposed solution ===
A good starting point is https://www.mediawiki.org/wiki/Manual:Caching. We need to complete the information missing for some cache types. A rough description of which caches are used when in the execution order would be extremely helpful (maybe in relation to some central hooks). Also, some information of how these caches can be invalidated within the code and in general should be added.
=== Endorsements (T156693) ===
#
=== Support (T156693) ===
#
== Fix or replace Module:Assemble multilingual message ==
{{tracked|T156674}}{{../buttons|task=T156674|title=Fix or replace Module:Assemble multilingual message}}
=== Problem ===
The process for updating users about technical changes is far more complex than it should be. If I have a technical newsletter (Tech News, specific newsletters for teams or products) and want to reach out in several languages, this is the process to send it out:
* Generate the text on Meta using a Lua module that combines all languages and adds a switch. [https://meta.wikimedia.org/w/index.php?title=Tech/News/Sandbox&oldid=16250936 See example].
* Realize you had too many languages, the module can't handle more than 20.
* Generate the first 20.
* Generate the next batch.
* Carefully insert the new languages.
* Find the duplication of the source text (typically English) and remove one of them.
* Test it.
* Find a mistake.
* Fix it on Meta.
* Redo the entire process.
* Finally send it out.
=== Who would benefit ===
Anyone keeping users updated about technical changes: upcoming, things they can give feedback on, or new changes.
=== Proposed solution ===
At least make sure we can send out messages to more than 20 languages without inviting mistakes by manual insertion prior to MassMessaging all the wikis.
{{tracked|T156640}}{{../buttons|task=T156640|title=Improve LTS support of extensions}}
=== Problem ===
MediaWiki has a LTS release, which receives security updates. Unfortunately most extensions are being developed in current <code>master</code> or maybe latest <code>wmf*</code> branch. That means that downloading an extension from <code>REL1_27</code> branch (e.g. by using Special:ExtensionDistributor) leaves the user with an outdated and potentially insecure codebase.
=== Who would benefit ===
Everyone who wants to use LTS version of MediaWiki and also be sure extensions that work with this version don't have security issues or severe bugs
=== Proposed solution ===
At least the greater WMF extensions like "WikiEditor", "VisualEditor/Parsoid", "FlaggedRevs", "CategoryTree", ... should get bugfix and security cherry-picks/backports from the current development into <code>REL1_27</code>.
Of course most voluntary, WMF-independent extension developers won't have time/will to do something like this, but maybe we can find a way to help them or at least make them more aware of the LTS release.
=== Endorsements (T156640) ===
#
=== Support (T156640) ===
#
== Review and update the Examples extension ==
{{tracked|T156568}}{{../buttons|task=T156568|title=Review and update the Examples extension}}
Other than ContentAction, which was touched during GCI, the code in the Examples extension hasn't really been touched for a few years. It would be nice to give it a spring clean, updating code to follow modern coding practices for MediaWiki extensions.
=== Endorsements (T156568) ===
#
=== Support (T156568) ===
#
== Document extensions' MediaWiki version compatibility better ==
{{tracked|T156500}}{{../buttons|task=T156500|title=Document extensions' MediaWiki version compatibility better}}
=== Problem ===
Extensions are (supposed to be) documented on a page on MediaWiki. This documentation includes [https://www.mediawiki.org/wiki/Template:Extension Template:Extension] to provide a summary of important information about the extension, including the "required version of MediaWiki".
This version field is inadequate: does specifying "1.19+" mean that the extension's master branch is intended to be compatible with MediaWiki 1.19, or that the extension has release branches going back to REL1_19 while the extension's master branch is only intended to be compatible with MediaWiki core's master branch, or perhaps some middle ground?
Some extensions have solved this by including detailed text in the existing "version" parameter, such as "1.26+ . Flow master is only supported with core's master; otherwise, use matching branches (e.g. Flow REL1_26 with core REL1_26, or matching WMF release branches).", but this is currently done inconsistently and infrequently.
=== Who would benefit ===
Developers making updates to extensions for a core change in compliance with the new [https://www.mediawiki.org/wiki/Deprecation deprecation policy] will no longer have to guess at whether backwards compatibility with older versions of MediaWiki core should be maintained.
Developers of extensions that don't maintain compatibility with old versions of MediaWiki won't have unnecessary and sometimes complex backwards-compatibility code added.
Developers of extensions that do maintain compatibility with old versions of MediaWiki won't have to -1 or -2 as many changes that break backwards compatibility.
=== Proposed solution ===
# Update Template:Extension with parameters to indicate the MediaWiki versions for which release branches exist versus the MediaWiki versions the extension's master branch maintains compatibility with.
# Update existing extension pages to use these parameters, which may involve determining the master-compatibility policy where it's not already specified.
=== Endorsements (T156500) ===
#
=== Support (T156500) ===
#
== Create a developer documentation special interest group ==
{{tracked|T156301}}{{../buttons|task=T156301|title=Create a developer documentation special interest group}}
'''Problem'''<br>
Documentation is out of date, incomplete ([https://phabricator.wikimedia.org/T2001 T2001: Documentation is out of date, incomplete (tracking)])
Wikimedia produces a large number of FLOSS software products targeted at various audiences. The audiences need documentation in the form of tutorials, API references, platform overviews, etc to effectively use and extend the products. MediaWiki itself is a highly extensible platform for creating solutions for collaborative, open sharing of information. Sadly, this platform itself is under-documented which slows down the rate at which developers can produce innovative solutions based on it. "Read the source code" is not an acceptable way to gain an initial understanding of a product offering, but many software developers lack the time, motivation, and skills needed to effectively and completely document the solutions they produce. Improved technical documentation of the internal and external interfaces that can be used to extend or programmatically consume MediaWiki hosted content should make use and development easier for existing and future technical contributors.
'''Solution'''<br>
Create [https://en.wikipedia.org/wiki/Special_Interest_Group special interest group] in charge of:
* Triaging/grooming the [https://phabricator.wikimedia.org/tag/documentation #documentation] workboard.
* Identifying top priorities based on impact and interest.
* Organizing activities (including lobbying to the Wikimedia Foundation) in order to complete the top priorities.
* Attracting people interested in working on documentation.
* Connecting documentation volunteers with people and projects who can help get them started.
* Advocating documentation best practices for Wikimedia products.
* Developing resources to make contributing technical documentation easier.
'''See also'''<br>
* [https://www.mediawiki.org/wiki/User:Xephyr826/Recruiting_Technical_Writers Community with outreach potential: Technical Writers]
=== Endorsements (T156301) ===
#
=== Support (T156301) ===
#
== Provide an alternative (more declarative) way to create classes in OOJS (UI) ==
{{tracked|T156235}}{{../buttons|task=T156235|title=Provide an alternative (more declarative) way to create classes in OOJS (UI)}}
=== Problem ===
Creating new classes/widgets with OOJS UI feels very cumbersome (see [https://phabricator.wikimedia.org/T155567 T155567: Make OOjs UI easier to use for gadgets]). E.g. method declaration is split into different statements all across the source file.
=== Who would benefit ===
Any developer that wants to work with OOJS (UI)
=== Proposed solution ===
Create a high level function that allows more declarative creation of a class. E.g.:
<syntaxhighlight lang="text">
OO.defineClass({
className: 'MyExtension.ui.dialog.Edit' //"namespace" get's created automatically
extends: 'OO.ui.Dialog',
titleMsg: 'myext-dialog-edit-title',
initialize: function () {
MyExtension.ui.dialog.Edit.super.prototype.initialize.call( this );
== Make it easier to manage/deliver files created by extensions ==
{{tracked|T156233}}{{../buttons|task=T156233|title=Make it easier to manage/deliver files created by extensions}}
=== Problem ===
There are some extensions (e.g. Extension:Math) that create files dynamically and then deliver those files to the user. Most extensions just create their files somewhere in <code>$wgUploadDirectory</code>, assuming that the location is accessible from the web. On private wikis this might not be true. Instead of direct delivery by the webserver the <code>img_auth.php</code> might be invoked. Unfortunately the current implementation sometimes makes it difficult or impossible to deliver files that are not part of the local filerepo.
=== Who would benefit ===
Any extension developer that wants to create files (images, pdfs, JNLP, xml, flat files, ...) dynamically and deliver them by a script entry point.
=== Proposed solution ===
* <code>img_auth.php</code> could be improved (see also [https://phabricator.wikimedia.org/T153174 T153174: img_auth.php: Improve extendability])
* A complete new entry point could be created
* Some mechanism besides filerepo/filebackend could be created that allows better management (save/cache, delete/invalidate, find) of files created by extensions
=== Endorsements (T156233) ===
#
=== Support (T156233) ===
#
== Provide an easy to use HTML mail system ==
{{tracked|T156231}}{{../buttons|task=T156231|title=Provide an easy to use HTML mail system}}
=== Problem ===
By default MediaWiki sends only oldfashioned plain text mails. With Extension:Echo there is at least a way to deliver some kind of HTML mail, but it is still very hard to customize the layout and design of those mails (need to override/extend classes).
=== Who would benefit ===
All developers that need to customize notification mails. This is especially a need in business contexts.
=== Proposed solution ===
There could be some directory that contains an HTML template and all required resources. E.g <code><mediawiki>/resources/mail/default</code> which contains <code>body.html</code>, <code>header.jpg</code>, <code>styles.css</code>, ...
Also the use of a library like SwiftMailer or PHPMailer should be considered.
There has been some approaches in the past, and I believe something like this is already planned for the Outreachy [https://phabricator.wikimedia.org/T15303 T15303: Implement HTML e-mail support in MediaWiki]
=== Endorsements (T156231) ===
#
=== Support (T156231) ===
#
== Display changes in sources codes like in Gerrit in red and green ==
{{tracked|T156048}}{{../buttons|task=T156048|title=Display changes in sources codes like in Gerrit in red and green}}
=== Problem ===
When we edit Lua or JavaScript code, we don't see what we have change, and many times that needs a big memory concentration.
=== Who would benefit ===
All Lua or JavaScript coders.
=== Proposed solution ===
When we edit Lua or JavaScript code, highlight differences like in Gerrit ( - + parts of line).
Do this when we explicitly ask differences, but also as option in any change from the previous version.
=== Description of the task ===
The way used in gerrit to display changes in source code seems better than some others.
In code panels, for old and new codes, gerrit colorises them in red and green for each changed character.
Then we could use it for other source codes: javascript for gadgets and user scripts, Lua modules, Lisp for templates.
=== Some chooses to select ===
guerrit uses '''2 ways''', which mode use?
In the '''mixing''' way, gerrit mixes the old and the new code lines, identify them with - and + signs, and hightlights them with red and green colors for each character.
In the '''columns''' way, gerrit put the old code in left and the new code in right column, and hightlights them with red and green colors for each character.
This styles also interfere with the '''usual hightlight''' of each code.
'''Where to use''' these display ways?
Perhaps also in wikitext for wikicontent?
Perhaps also when we display a revision-diff = "Difference between revisions"?
Even in VisualEditor?
'''When to use''' these display ways?
Each time when we edit a script or a module or a template and then clic on "show changes".
Also when we clic "Preview" to see the effect on a test page?
Begin to offer these ways for codes panels, and later extend them to other places?
'''When to activate''' these ways and modes?
When the user chooses these ways for each code panel?
When the user chooses them in his preferences?
=== Endorsements (T156048) ===
#
=== Support (T156048) ===
#
== Make it easier to create an OOUI theme ==
{{tracked|T155562}}{{../buttons|task=T155562|title=Make it easier to create an OOUI theme}}
To create a theme currently: get the oojs/ui repo, copy-paste the src/themes/blank directory to your own name, list the new theme in Gruntfile.js and maybe a few other places (i could find them all if you're serious about doing this), and start writing the CSS
I want a more modular approach, where themes are definable in any extension, and consist of an array of variables in json or less or something which OOUI then assembles that into the css/js itself:
* A set of colours for different things (borders, backgrounds, text, different types of buttons, etc)
* General properties - how much spacing in general, whether to even use any shadows, whether buttons should be gradiented or flat, whether to override fonts, that sort of thing
* Specific properties for all the types of things (buttons, dialogs, inputs, etc) such as rounded corners, gradients, shadows, fonts, padding - none, or specific values (what sort of gradient, what sort of shadow, how much padding)
* ...
* Profit?
=== Endorsements (T155562) ===
#
=== Support (T155562) ===
#
== VE support for skins should be done by adding appropriate anchors/ids/styles to the skins, and not by editing VE itself ==
{{tracked|T155554}}{{../buttons|task=T155554|title=VE support for skins should be done by adding appropriate anchors/ids/styles to the skins, and not by editing VE itself}}
Apparently the only way to make a skin work with VE is to edit VE itself. This makes it very hard to make new skins compatible with VE, despite more and more third-party projects desiring such compatibility.
It should be the other way around - compatibility should be in the skin, not VE. The skin should be edited to meet VE's expectations (maybe have appropriate ids or whatever on things where it should be showing up around the content, or a js snippet specifying how it is supposed to show up, or whatever?), and modified and styled appropriately to look right with it.
And how to do this should be documented somewhere so we can actually, well, do it.
=== Endorsements (T155554) ===
#
=== Support (T155554) ===
#
== Make Monolog the default debug processing layer and deprecate wfDebug* and LegacyLogger ==
{{tracked|T155552}}{{../buttons|task=T155552|title=Make Monolog the default debug processing layer and deprecate wfDebug* and LegacyLogger}}
=== Problem ===
The [https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-3-logger-interface.md PSR3] logging interface has been introduced in MediaWiki to support [https://www.mediawiki.org/wiki/Manual:Structured_logging structured logging], but no coordinated effort has been made to deprecate the use of <code>wfDebug()</code>, <code>wfDebugLog()</code>, <code>wfLogDBError()</code>, and <code>wfErrorLog()</code>. Several bugs are open in the [https://phabricator.wikimedia.org/tag/mediawiki-debug-logger #mediawiki-debug-logger] project about the lack of parity between debug log usability on the Wikimedia Foundation production cluster and a typical development environment or external deployment of MediaWiki that are directly related to [https://phabricator.wikimedia.org/p/bd808 bd808] taking the structured logging project to a point where it is useful for the WMF but not pushing that usability further for other MediaWiki deployments.
=== Who would benefit ===
* MediaWiki site operators who want better insight into their operational issues
* MediaWiki developers who don't want to think about choosing between two largely compatible but very different debug logging layers
=== Proposed solution ===
* Replace all usage of <code>wfDebug*</code> in MediaWiki core with direct PSR3 usage.
* Add [https://github.com/Seldaek/monolog Monolog] as a core dependency and the default debug logging solution.
* Make configuring Monolog easier by making helpers in the <code>MediaWiki\Logger\Monolog</code> namespace.
* Remove <code>MediaWiki\Logger\LegacyLogger</code> from core. (It could be made a library if there are people who really love it and want to keep maintaining a homegrown debug log formatting and routing layer.)
* Deprecate <code>wfDebug()</code>, <code>wfDebugLog()</code>, <code>wfLogDBError()</code>, and <code>wfErrorLog()</code>.
=== See also ===
* [https://phabricator.wikimedia.org/T88649 T88649: Convert MediaWiki logging to direct use of PSR-3]
* [https://phabricator.wikimedia.org/T128224 T128224: It is difficult to determine in which log bucket a logging call will end up]
* [https://phabricator.wikimedia.org/T92585 T92585: MediaWiki logging/debugging documentation is out of date]
* [https://phabricator.wikimedia.org/T108650 T108650: $wgMWLoggerDefaultSpi requires special usage, needs to be fixed or documented]
* [https://phabricator.wikimedia.org/T142313 T142313: Add global logging context]
* [https://phabricator.wikimedia.org/T114532 T114532: Monolog logging has no way to interact with MWDebug::debugMsg()]
=== Endorsements (T155552) ===
#
=== Support (T155552) ===
#
== Get rid of UTF-8 encoded as latin-1 ==
{{tracked|T155529}}{{../buttons|task=T155529|title=Get rid of UTF-8 encoded as latin-1}}
=== Problem ===
(copy and paste from https://www.mediawiki.org/wiki/Toolserver:Code_snippets#Fix_UTF-8_encoded_as_latin-1 )
Versions of MySQL before 5 did not have binary nor UTF-8 support (or at least nobody cared). A common workaround was to encode the text as a UTF-8 byte sequence and give that to MySQL which read the byte in as if they were latin-1 characters. This worked alright until MySQL and VARCHAR became more Unicode aware. Now depending on settings, it may convert the latin-1 bytes to Unicode code points then encode to your specified encoding. So <code>è</code> (U+00E8, UTF-8: <code>c3 a8</code>) becomes <code>è</code> (U+00C3 U+00A8, UTF-8: <code>c3 83 c2 a8</code>), the equivalent python transformation is <code>u'è'.encode('utf-8').decode('latin').encode('utf-8')</code>. This double encoding is the reason why JOINs will fail with the newer VARBINARY fields used everywhere by MediaWiki now.
This is quite complicated and annoying to work with. Source of bugs.
=== Who would benefit ===
Anyone who uses database access on Toollabs to do queries.
=== Proposed solution ===
Convert the remaining legacy field and tables so we don't have to do tricks like <code>CONVERT( CONVERT( CONVERT( your_column USING latin1) USING binary) USING utf8);</code> any more?
=== Endorsements (T155529) ===
#
=== Support (T155529) ===
#
== Improve documentation of OOjs UI ==
{{tracked|T155473}}{{../buttons|task=T155473|title=Improve documentation of OOjs UI}}
=== Problem ===
Extension developers and even core MediaWiki developers want to, or should want to, use a standardized design. Even if we don't like the standard itself, by using a standard we can then inherit improvements to the standard with little to no additional work.
OOjs UI is the standard. However, it is difficult to work with, owing to poor documentation. This discourages its use and adoption as a standard.
Compare this to other frameworks such as Semantic UI that make it very easy to use its design. You can use its JavaScript widgets for specialized features, or just use the CSS to get the look and feel if you are dealing with static HTML.
=== Who would benefit ===
People developing new extensions and those working on improvements to MediaWiki core and existing extensions. The Wikimedia Foundation would benefit from less time wasted on figuring out this system.
=== Proposed solution ===
Better documentation that makes it easier for developers to integrate OOjs UI.
The CompletenessTest was my attempt at getting a basic code coverage report using run-time inspection instead of static instrumentation.
It was never fully developed, remained somewhat unstable, isn't used by Jenkins or otherwise enabled or encouraged, and its results are not publishable, either. (Only works locally as on the Special:JavaScriptTest HTML view).
The "export" feature for Special:JavaScriptTest introduced in 2014 for Karma and TestSwarm (ba50b3255) lacked support support for loading the CompletenessTest. And when the regular "skinned" mode was deprecated and, eventually, removed last year in 0f9e4ca0f it essentially hasn't been used anymore as far as I can see.
From a Git-wide search I see that various Wikibase repositories still have references to it, so I won't remove it just yet. But it'd be good to know for sure if and how it's being used there. There's no rush behind its removal, but if it's not being used, that I'd rather we remove it from core.
== Organize a MediaWiki Documentation Day (similar to the Gerrit Cleanup Day) ==
{{tracked|T126500}}{{../buttons|task=T126500|title=Organize a MediaWiki Documentation Day (similar to the Gerrit Cleanup Day)}}
It would be awesome if we devoted 1 entire day to doing nothing but documenting MediaWiki. There are countless classes and functions in MediaWiki core and its extensions that have no documentation. There is also a serious lack of high level documentation for developers. The problem is that documentation is often an after-thought and rarely gets focused attention from developers.
Some suggested projects that could be part of MediaWiki Documentation Day:
* Tackle some of the blocking tasks at [https://phabricator.wikimedia.org/T2001 T2001: Documentation is out of date, incomplete (tracking)] or [https://phabricator.wikimedia.org/tag/tracking #tracking].
* Add in-code function descriptions for important functions that don't have them.
* Add in-code class descriptions to classes that don't have them.
* Create documentation pages on MediaWiki.org for important classes in core that don't have them. See [https://www.mediawiki.org/wiki/Manual:User.php Manual:User.php] for an example of a page that does exist. High-level documentation, like [https://www.mediawiki.org/wiki/Manual:Title.php#Title_structure Manual:Title.php#Title_structure] is especially useful.
* Clean up our [https://www.mediawiki.org/wiki/Category:Outdated_pages outdated documentation] on MediaWiki.org.
* Create README files for all the extensions that don't have them and make sure that all configuration variables are documented there.
* Create some high-level documentation on how to write new API modules.
'''See Also:'''<br>
* <s>[https://phabricator.wikimedia.org/T85592 T85592: Sort out [[:Category:Tutorials]]]</s>
* [https://phabricator.wikimedia.org/T101659 T101659: Run a documentation sprint for Labs]
* [https://phabricator.wikimedia.org/T117526 T117526: Improve the generated PHPdoc (by considering alternatives to Doxygen?)]
== Integrate a modern debug/error display tool into MediaWiki ==
{{tracked|T111731}}{{../buttons|task=T111731|title=Integrate a modern debug/error display tool into MediaWiki}}
The MediaWiki ecosystem has some highly sophisticated loggin/debugging/error reporting tools such as the ELK stack, but they are nontrivial to set up and an effort to use (you need to go to the aggregation site and search for your error or log message, instead of just having it right on the wiki page where the error happened). It would be nice to integrate some modern error display / debug tool into MediaWiki for casual development - probably as an extension, since such tools tend to be insecure. A few possibilities:
* [http://raveren.github.io/kint/ kint]
* [https://github.com/raulfraile/Ladybug Ladybug]
* [https://github.com/filp/whoops whoops]
=== Endorsements (T111731) ===
#
=== Support (T111731) ===
#
== [Task] Add mw.wikibase.getEntityObject by site link (title) Lua function ==
{{tracked|T74815}}{{../buttons|task=T74815|title=[Task] Add mw.wikibase.getEntityObject by site link (title) Lua function}}
Please add mw.wikibase.getEntityObject by site link (title) Lua function just like https://www.wikidata.org/wiki/Special:ItemByTitle or wbgetentities API module with titles parameter. It would be nice with and without language code or site code.
On '''cswiki''' articles translated from other language wikis are marked by Translated template (with source wiki, article and revision parameters filled in). The template could detect (using Module:Wikidata), whether the article is connected with that source article and categorize it if not. But if that source article is connected with other article in home wiki, it is false positive there (could be categorized too, but in a different maintenance category). I can not single out these false positives, because even if I can find out (using Lua function in Module:Wikidata) there is an article in home wiki for any Q-ID given, I can not find out that Q-ID for any wiki:page pair given.
On '''enwiki''' in Module:Wikidata talk page is another request from [https://phabricator.wikimedia.org/p/czar czar]: [https://en.wikipedia.org/wiki/Wikipedia_talk:Wikidata#QID_lookup_from_enwp_article_title QID lookup from enwp article title].
=== Endorsements (T74815) ===
#
=== Support (T74815) ===
#
== Make OOjs UI easier to use for gadgets ==
{{tracked|T155567}}{{../buttons|task=T155567|title=Make OOjs UI easier to use for gadgets}}
As I explained in [https://phabricator.wikimedia.org/T155473#2944504 T155473: Improve documentation of OOjs UI]
For example when someone wants to make a dialog box in OOjs UI:
(Copied from [https://www.mediawiki.org/wiki/OOjs_UI/Windows/Dialogs here]).
What I would love to see is some sort of form factory in javascript. Like HTMLFormFactory in php. So we only build an array of form descriptors and call it, then bam! the form is there. Something like:
<syntaxhighlight lang="text">
windowManager.openWindow(
{
name: 'MyDialog',
title: 'Simple dialog',
size: 'medium',
elements: [
{
id: 'panel1',
type: 'Panel',
attr: { padded: true, expanded: false }
},
{
tag: 'p',
text: 'A simple dialog window. Press \'Esc\' to close.',
parent: 'panel1'
}
]
}
);
</syntaxhighlight>
And/or somerhing like jQuery (which can consume existing HTML <code>div</code>s as the source of the dialogue:
<syntaxhighlight lang="text">
<div id="MyDialog" title="Simple dialog">
<p>A simple dialog window. Press \'Esc\' to close.</p>
</div>
</syntaxhighlight>
<syntaxhighlight lang="text">
$( function() {
$( "#MyDialog" ).dialog();
} );
</syntaxhighlight>
=== Endorsements (T155567) ===
#
=== Support (T155567) ===
#
== Re-evaluate how we implement phabricator's search engine ==
{{tracked|T146843}}{{../buttons|task=T146843|title=Re-evaluate how we implement phabricator's search engine}}
IMPORTANT: Experimental elasticsearch support has been enabled, to try it out please do the following. Enter something in the searchbar then you will get a url like https://phabricator.wikimedia.org/search/query/.trvn2LNszXn/#R please replace #R with ?elastic=1 which will give you elasticsearch results, example elasticsearch url https://phabricator.wikimedia.org/search/query/.trvn2LNszXn/?elastic=1
When we originally deployed Phabricator, we started out using the [https://phabricator.wikimedia.org/tag/ElasticSearch #ElasticSearch] back-end for searching phabricator Tasks / Objects. Unfortunately, after launching with [https://phabricator.wikimedia.org/tag/elasticsearch #elasticsearch] there were quite a few user complaints about unexpected search behavior and we eventually made the (IMO, somewhat hasty) decision to switch to using the MySQL Full-text search backend.
Now that we reached the scalability limit of MyISAM fulltext search, we've been sort of forced to switch to Innodb Fulltext search (see <s>[https://phabricator.wikimedia.org/T146673 T146673: Contention on search phabricator database creating full phabricator outages]</s>)... The fulltext search feature in innodb is not as mature as MyISAM fulltext. The ranking algorithm is very simplistic and I expect results to be lower quality than before.
ElasticSearch ''should be far superior'' to mysql for implementing phabricator search. Lets try again to solve the problems with phabricator's elasticsearch integration rather than settling for a much worse search experience in Innodb.
=== A bit of history ===
There is quite a bit of history behind Phabricator's search implementation. Some of the more relevant tasks I was able to dig up are linked below:
==== Original ElasticSearch task ====
<s>[https://phabricator.wikimedia.org/T95 T95: Use ElasticSearch backend for Maniphest to get stemming feature]</s>
==== Stuff about switching to MySQL ====
<s>[https://phabricator.wikimedia.org/T75854 T75854: Fix provided search results in Wikimedia Phabricator]</s>
<s>[https://phabricator.wikimedia.org/T86805 T86805: Lots of unrelated results when searching for specific string]</s>
==== Problems after switching to Mysql ====
<s>[https://phabricator.wikimedia.org/T89274 T89274: Mysql search issues flagged by Phabricator setup]</s>
<s>[https://phabricator.wikimedia.org/T146789 T146789: Phab Advanced Search no longer showing typical results]</s>
=== Endorsements (T146843) ===
#
=== Support (T146843) ===
#
== Allow excluding soft redirected categories on Special:UnusedCategories ==
{{tracked|T96041}}{{../buttons|task=T96041|title=Allow excluding soft redirected categories on Special:UnusedCategories}}
[[Special:UnusedCategories]] is flooded by tons of soft redirected categories. But purpose of this special page was to show real unused categories, not all unused ”aliases” aka redirecting categories.
It's necessary to define a special magic word which should be placed in ”Template:Category redirect” and in mediawiki core add a exception/condition - if category page has this special word (via transclusion) - then to not show this page in [[Special:UnusedCategories]]. Such a thing it's really necessary, because some wikipedias have over 15,000 redirected categories (!)
A similar technology is used for [[Special:DisambiguationPages]] where are listed all pages which contains the tag <code>__DISAMBIG__</code>
=== Endorsements (T96041) ===
#
=== Support (T96041) ===
#
== ApiQueryImageInfo is crufty, needs rewrite ==
{{tracked|T89971}}{{../buttons|task=T89971|title=ApiQueryImageInfo is crufty, needs rewrite}}
The code is a mess, the limit semantics make no sense, and we have several other options that don't really fit non-images.
The best thing to do here is probably to just write a prop=fileinfo module from scratch so we don't have to worry about backwards compatibility, and then deprecate prop=imageinfo.
Current plans:
* Right now, iilimit specifies the max number of revisions to return per file, which is inconsistent with the rest of the API and isn't particularly sane. For fileinfo, filimits will limit the number of file-info-objects returned per result, and a separate "fioldversions" property (default 0, values integers or 'all') will specify the max number of revisions to be returned per file.
* fistart/fiend may result in the info for the current revision not being returned.
* iiprops has three different metadata properties. There really should be only one, and if possible it should be key-value pairs rather than a list of objects with key and value properties.
** Metadata needs to be separately continuable, see [https://phabricator.wikimedia.org/T86611 T86611: API does not fail gracefully when data is too large].
* Figure out something sane to replace iiurlwidth/iiurlheight/iiurlparam. Maybe multi-valued fiparams?
* prop=stashimageinfo is very odd, it's a prop module but doesn't use any titles. It would make sense to me for prop=fileinfo to have a fifilekeys parameter instead of having a whole separate module for this.
* prop=videoinfo really isn't needed either. Instead we should make it possible for extensions to add additional info to the fileinfo response.
=== Endorsements (T89971) ===
#
=== Support (T89971) ===
#
== Expose php warnings in mediawiki-config more visibly ==
{{tracked|T87447}}{{../buttons|task=T87447|title=Expose php warnings in mediawiki-config more visibly}}
https://gerrit.wikimedia.org/r/#/c/185667/ would probably not have happened if we had noticed the PHP warnings. Changes to mediawiki-config are difficult to test locally, so spelling mistakes are hard to spot.
Most links in https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_and_monitor_your_live_code seem to contain no data, or are broken, and don't contain PHP warnings anyway, just fatals and exceptions.
=== Endorsements (T87447) ===
#
=== Support (T87447) ===
#
== Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed ==
{{tracked|T92621}}{{../buttons|task=T92621|title=Implement addition of un-redirected pages to Special:NewPages and Special:NewPagesFeed}}
Per consensus [https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)/Archive_117#Proposed_technical_change:_show_pages_expanded_from_redirects_on_Special:NewPages_and_Special:NewPagesFeed here], en-wiki's [https://en.wikipedia.org/wiki/User:Samwalton9 Samwalton9] activated [https://en.wikipedia.org/wiki/Special:AbuseFilter/342 the relevant abuse filter] on March 7th. After monitoring the [https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchFilter=342 filter log] for a week, we are satisfied that the behavior is ready to be implemented on Special:NewPages and Special:NewPagesFeed, with two caveats:
# Edits that ''revert '' a redirect to a prior state with content should ''not'' appear on these patrol pages.
# Pages where a redirect has been restored should disappear from the patrol pages, by analogy with new pages that have been deleted.
It's our understanding that this behavior can be implemented in the PageCuration extension. Thanks!
=== Endorsements (T92621) ===
#
=== Support (T92621) ===
#
== CodeEditor: Migrate from Ace to CodeMirror ==
{{tracked|T50826}}{{../buttons|task=T50826|title=CodeEditor: Migrate from Ace to CodeMirror}}
Has more features, is lighter(?) and has much better support for Unicode / BiDi text rendering (see http://codemirror.net/demo/bidi.html).
Plus Brion likes it :)
--------------------------
'''Version''': unspecified
'''Severity''': enhancement
=== Endorsements (T50826) ===
#
=== Support (T50826) ===
#
== Relocate CI generated docs and coverage reports ==
{{tracked|T137890}}{{../buttons|task=T137890|title=Relocate CI generated docs and coverage reports}}
Part of / blocker of <s>[https://phabricator.wikimedia.org/T133300 T133300: Target architecture without gallium.wikimedia.org]</s>
Another blocker, and potentially a prerequisite, is publishing the generated documentation. From the drawing and https://www.mediawiki.org/wiki/Continuous_integration/Documentation_generation
[https://docs.google.com/drawings/d/16aYqCa9nSY6SR1zQazQZ6gVSme-VRm8ObGgPqbjXgeE/edit CI Target 2016 - Relocation of Doc / coverage reports (private)] gives an overview of the documentation flow.
As summarized by [https://phabricator.wikimedia.org/p/thcipriani thcipriani] :
Current:
* Doc and coverage reports are generated on Nodepool instances (they have lot of build dependencies)
* Building instance rsync to a labs instance <code>integration-publisher</code>
* A Jenkins job <code>publish-on-gallium</code> is executing on gallium to rsync the doc from the publisher instance.
We would need an instance to host the material with PHP5 (some docs need that). Most probably out of the labs support host / on an isolated network. We would need some intermediary system to have the Nodepool building instances to push to.
* Doc and coverage reports are still generated on Nodepool instances
* Building instance push to a publisher system
** might reuse <code>integration-publisher</code>
* Jenkins (or another system) runs a task that fetch from the publisher system to doc.wikimedia.org document root.
We need to find a target host on which to migrate documentation to. It would have Apache / PHP5 code and run code as generated by the various code repository that have doc/coverage enabled.
== Flow originating from webhost ==
{| class="wikitable"
! Proto !! source host !! source IP !! dest network !! dest Host !! dest IP !! dest port !! description
|-
| TCP || webhost || ??? || labs project || publisher || 10.68.16.255 || 873 || Jenkins job doing a <code>rsync</code> from Webhost to fetch material
|-
|}
== Flow going to webhost ==
{| class="wikitable"
! Proto !! source network !! source host !! source IP !! dest Host !! dest port !! description
How to do it from Tim L (from Sept 2015) https://lists.wikimedia.org/pipermail/wikitech-l/2015-September/083172.html :
{{quotation|1=
Untested, the change would be something like:
```
diff --git a/project.config b/project.config
index 151eebd..93291e1 100644
--- a/project.config
+++ b/project.config
@@ -12,6 +12,7 @@
owner = group ldap/ops
label-Code-Review = -2..+2 group Project Owners
label-Code-Review = -1..+1 group Registered Users
+ label-WIP = -1..+0 group Registered Users
create = group Project Owners
editTopicName = group Registered Users
viewDrafts = group JenkinsBot
@@ -78,6 +79,11 @@
value = +2 Looks good to me, approved
copyAllScoresOnTrivialRebase = true
copyAllScoresIfNoCodeChange = true
+[label "WIP"]
+ function = AnyWithBlock
+ value = -1 Work in progress
+ value = 0 Ready for reviews
+ copyMinScore = true
[access "refs/meta/dashboards/*"]
create = group Project Owners
create = group platform-engineering
```
}}
Related: <s>[https://phabricator.wikimedia.org/T52842 T52842: Add "Work in progress" button/status to Gerrit workflow to reduce dashboard noise]</s>
=== Endorsements (T135245) ===
#
=== Support (T135245) ===
#
== Add global logging context ==
{{tracked|T142313}}{{../buttons|task=T142313|title=Add global logging context}}
Certain kinds of information would be useful to have in the log context, but not possible or convenient to add manually. When such information is available from the log processing code, we use a Monolog processor to add it (e.g. IP, URL) but that's not always possible. For example, logging the canonical special page name would be handy but that's controller-level information and the log processing code has no access to the controller (and if it is logging an exception, the controller might be in some unexpected state).
The straightforward solution is to have some globally available temporary storage which application code can write into and log processing code can read from. (log4j calls this a [https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html diagnostic context].)
<syntaxhighlight lang="text">
20:28 < bd808> One feature that monolog is missing that I loved from log4j is a global diagnostic context. That's basically a thread local dict that any code can grab and stick key=value data into that then ends up in all log events
...
20:31 < bd808> at $DAYJOB-1 we tagged logs with lots of things as we found out about them in the app stack. customer id, databases used, services called, etc
...
20:37 < bd808> and we could expose it via LoggerFactory
20:39 < bd808> log4j (and some academic papers I can't find right now) call this thing a "diagnostic context" -- https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/MDC.html
== Small enhancements to current system of dumps ==
{{tracked|T155697}}{{../buttons|task=T155697|title=Small enhancements to current system of dumps}}
I know dumps are being re-written but it's taking several years so in the mean time, it would be great to have small enhancements (low hanging fruits) to the current system:
- Make it faster and nimble:
* Remove Yahoo! summaries: For example it's [https://dumps.wikimedia.org/wikidatawiki/20170101/ 38 GBs for Wikidata] and it slows down the whole process of generating dumps for all wikis. The Yahoo! itself is about to die and I don't know why we keep doing this.
* Keep one compression method and abandon the other. Why we build two dumps one for 7z and one for bz2?
- Notifications: I would love to receive an email once the monthly dump of Wikidata is done so I can run some checks and fix it on-wiki.
- UI. It's so 1990s. Please have something a little bit prettier.
=== Endorsements (T155697) ===
#
=== Support (T155697) ===
#
== mediawiki-extensions-qunit-jessie tests are failing ==
{{tracked|T153597}}{{../buttons|task=T153597|title=mediawiki-extensions-qunit-jessie tests are failing}}
'''Steps to reproduce'''<br>
* View this change https://gerrit.wikimedia.org/r/#/c/311463/ (it passed when it was merged but doing a recheck fails)
* See the failed test https://integration.wikimedia.org/ci/job/mediawiki-extensions-qunit-jessie/19388/console
'''Actual results'''<br>
* It is failing with
<syntaxhighlight lang="text">
16:56:04 18 12 2016 16:56:03.129:DEBUG [launcher]: Chrome (id 41038593) captured in 1.288 secs
<code>mediawiki-core-qunit-jessie</code> runs against mediawiki/core and has no dependencies beside <code>mediawiki/vendor</code>. The failing builds are:
{| class="wikitable"
!Time !! Gerrit !! Console !! Chromium
|-
| Dec 12 16:05 UTC || [https://gerrit.wikimedia.org/r/#/c/325049/13 | 325049/13] || [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/9842/console | 9842] || Chrome 53.0.2785
|-
| Dec 12 16:14:41 UTC || [https://gerrit.wikimedia.org/r/#/c/325049/14 | 325049/14] || [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/9843/console | 9843] || Chrome 53.0.2785
|-
| Dec 16 21:47:08 UTC || [https://gerrit.wikimedia.org/r/#/c/325049/15 | 325049/15] || [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/10154/console | 10154] || Chrome 55.0.2883
|-
|}
Note that Gerrit change 325049 hasn't been merged. I have rebuild 9842 twice (in Jenkins UI with the Rebuild link in the web interface) and it failed with the same error. So it seems those patches manage to reproduce the issue at hand.
I have triggered the build against the <code>master</code> branch and it passed three times [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/10304/console 10304] [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/10305/console 10305] [https://integration.wikimedia.org/ci/job/mediawiki-core-qunit-jessie/10306/console 10306].
=== Endorsements (T153597) ===
#
=== Support (T153597) ===
#
== MediaWiki support for Composer equivalent for JavaScript packages ==
{{tracked|T107561}}{{../buttons|task=T107561|title=MediaWiki support for Composer equivalent for JavaScript packages}}
We should have an equivalent for JavaScript to what we have with Composer for PHP. A simple way to manage dependencies and install required JavaScript modules automatically.
'''Problem'''<br>
# Both core and extensions depend upon 3rd party javascript libraries while we currently lack a system to manage those dependencies
# Instead, 3rd party libraries get duplicated into—and sometimes across—our repositories.
* Creates higher code complexity of our own repositories as 3rd party code—with all its flaws—is effectively part of our own code now
* High effort to manually updating those libraries by copy and paste
* Some libraries get effectively forked into our repositories while this is not necessary and makes updating/maintaining/reusing them even harder
* Conflict between MW coding conventions and the pasted libraries ones
'''Who will benefit'''<br>
# Developers: Development efficiency
* More predictable and maintainable code due to reduced code complexity
* Less worries about conflicts across different MW extensions and a simple way to share JS code between them
# Security: Simpler to keep an eye on security issues in 3rd party libraries and to deal with them
# Possibly, WMF Deployment team.
'''What we need'''<br>
# We need to settle on a system to track 3rd party javascript libraries. Something similar to ''composer.json'' or ''package.json'' or ''extension.json''
# We need to implement a way to make the selected system scalable and usable for both end users, developers and WMF deploymen
# (optional) deduplication of libraries
# (optional) predictability of versions used of libraries based on 1. (lock files, shrinkwrap).
# (optional) packaging download and update platform (npmjs etc)
'''Possible solutions'''<br>
# [https://yarnpkg.com Yarn] an NPM compatible client that combines benefits of composer (vendor dir, versioncontract/lock file, package deduplication etc).
# Plain NPM for external users and developer, And then build a WMF specific 'vendor' concept on top and other things we need. maybe some CDNJS like system perhaps ?
# Specify a structure for how to import libraries into our extensions (RL flag ?), so that it is more clear what we use, what versions they are etc.
# Turn JS libraries into composer packages.
=== Endorsements (T107561) ===
#
=== Support (T107561) ===
#
== Special:MobileLanguages should be in core and called Special:Languages ==
{{tracked|T104660}}{{../buttons|task=T104660|title=Special:MobileLanguages should be in core and called Special:Languages}}
The mobile skin minimises payload by not serving languages in the page and instead using JavaScript to load other languages or for those without JavaScript a special page fallback
The parameter given to the page is the page to retrieve languages from.
This should be in core in some form so it can be used by other skins.
This is one of many non-standard language selectors which need to be consolidated; see also <s>[https://phabricator.wikimedia.org/T73136 T73136: Improve language selection]</s>.
=== Endorsements (T104660) ===
#
=== Support (T104660) ===
#
== API's list=recentchanges should have rcrelated parameter (provide Special:RelatedChanges/Special:RecentChangesLinked functionality via API) ==
{{tracked|T17552}}{{../buttons|task=T17552|title=API's list=recentchanges should have rcrelated parameter (provide Special:RelatedChanges/Special:RecentChangesLinked functionality via API)}}
... to implement something akin to [[Special:RelatedChanges]].
--------------------------
'''Version''': 1.21.x
'''Severity''': enhancement
=== Endorsements (T17552) ===
#
=== Support (T17552) ===
#
== Consolidate the many tech events calendars in Phabricator's calendar ==
{{tracked|T1035}}{{../buttons|task=T1035|title=Consolidate the many tech events calendars in Phabricator's calendar}}
We have three problems related to calendars that need to be resolved, which are related but perhaps may be fixed separately, even at different points in time:
* '''Introducing calendar data'''. Now we are doing this in 1001 places. Ideally it would be just one place. The assumption of this task is that the one place would be Phabricator's calendar ([https://secure.phabricator.com/T7924 today a prototype]), but other candidates should be considered.
* '''Pulling calendar data in other supports, mainly wiki pages'''. While we could start linking from wiki pages to Phabricator calendar queries, the desired scenario would be a way for editors to embed calendars based on queries in wiki pages. This probably implies a Calendar API to query data ([https://secure.phabricator.com/T7944 which is missing]) and a MediaWiki extension allowing to embed those queried calendars in wiki pages (which we don't have). Maybe this is just too much, and at least the tech-inclined Wikimedians would be fine clicking a Phabricator link.
* '''Integrating calendar data with other systems (mainly Google Calendar)'''. "[https://secure.phabricator.com/T7929 Future work]" upstream, no plans today.
As we can see, deciding on Phabricator Calendar as the one place to introduce data would not provide a quick path to use that data out of Phabricator. However, what would be the alternatives? Other than defaulting to Google Calendar (which I think would be wrong as a matter of Wikimedia principles), I don't see a shortcut but others may have better ideas.
=== Phabricator Calendar in a nutshell ===
After playing a bit with https://phabricator.wikimedia.org/calendar/, I think the most practical option is to focus on having that calendar up to date, and then link to it from the right places in mediawiki.org.
* Entering events is simpler. The usual you can expect in a calendar application. There is no need to archive past events, since this is done automatically.
* Users can RSVP, getting notifications about the event and letting others know that they are attending.
* The calendars shown are the result of queries allowing for multiple parameters, including month view vs list, show only upcoming events, etc. These queries have static URLs.
* Events can be assigned to projects, which means that
** We could have projects for i.e. Tech Talks, Technical Office Hours, etc, people could subscribe to these projects and receive notifications when a new event is filed.
** By adding an event to existing related projects (i.e. [https://phabricator.wikimedia.org/tag/Web-APIs-hub #Web-APIs-hub], [https://phabricator.wikimedia.org/tag/Google-Summer-of-Code-2015 #Google-Summer-of-Code-2015]), users following that project would receive notifications as well.
** Queries can be fine tuned to show a specific set of events.
If we agree on this, the implementation would be relatively simple, since (at least in Wikimedia tech) a few people create most of the events. Redirecting from the current calendar pages to their equivalent Phabricator calendar queries should be enough to tell current users about these calendars about the new way to create new events.
==== Basic review of existing MediaWiki extensions ====
I went through https://www.mediawiki.org/wiki/Extension:Calendar (a linkhub for the ~12 different extensions or methods of integrating calendars with MediaWiki). There was no extension surviving a basic check against our needs. In fact, most of them are more than abandoned, and in general they focus on presentation, not on easy input, even less on semantic data (except the SemanticMediaWiki one, perhaps). [https://www.mediawiki.org/wiki/Extension:SimpleCalendar SimpleCalendar] looks like the only candidate if we would ever want to start from this point.
The reason for a lack of a proper MediaWiki Calendar extension may well be that MediaWiki was not designed to input calendar data, subscribe to events, etc.
After this short investigation, I still think that it is better to start from something other than MediaWiki, and the main candidate keeps being Phabricator. Then work separately in a way to import Phabricator Calendar data and present it in MediaWiki pages.
==== Background / previous description ====
https://www.mediawiki.org/wiki/Project:Calendar has a lot of room for improvement. Creating tasks is not trivial, and although the calendar can be watched and the entries appear in the mediawiki.org homepage, it doesn't have any of the features expected nowadays in an online calendar, i.e. integration with the calendar apps people use to organize their lives.
Also, for some low hanging fruit, a reporter explains in an email:
{{quotation|1=
the whole project:calendar page hierarchy is confusing - I would avoid subpages at more than one level deep
It's not clear to me why this page is in the Project: namespace to begin with
https://www.mediawiki.org/wiki/Project:Namespaces seems to suggest the Project: namespace is for "organization of mediawiki.org", which does not describe this page
see https://meta.wikimedia.org/wiki/Tech for a better way to provide consistent navigation/page structure across a set of dispersed pages without use of subpages you asked :)
}}
=== Endorsements (T1035) ===
#
=== Support (T1035) ===
#
== Implement a way to bring GitHub pull requests into gerrit ==
{{tracked|T37497}}{{../buttons|task=T37497|title=Implement a way to bring GitHub pull requests into gerrit}}
'''Author:''' <code>sumanah</code>
'''Description:'''<br>
First: Find the various GitHub mirrors of MediaWiki. Turn one into an up-to-date clone of our codebase.
Next, harder step: Make an interface to accept GitHub pull requests as merge requests in Gerrit, or do two-way syncing automatically via a bot.
Erik: "although I'm guessing that falls into the "hard" category, it could give us huge wins in terms of casual contribution.
Chad: "Yeah, that's definitely not straightforward--would need some careful thought to make sure we're doing it in a way that makes sense on our end too."
--------------------------
'''Version''': unspecified
'''Severity''': enhancement
=== Endorsements (T37497) ===
#
=== Support (T37497) ===
#
== Set $wgLegacyJavaScriptGlobals = false by default ==
{{tracked|T35837}}{{../buttons|task=T35837|title=Set $wgLegacyJavaScriptGlobals = false by default}}
Per [https://www.mediawiki.org/wiki/ResourceLoader/Migration_guide_(users)#wg.2A_Variables ResourceLoader Migration guide], there are plans to remove the global JavaScript variables (such as <code>wg*</code>).
I'm opening this bug (similar to <s>[https://phabricator.wikimedia.org/T35836 T35836: Set $wgIncludeLegacyJavaScript = false by default]</s>) mostly for tracking the progress on this regard.
If anyone knows if this is already scheduled to be done in some specific future version of MediaWiki, please inform us below.
--------------------------
'''Severity''': enhancement
'''See Also''':
* <s>[https://phabricator.wikimedia.org/T72366 T72366: Set $wgLegacyJavaScriptGlobals = false on ptwiki and ptwikibooks]</s>
=== Endorsements (T35837) ===
#
=== Support (T35837) ===
#
== Create an authoritative and well promoted catalog of Wikimedia tools ==
{{tracked|T115650}}{{../buttons|task=T115650|title=Create an authoritative and well promoted catalog of Wikimedia tools}}
Suggested by [https://phabricator.wikimedia.org/p/Qgil Qgil] at https://lists.wikimedia.org/pipermail/wikitech-l/2015-October/083580.html
Brief list of catalogs that have been suggested thus far:
'''See also''': <s>[https://phabricator.wikimedia.org/T1238 T1238: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets)]</s>
Per discussion in <s>[https://phabricator.wikimedia.org/T91190 T91190: When uploading a new patch, reviewers should be added automatically]</s>, it would be nice to enable [https://gerrit-documentation.storage.googleapis.com/Documentation/2.13/config-plugins.html#reviewers-by-blame reviewers-by-blame] which helps inexperienced developers find the right person for code review.
(I'm not sure what the roadmap is for Gerrit -> Phabricator migration - please decline if it's too close for Gerrit improvements to be worth the effort. Closest Phabricator equivalent I have found is [https://secure.phabricator.com/T1743 phabricator:T1743], still under development.)
=== Endorsements (T101131) ===
#
=== Support (T101131) ===
#
== A cached server-side HTML template doesn't update when you change a partial template which it includes. ==
{{tracked|T113095}}{{../buttons|task=T113095|title=A cached server-side HTML template doesn't update when you change a partial template which it includes.}}
https://gerrit.wikimedia.org/r/#/c/223165/ has a top-level template <code>Skin.mustache</code> that includes the partial template <code>sidebar.mustache</code> using
{{>sidebar}}
I notice on my local wiki if I edit <code>Skin.mustache</code> and view a page with the skin, I see the change to it (good!), but if I edit the partial <code>sidebar.mustache</code>, I don't see the change to it, even if I use ?action=purge (bug!).
Looking at <code>includes/TemplateParser.php</code> in core, it does a simple
<syntaxhighlight lang="text">
// Read the template file
$fileContents = file_get_contents( $filename );
// Generate a quick hash for cache invalidation
$fastHash = md5( $fileContents );
</syntaxhighlight>
this doesn't notice changes to partials included by $filename.
This is probably hard to fix. A workaround is to make cosmetic changes to all parent templates that include the edited partial template. I documented the bug and workaround in https://www.mediawiki.org/wiki/Manual:HTML_templates#Caching.
=== Endorsements (T113095) ===
#
=== Support (T113095) ===
#
== Document common low level site requests (namespace + logo changes, IP throttling expectations) for potential technical contributors and advertise those docs in tasks ==
{{tracked|T126330}}{{../buttons|task=T126330|title=Document common low level site requests (namespace + logo changes, IP throttling expectations) for potential technical contributors and advertise those docs in tasks}}
A good bunch of [https://phabricator.wikimedia.org/tag/Wikimedia-Site-Requests #Wikimedia-Site-Requests] items are pretty common / repetitive: Namespace translation changes, namespace additions, site logo changes, IP throttling exceptions for editathons etc.
Let's make sure they are documented ''for the patch writers'' (maybe they already are?) so [https://phabricator.wikimedia.org/p/aklapper aklapper] can link to such docs everytime [https://phabricator.wikimedia.org/p/aklapper aklapper] sees a request via his [https://git.wikimedia.org/log/wikimedia%2Fbugzilla%2Ftriagescripts.git Phabricator stock answers].
We don't want to burn out our existing contributors in this area like [https://phabricator.wikimedia.org/p/Dereckson Dereckson] etc. and we want to grow our technical contributor base.
Endlessly discussed and griped about but apparently there's no task.
This system is carelessly leaving behind a trail of maintenance overhead. With new issues popping up all the time. Here's a quick sample just from MediaWiki core (quick Resources.php search for "target" and "mobile").
* [https://phabricator.wikimedia.org/rMWc2d117b379ef588e8380dfd5f2b93a5a32fc22f5 rMWc2d117b379ef: Add mobile target to modules needed for mw.msg()]
* [https://phabricator.wikimedia.org/rMWa4fcb5914034ecee55b03f4e9560951f9ef58768 rMWa4fcb5914034: make jquery.json module run on mobile]
* [https://phabricator.wikimedia.org/rMW69d779cf352118467fcb479189670bb05d1caf80 rMW69d779cf3521: Add mobile target to QUnit and its dependencies]
* [https://phabricator.wikimedia.org/rMW50f46c678ef06e88a5382e096aa0116941df90f4 rMW50f46c678ef0: Add mobile target to jquery.getAttrs]
* [https://phabricator.wikimedia.org/rMW007acdc32b0d753c5ca957346fc5ac1c539586ed rMW007acdc32b0d: Add an explicit targets declaration for mediawiki.inspect & $.byteLength]
* [https://phabricator.wikimedia.org/rMW4726a3081a1e2c99b7fa591236bccb6e7a90a636 rMW4726a3081a1e: Add mobile as a target on VisualEditor dependencies.]
* [https://phabricator.wikimedia.org/rMW2947ba0244fcea5e42489a5fe2333c973a4f2f1b rMW2947ba0244fc: Use Agora oojs-ui theme on mobile]
* [https://phabricator.wikimedia.org/rMWe0897187b826f62b36c47ca961d9b1dd6328e2b4 rMWe0897187b826: Resources: Enable es5-shim and json for mobile as well as desktop target]
* [https://phabricator.wikimedia.org/rMWecc5f63a84013155656b37c27da917a02328dbfc rMWecc5f63a8401: Fix mediawiki.ui.checkbox loading in mobile]
* [https://phabricator.wikimedia.org/rMW21ec580f066566d7da97cca0ef40c112b6a0b7a1 rMW21ec580f0665: Load mediawiki.action.view.redirectToFragment in mobile]
* [https://phabricator.wikimedia.org/rMW017242816293ddab18c5aa0b5097f09471112f82 rMW017242816293: Allow mediawiki.cookie module to be used on mobile]
* [https://phabricator.wikimedia.org/rMW81c11be76e413aa53db2257abffbf976c728c582 rMW81c11be76e41: Allow mobile for jquery.throttle-debounce]
* [https://phabricator.wikimedia.org/rMWde0c7cb1c18039d51ce947dcd567010bde616bab rMWde0c7cb1c180: Allow usage of mediawiki.api.options on mobile]
* [https://phabricator.wikimedia.org/rMWfce27ff3285705ffd78e2746e6f5031f9b5528ec rMWfce27ff32857: Add mobile target for mediawiki.confirmCloseWindow]
* [https://phabricator.wikimedia.org/rMW67c1308ceeaa3b340a226f4ff0fb48b1f958e71c rMW67c1308ceeaa: Adding mobile target to mediawiki.template.mustache]
* [https://phabricator.wikimedia.org/rMW945eabb7883cc614b0edb899697f05d6a7f9ea62 rMW945eabb7883c: Add target mobile to jquery.textSelection]
* [https://phabricator.wikimedia.org/rMWe81b4e46a07596e3c7767311e7e766de03089363 rMWe81b4e46a075: mediawiki.ForeignApi: Module should target mobile]
* [https://phabricator.wikimedia.org/rMWb41781f08ea1cddf501deaff785c473b99c785fe rMWb41781f08ea1: Add 'mobile' target to 'mediawiki.raggett' module]
* [https://phabricator.wikimedia.org/rMW639cecb4bec8ac275d2c5eac089a124ccf96d7c4 rMW639cecb4bec8: Allow UserInputWidget on mobile]
** [https://phabricator.wikimedia.org/rMW80f1f08272ad4d5ebdc4e089041a22ee1c77f159 rMW80f1f08272ad: jquery.accessKeyLabel: Enable for target=mobile]
* <s>[https://phabricator.wikimedia.org/T67823 T67823: VisualEditor: [Regression pre-wmf7] Mobile VE doesn't load due to dependency on mediawiki.skinning.content.parsoid which is not available for mobile target]</s>
** [https://phabricator.wikimedia.org/rMW9cf7b5fee10fe93eaf630c843fd3177b5fd9d4ea rMW9cf7b5fee10f: Enable mediawiki.skinning.content.parsoid on Mobile target too]
* <s>[https://phabricator.wikimedia.org/T78069 T78069: JS is broken on mobile web]</s>
** [https://phabricator.wikimedia.org/rMW96180a49179b88ad563a6c3bb881dccf96fa0957 rMW96180a49179b: Allow moment on mobile web]
* <s>[https://phabricator.wikimedia.org/T93262 T93262: MobileFrontend doesn't do URL updating for redirects]</s>
** [https://phabricator.wikimedia.org/rMWf6bda94623d092d2fbd7b625e076da5353ebb9e4 rMWf6bda94623d0: Enable mediawiki.action.view.redirect on mobile]
** [https://phabricator.wikimedia.org/rMW92592631ecb308f814b976f068cad176699f8716 rMW92592631ecb3: mediawiki.api: Include 'mobile' target in mediawiki.api.parse module]
* <s>[https://phabricator.wikimedia.org/T108191 T108191: Mobile site not functional - Uncaught Error: Unknown dependency: mediawiki.legacy.wikibits]</s>
** [https://phabricator.wikimedia.org/rMW0dadc3972be20014caad20fd0461a485c5167589 rMW0dadc3972be2: Add 'targets=desktop,mobile' to mediawiki.legacy.wikibits module]
* <s>[https://phabricator.wikimedia.org/T63861 T63861: VisualEditor: Show something other than a blank page when editing a redirect page]</s>
** [https://phabricator.wikimedia.org/rMW848eabef42e9be7f512aabdcc0d6ff5280e2fb94 rMW848eabef42e9: Make mediawiki.action.view.redirectPage available on mobile]
* <s>[https://phabricator.wikimedia.org/T126935 T126935: Redirects are not italicized on mobile Special:PrefixIndex/User:... page]</s>
** [https://phabricator.wikimedia.org/rMW46cabd425225d53c6ff08d3b41a2f619a84f1617 rMW46cabd425225: Add mobile target to mediawiki.special]
=== Endorsements (T127268) ===
#
=== Support (T127268) ===
#
== Organize a Wikimedia developer contest to recognize and promote best projects ==
{{tracked|T147545}}{{../buttons|task=T147545|title=Organize a Wikimedia developer contest to recognize and promote best projects}}
This is a known model: organizing a developer contest in order to find great projects and the great people behind them. Do we have any precedent in Wikimedia?
This is a proposal targeting the Technical Collaboration annual plan FY2017-18. We would need to be in sync with the rest of Community Engagement, Product, and Comms. If you like the idea, let's plan for it and let's request the necessary budget.
How this could work:
* Being the first edition, the requirement would be to just be a stable and active project during 2016. In future edition we might want to restrict eligibility for new projects only, if there are enough of them.
* We could have different categories:
** Projects using Wikimedia APIs (one option would be to start small only with this category, then grow other categories if needed in future editions).
** Extensions
** Gadgets
** Bots
** Templates
** Skins
* The criteria to select winners could be a combination of qualitative factors (innovation, originality, usefulness...) and popularity. A jury would be in charge of the selection.
* Potential prizes:
** Organization of a small hackathon or workshop with the winner and a selection of developers, UX designers and users to improve the project and get new ideas.
** Invitation to the Wikimedia Hackathon / Summit / Wikimania with some extra spice (i.e. some days of leisure and you can invite a partner).
** Invitation to a special activity organized by a Wikimedia partner e.g. a workshop at the Internet Archive, a guided tour to NASA premises, an activity by any GLAM institution... also with some extra leisure spice for the winner and one partner.
** Of course media coverage in the form of press release, blog post, promotional video...
=== Endorsements (T147545) ===
#
=== Support (T147545) ===
#
== Add support for a wmf-ci.yaml type file for wikimedia jenkins ==
{{tracked|T145669}}{{../buttons|task=T145669|title=Add support for a wmf-ci.yaml type file for wikimedia jenkins}}
= Problem =
Continuous Integration is hard to set up for repositories in the Wikimedia environment. Often this will require changes to the <code>integration/config</code> repo (e.g. editing a huge YAML file) and whitelisting of users (who may otherwise be unable to trigger some Jenkins jobs via Gerrit).
= Proposed solution =
Travis CI ''et similia'' only require a simple YAML file in the root directory of each code repository. Supporting such model can greatly streamline the addition of CI to repositories managed by small volunteer teams, decrease reliance on third-party services and ease the work of the few employees dedicated to CI infrastructure.
----
I discussed this on [https://phabricator.wikimedia.org/tag/wikimedia-releng #wikimedia-releng] and [https://phabricator.wikimedia.org/p/mmodell mmodell] thought it was a nice idea, he is the one who came up with the name for the file. But this will help us customize it per repo without needing to create a separate job.
<twentyafterfour> paladox: it would be cool to do something similar to travis, with a test config file, indeed.
What we will do is have a major improvement over .travis-ci which will allow us to define multiple tests at the same time instead of being limited to 1.
An example on how it will look
<syntaxhighlight lang="text">
project:
- name: hi
- php:
- 7
- 5.6
- 5.5
- 5.4
- 5.3
- hhvm
script:
- composer test
</syntaxhighlight>
This is a mock and will need improvements to support extending our tests without making it complex.
=== Endorsements (T145669) ===
#
=== Support (T145669) ===
#
== When a project has no workboards enabled, many clicks are required to open the task list of that project ==
{{tracked|T127903}}{{../buttons|task=T127903|title=When a project has no workboards enabled, many clicks are required to open the task list of that project}}
I used to be able to click a tag, click "open tasks" on the sidebar and see a list of open reports for that project. (<s>[https://phabricator.wikimedia.org/T89865 T89865: Phabricator project page should not default to workboard]</s> made that slower but still feasible, at least for people with good enough CPUs and networking.) Nowadays, I have no idea how to reach the same result in less than 10 clicks or so: can someone point out a way? Thanks.
'''Upstream task (with potential Phabricator extension code):''' [https://secure.phabricator.com/T10308#158036 <s>[https://phabricator.wikimedia.org/T10308 T10308: Should be an option to delete redirect when moving pages]</s> Please undo some changes]
=== Endorsements (T127903) ===
#
=== Support (T127903) ===
#
== Add a welcome bot to Differential for first time contributors ==
{{tracked|T135186}}{{../buttons|task=T135186|title=Add a welcome bot to Differential for first time contributors}}
See also - [https://phabricator.wikimedia.org/T73357 T73357: Add a welcome bot to Gerrit for first time contributors]
OpenStack is using this bot for Gerrit: https://github.com/openstack-infra/jeepyb/blob/master/jeepyb/cmd/welcome_message.py
=== Endorsements (T135186) ===
#
=== Support (T135186) ===
#
== Use Sentry in production ==
{{tracked|T106915}}{{../buttons|task=T106915|title=Use Sentry in production}}
Noticing, tracking and debugging errors should be easy. A Wikimedia developers and users should be able to easily notice new errors (possibly only a subset of them that they are interested in), find out details, and share with others. At the same time security and privacy standards should be enforced.
https://getsentry.com/
=== Endorsements (T106915) ===
#
=== Support (T106915) ===
#
== [MediaWiki-commits] Reverts are not notified by gerrit ==
{{tracked|T49252}}{{../buttons|task=T49252|title=[MediaWiki-commits] Reverts are not notified by gerrit}}
New changesets which are reverts, and the respective comment on the reverted change, are not announced on mailing list; the merge of the revert is.
This finds nothing: <http://markmail.org/search/?q=%22This%20patchset%20was%20reverted%20in%20change%22%20list%3Aorg.wikimedia>
508 mentions of reverts: <http://markmail.org/search/?q=%22Change+subject%3A+Revert%22+list%3Aorg.wikimedia.lists.mediawiki-cvs#query:%22Change%20subject%3A%20Revert%22%20list%3Aorg.wikimedia.lists.mediawiki-cvs>
394 of which seem to be merges: <http://markmail.org/search/?q=%22Change+subject%3A+Revert%22+%22has+submitted+this+change+and+it+was+merged%22+list%3Aorg.wikimedia.lists.mediawiki-cvs>
--------------------------
'''Version''': unspecified
'''Severity''': normal
=== Endorsements (T49252) ===
#
=== Support (T49252) ===
#
== Run a documentation sprint for Labs ==
{{tracked|T101659}}{{../buttons|task=T101659|title=Run a documentation sprint for Labs}}
Currently documentation is way too out of date and inconsistent. Setup a weeklong sprint with specific tasks to fix documentation, and run the weeklong sprint, with help from Admins and volunteers.
Should involve both general labs and tool labs.
'''See also:'''<br>
* [https://phabricator.wikimedia.org/T126500 T126500: Organize a MediaWiki Documentation Day (similar to the Gerrit Cleanup Day)]
=== Endorsements (T101659) ===
#
=== Support (T101659) ===
#
== [jsduck] Various custom tags should be easily shareable between projects ==
{{tracked|T86587}}{{../buttons|task=T86587|title=[jsduck] Various custom tags should be easily shareable between projects}}
Recently we introduced the jsduck [https://phabricator.wikimedia.org/p/see see] tag in MobileFrontend [1], which isn't part of the vanilla jsduck. Actually we need to add a customTag our self [2] to use it without warnings from jsduck. The feature request for jsduck [3] isn't implemented at the moment and there is no roadmap for it (as i can see).
VisualEditor itself (like mentioned by [https://phabricator.wikimedia.org/p/Krinkle Krinkle] on the feature request) uses a set of custom tags [4] and there are other projects using this (and other) custom tag(s), too (core, VE and GuidedTours). It would be possible to use cores CustomTags.rb in jsduck, but with it it wouldn't be easy to share custom tags introduced in VE or MF, e.g.. So it would be great to have a central repository (e.g. a git project in gerrit) to manage tags used in wmf projects to simply clone it (maybe integrate it as a submodule) into the project (or a seperate directory) and use it. An update of a tag or new tags could be used without any problems by updating the local copy of the repo.
== Phabricator silently overwrites changes (no mid-air collision/conflict detection) ==
{{tracked|T78236}}{{../buttons|task=T78236|title=Phabricator silently overwrites changes (no mid-air collision/conflict detection)}}
Upstream task for Phriction and Maniphest: https://secure.phabricator.com/T4768
It looks like Phabricator may be unintentionally removing CCs when a comment is submitted shortly after a person subscribes? This is pretty worrying.
Examples: [https://phabricator.wikimedia.org/T77611 T77611: Investigate Erik's ideas about why enwiki is not equivalent to other wikis], <s>[https://phabricator.wikimedia.org/T78116 T78116: 503 Varnish error when adding template to a page on Commons.]</s>, [https://phabricator.wikimedia.org/T78607 T78607: Update from 1.19 to 1.23 fails: Error: 1054 Unknown column 'page_content_model' in 'field list'.], <s>[https://phabricator.wikimedia.org/T85196 T85196: Checkuser results should update usernames after a user is renamed]</s>
Issues with subscribers additions: [https://phabricator.wikimedia.org/T96464 T96464: Upon edit, a task description which mentions a Phab user (re)adds that Phab user to CC/Subscribers field], <s>[https://phabricator.wikimedia.org/T913 T913: Adding subscribers to a Phabricator task should be more lightweight]</s>.
=== Endorsements (T78236) ===
#
=== Support (T78236) ===
#
== meta=siteinfo should allow client to identify RTL languages ==
{{tracked|T74153}}{{../buttons|task=T74153|title=meta=siteinfo should allow client to identify RTL languages}}
== Announce all creations, deletions and renaming of gerrit repos (for e.g. translatewiki.net workflow) ==
{{tracked|T48982}}{{../buttons|task=T48982|title=Announce all creations, deletions and renaming of gerrit repos (for e.g. translatewiki.net workflow)}}
Creation, deletion and renaming of Gerrit repositories regularly has a very negative impact on the translatewiki.net workflow.
Recently the repo DonationEmailUnsubscribe appears to have been deleted. The repo FundraisingEmailUnsubscribe appears to have been moved from wikimedia to mediawiki, without updating the permissions on the repo, and without updating .gitreview.
Deleting repos causes errors in mass update scripts. They will exit with inexplicable errors, which then means that you have to start chasing ghosts in https://gerrit.wikimedia.org/r/#/admin/projects/
--------------------------
'''Version''': wmf-deployment
'''Severity''': major
=== Endorsements (T48982) ===
#
=== Support (T48982) ===
#
== Define the architecture areas for MediaWiki core and platform extensions ==
{{tracked|T1287}}{{../buttons|task=T1287|title=Define the architecture areas for MediaWiki core and platform extensions}}
We really miss a high level architecture overview of MediaWiki core and platform extensions (the ones that provide APIs and enable user features). Reasons to have one:
* MediaWiki and relatives form a very complex family. https://www.mediawiki.org/wiki/Developers/Maintainers lists 210 components only for core, and there is no subdivision to be seen. Without a shared high level map it is a lot more complex to have shared high level discussions and plans.
* New potential contributors need an overview to understand the basics of MediaWiki and find the area where they want to work on. Such diagram would be really helpful to identify an area as a starting point. After many conversations with many newcomers with different skill levels, we know that most of them get simply lost / overwhelmed in their first contact.
* Defining areas is a premise required to discuss whether we want to have architects / owners / maintainers for a specific area that would work with the [https://phabricator.wikimedia.org/tag/ArchCom #ArchCom] or be part of it.
How a v0.1 could look like:
'''MediaWiki Core'''<br>
* Configuration
* Database
* i18n/L10n
* Parser
* Skins
* Media
* API
* ...
'''Platform extensions'''<br>
* Parsoid
* ...
=== Endorsements (T1287) ===
#
=== Support (T1287) ===
#
== Phabricator is unfriendly to assistive technology ==
{{tracked|T109}}{{../buttons|task=T109|title=Phabricator is unfriendly to assistive technology}}
Nothing ''ever'' shows on cursor hover, and none of the popular images (avatars, Phabricator logo, edit menu buttons) include the "alt" attribute.
Actually, the pictures all seem to be added through CSS (as part of background for div, span, and similar tags), which is very bad for screen readers and similar software (IIRC).
=== Endorsements (T109) ===
#
=== Support (T109) ===
#
== Free-form tagging in gerrit ==
{{tracked|T37534}}{{../buttons|task=T37534|title=Free-form tagging in gerrit}}
As with [https://www.mediawiki.org/wiki/Extension:CodeReview CodeReview], to organize work.
== Phabricator should suggest possible duplicates when creating a new task ==
{{tracked|T45}}{{../buttons|task=T45|title=Phabricator should suggest possible duplicates when creating a new task}}
When you create a new bug report in Bugzilla, you get a list of possible duplicates. I find it useful. It might be even more useful for new users filing what is going to be probably an obvious duplicate.
I am missing a way to disable the "Notify" when a task was getting a token.
In the Email Preferences under https://phabricator.wikimedia.org/settings/panel/emailpreferences/ I have not found a way to disable this. I did not need tokens and therefore no notify if a subscribed task get a token.
=== Endorsements (T91289) ===
#
=== Support (T91289) ===
#
== Email notifications should bundle events as the web interface does ==
{{tracked|T85305}}{{../buttons|task=T85305|title=Email notifications should bundle events as the web interface does}}
As a user with limited email digesting capabilities*, I want phabricator to make some basic digesting on my stead, so that I'm not overwhelmed; and to have a consistent behaviour across web interface and emails, so that I'm not confused.
I. Observed: the web interface bundles/digests/collates tightly connected events by a single user under a single header/timestamp, e.g. https://phabricator.wikimedia.org/T85304#943638 . The emails instead show separately the actions which were made separately. Not only the additional emails are annoying, but whether some actions were made together or in multiple steps is totally irrelevant for me as a subscriber, to the point they're often impossible to verify in the web interface (because not displayed).
II. Expected: a single email should be sent for all the events which the web interface bundles together. A delay in sending the email notifications may be added, if needed for this purpose.
(*) Note: I don't fall in this category so I don't have a COI in filing this task.
=== Endorsements (T85305) ===
#
=== Support (T85305) ===
#
== Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites ==
{{tracked|T71445}}{{../buttons|task=T71445|title=Implement a sane code-review process for MediaWiki JS/CSS pages on Wikimedia sites}}
MediaWiki: CSS/JS pages on any non-large wiki are usually a mess. Occasionally, we'll discover that wikis have been loading external resources for months and no one noticed. In addition, the local sysops maintaining those pages usually don't know JavaScript and are copy-pasting what someone else told them to do.
Various proposals have floated around over the years. The wikitech-l threads have some good discussion on some of the reasons why this is difficult for smaller wikis.
* Wikitech-l:
* [http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/74283 No longer allow gadgets to be turned on by default for all users on Wikimedia sites] (specifically about Gadgets though)
* [http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/79080/ Deployment targets and preferences (was: Superprotect user right, Comming to a wiki near you)]
* Wikimedia-l:
** [http://thread.gmane.org/gmane.org.wikimedia.foundation/74166 Next steps regarding WMF<->community disputes about deployments]
** [http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/79055/ Superprotect user right, Comming to a wiki near you]
I'm mainly filing this in response to [http://lists.wikimedia.org/pipermail/wikimedia-l/2014-August/073767.html Erik's email about "superprotect"] in which he says we want to move forward to a code review process. I disagree with his statement that "the system works as it is". Code with [https://szl.wikipedia.org/w/index.php?title=MediaWiki%3ACommon.js&diff=prev&oldid=208782 obvious syntax errors] should never be sent to readers.
'''See Also''':
* [https://phabricator.wikimedia.org/T39230 T39230: Provide standard way to create/run QUnit tests for Gadgets and user scripts] (bug 37230)
* [https://phabricator.wikimedia.org/T53651 T53651: Auto-generated gadget documentation with JsDuck] (bug 51651)
* [https://phabricator.wikimedia.org/T71550 T71550: Move code in enwiki MediaWiki:Common.js and Gadgets to MediaWiki software]
* <s>[https://phabricator.wikimedia.org/T1238 T1238: Central Code Repository for code used on wikis (Templates, Lua modules, Gadgets)]</s>
=== Endorsements (T71445) ===
#
=== Support (T71445) ===
#
== Support a responsive grid system ==
{{tracked|T90687}}{{../buttons|task=T90687|title=Support a responsive grid system}}
In order to consistently accommodate multiple screen sizes we need a responsive grid system.
We had an [https://www.mediawiki.org/wiki/Requests_for_comment/Grid_system RFC] and [https://gerrit.wikimedia.org/r/#/c/125387/ an initial implementation] that needs some polishing. Additional work may be needed to make sure it works well with OOjs-UI components.
=== Endorsements (T90687) ===
#
=== Support (T90687) ===
#
== Add a welcome bot to Gerrit for first time contributors ==
{{tracked|T73357}}{{../buttons|task=T73357|title=Add a welcome bot to Gerrit for first time contributors}}
Something akin to https://review.openstack.org/#/c/124398/ - The "Welcome, new contributor!" message is quite a nice touch
-----
'''See Also:''' [https://phabricator.wikimedia.org/T64324 T64324: Visually indicate when a Phabricator user is new (Welcome culture)]
=== Endorsements (T73357) ===
#
=== Support (T73357) ===
#
== Remove all PHP entry points from all Wikimedia-deployed extensions and skins ==
{{tracked|T140850}}{{../buttons|task=T140850|title=Remove all PHP entry points from all Wikimedia-deployed extensions and skins}}
Once all Wikimedia-deployed extensions and skins have been switched over to extension registration, and Wikimedia production has switched over to using them, we should remove the backwards-compatibility shims that very often imply support which doesn't exist for older versions of MediaWiki.
=== Endorsements (T140850) ===
#
=== Support (T140850) ===
#
== Duplicate tasks are not listed in or near the description of the target task ==
{{tracked|T883}}{{../buttons|task=T883|title=Duplicate tasks are not listed in or near the description of the target task}}
As a user, I want to have a list of tasks currently marked as merged to the one I'm reading, so that I know what are the tasks currently marked as merged to the one I'm reading.
----
The description of <s>[https://phabricator.wikimedia.org/T857 T857: Imported bugs from bugzilla should be assigned the same number as their bugzilla ID (i.e. Bug 1 -> Task 1; Bug 2007 -> Task 2007)]</s> has no mention of the fact <s>[https://phabricator.wikimedia.org/T625 T625: Bug 1 be bug 1]</s> was merged into it.
The fact should be noted:
* in or around the description, with a list of all merged tasks (as with blocking tasks);
* in the history of actions/comments [this is currently satisfied, but hard to find].
=== Endorsements (T883) ===
#
=== Support (T883) ===
#
== Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator ==
{{tracked|T687}}{{../buttons|task=T687|title=Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator}}
In comments, [Bb]ug #?<N> should be parsed as T<N+2000>: that is, "bug 323" would be rendered as [https://phabricator.wikimedia.org/T2323 T2323: edits where the rev_user_text and ar_user_text fields contain underscores, initial lower-case letters or consecutive spaces, which could occur in the Phase I and II software, are inaccessible using Special:Contributions]; or converted to "bug 323 ([https://phabricator.wikimedia.org/T2323 T2323: edits where the rev_user_text and ar_user_text fields contain underscores, initial lower-case letters or consecutive spaces, which could occur in the Phase I and II software, are inaccessible using Special:Contributions])". Ideally, the full bugzilla syntax would be parsed/converted, see https://bzr.mozilla.org/bugzilla/4.4/view/head:/Bugzilla/Template.pm#L234
@Chasemp: For sentences imported from Bugzilla tickets in comments like
'''* Bug 12345 has been marked as a duplicate of this bug. *'''<br>
(yes, those are three stars at the start of the line turned into a bullet point, meh, another cosmetic thingy)
I know that some folks like to look at duplicates because they might provide more information about a bug and clicking instead of manual copy and paste fiddling sounds easier...
>>! In [https://phabricator.wikimedia.org/T687#1140536 T687: Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator], [https://phabricator.wikimedia.org/p/chasemp chasemp] wrote:
>>>! In [https://phabricator.wikimedia.org/T687#1140427 T687: Convert Bugzilla's "Bug NNNNN" links to "TNNNNN" links in Phabricator], [https://phabricator.wikimedia.org/p/Aklapper Aklapper] wrote:
{{quotation|1=
{{quotation|1=
@chasemp: If a volunteer (or me) wanted to work on this, what would be needed? Write code with regexes and set up a bot for it?
Could a volunteer work on this task (or if not fully, how much of this task)?
}}
I'm not sure how the bot fits in, but I am also thinking of this as a historical one-time fixup. I never had any plans for an ongoing translator. This is a straight mysql job in the first case which means simpler and more dangerous :)
This really doesn't require me / privs to ''write'' the job, only to validate / run it. It could easily be worked on on phab-01 or whatever.
The off-the-cuff break down to achieve this for
'''comments:'''<br>
1. Find all issues that were historically BZ using the custom reference field
2. use the task PHID to find all comment type transactions
3. use the comment transaction to find the actual comment itself
4. retrieve the comment content from the db (assuming we only want to mangle comments from before migration)
5. Run some kind of transform on the content (regex based changing Bug: Foo to Bug: Bar or whatever), and write the output back as the content.
6. Repeat for every comment on every BZ imported task
7. Wipe remarkup cache
'''descriptions'''<br>
1. Find all issues that were historically BZ using custom reference field
2. retrieve the task desription (is this stored as a transaction now or not, I'm not sure anymore?)
3. Perform same regexy type logic as above and update description
4. Repeat for every task from BZ
5. Wipe remarkup cache
The good news is a basic framework for this would handle all cases, and it's not too hard to write this, just very time consuming to make sure it's not doing something awkward and untoward.
}}
=== Endorsements (T687) ===
#
=== Support (T687) ===
#
== Allow to search tasks about MediaWiki core and core only (create MediaWiki umbrella project?) ==
{{tracked|T76942}}{{../buttons|task=T76942|title=Allow to search tasks about MediaWiki core and core only (create MediaWiki umbrella project?)}}
As a user looking for a report about a MediaWiki core bug, I want to quickly look for it without bothering about non-core reports or specific components/projects, so that I find what I'm looking for before I give up out of desperation.
----
Currently, I must type N MediaWiki core projects manually in the "Projects" field. (Cf. https://secure.phabricator.com/T3670#65849, first bullet.)