Fri, Mar 16
This is required by WCAG 2.0 SC 2.2.2: "For any moving, blinking or scrolling information that (1) starts automatically, (2) lasts more than five seconds, and (3) is presented in parallel with other content, there is a mechanism for the user to pause, stop, or hide it unless the movement, blinking, or scrolling is part of an activity where it is essential"
WCAG 2.0 SC 1.1.1 requires non-text CAPTCHAs to have "alternative forms of CAPTCHA using output modes for different types of sensory perception are provided to accommodate different disabilities"
Wed, Mar 14
The relevant WCAG 2.0 success criterion is SC 2.4.1 Bypass Blocks: "A mechanism is available to bypass blocks of content that are repeated on multiple Web pages. (Level A) "
WCAG 2.0 SC 2.4.9 Link Purpose (Link Only): "A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general. (Level AAA) "
If the icon is conveying information then it is a violation of WCAG 2.0 SC 1.1.1 "Non-text Content" if we do not provide a text equivalent. The only way out of this is to claim that it is "pure decoration", which I don't think is true.
I think the existing behaviour is OK under WCAG 2.0 SC 1.3.1 since the same information is available in the <title> and <h1>.
The title attribute only contains the name of the page, which is the same in every case, it doesn't contain the heading or anchor. Improving the title attribute would satisfy WCAG 2.0 SC 2.4.9, although begrudgingly, since note H33 recommends using CSS to hide part of the link text instead, due to "extensive user agent limitations" with the title attribute.
Whether this is a WCAG 2.0 Level A or Level AAA conformance issue depends on whether you think the link purpose can be determined from the "programmatically determined link context", which includes other links in the same list. I think the answer is probably yes, so it's only Level AAA SC 2.4.9 "Link Purpose (Link Only): A mechanism is available to allow the purpose of each link to be identified from link text alone, except where the purpose of the link would be ambiguous to users in general."
This is not a WCAG 2.0 issue since there is a text alternative by WCAG's definition of the term.
The existing behaviour violates WCAG 2.0 SC 2.2.1 Timing Adjustable (Level A). Allowing the user to disable auto-hide in preferences would satisfy SC 2.2.1 but would probably not be Level AAA compliant due to SC 2.2.3 "No Timing".
This is really usability rather than accessibility.
The checkboxes in the Notifications tab of Special:Preferences, from the Echo extension, appear to violate WCAG 2.0 SC 1.1.1 (Level A). I don't see any label for those checkboxes, not even an empty label. Each checkbox needs to have a human-readable name that describes its purpose. Presumably that means the "web" and "email" checkboxes on each row need to have different names. An aria-label attribute would be sufficient.
Not required by WCAG 2.0
This is a violation of WCAG 2.0 SC 1.3.1: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)
WCAG 2.0 SC 2.1.2 No Keyboard Trap (Level A)
The only WCAG 2.0 violation that I see in here is "The file size textfields for the size are not labelled". This violates SC 1.1.1 "If non-text content is a control or accepts user input, then it has a name that describes its purpose." (Level A)
This is not a WCAG violation if there are no callers that use this.
This is probably a WCAG 2.0 SC 2.1.1 conformance failure. You can type the language name, but if "suggested languages" counts as functionality then it's a violation to not give keyboard access to it.
This is a violation of WCAG 2.0 Level AA 2.4.7 Focus Visible: Any keyboard operable user interface has a mode of operation where the keyboard focus indicator is visible.
Based on the screenshot, this is a failure of WCAG 2.0 Level A guideline 1.4.1 "Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element."
Not a WCAG 2.0 violation in my opinion, on the basis that the logo is pure decoration. It is deliberately hidden from screen readers.
Tue, Mar 13
Mon, Mar 12
So we need a Greenhouse admin to go to Configure > Email Settings, then enter "careers.wikimedia.org" for the domain and click "Register". Then click "Email your I.T. dept" and send it to firstname.lastname@example.org.
Fri, Mar 9
To get a bit more philosophical, my theory is that improving and encouraging communication of the rationale for an edit will help to avoid conflict and anger.
Proof-of-concept display-side truncation uploaded at https://gerrit.wikimedia.org/r/#/c/417593/
I think 500 is too long for change lists, I think it should be more like 150. When you require the same length for storage and display, you have to make awkward trade-offs. Edit summaries on Wikipedia are usually much shorter than 500 characters, whereas commit messages in MW git are very often longer than 500 characters. I don't think MediaWiki is fundamentally more complicated than a Wikipedia article, I think Wikipedians are just accustomed to not explaining what they are doing, due to UI decisions by developers.
My preference is to leave the limit as it is, and to collapse or truncate edit summaries in the change list UI. There's no reason to limit the size on the diff page.
Thu, Mar 8
How about I change the task title so that it can stay open? Because the real problem here is that outbound email is broken, I don't care whether SPF or a subdomain is used to fix it. There's no MX record for careers.wikimedia.org.
Wed, Mar 7
Tue, Mar 6
Sanitizer is in fact not involved. The Parser wraps the TOC with <mw:toc>...</mw:toc>. The input to Tidy is:
Thu, Mar 1
This comes from pybal monitoring. The client IP addresses identify LVS hosts, and you can see the relevant requests using tcpdump. I tried to reproduce using nc, which was mostly unsuccessful, except for one request to http://fr.wikipedia.org/wiki/Special:BlankPage .
Wed, Feb 28
Fix uploaded at https://gerrit.wikimedia.org/r/#/c/415207/ . Any objections to removing the policy? This is not a DOS attack. It's apparently not even a DOS attack vector, since the memory limit is doing its job, and the CPU time is short.
Wed, Feb 21
The issue is that some GET requests will be routed to the secondary data centre. Eliminating all writes in such requests is not feasible and was abandoned as a goal very early in the planning. Instead, when MW calls wfGetDB(DB_MASTER) from the secondary datacentre, it will connect to the remote master database. This takes about 6 RTTs per SSL connection plus 1 RTT per query. So avoiding such queries is useful for performance.
I'm not sure this needs to be done, since it is already deferred until post-send so should not have any impact on user-visible latency.
It looks like this is deferred until post-send, so there shouldn't be a user-visible latency impact. I'm assuming we're talking about LocalFile::maybeUpgradeRow().
The call of ArticleCompileProcessor::compileMetadata() from from ArticleMetadata::getMetadata() is supposedly a "very rare case" according to a source code comment. It's incorrect in this case to do BasicData compilation from the master. ArticleMetadata::getMetadata() has just loaded the page information from the replica, so it knows all the data is already in the replica. It should override the componentDb config so that all data comes from the replica. Note that the backtrace shows this information being prepared for the footer of a page view. Page views use existence information from the replica DB, so if you loaded PageTriage data from the master, the best you could do would be to display a triage footer on a "page does not exist" error message.
So this only affects users with user_token=''? The field is not nullable. Apparently only users created between March and June 2012 are affected by this:
I revision-deleted the revision in question.
Tue, Feb 20
It's not a DOS, there's not enough requests. It's just a broken bot hitting the same old revision via action=parse again and again. Specifically 256170852, a revision of [[Barack Obama]] from 2008. The solution is to find the person running this bot and to tell them to stop doing it.
There's no longer a 512MB limit imposed by wfShellExec(). Monitoring bytecode cache size may be useful if there is a risk of disk space exhaustion or performance degradation, but this is no longer necessary for T146285, so I'm removing it as a parent and reducing priority. Possibly the task could be declined if we switch mwscript back to HHVM and no issues are encountered.
Mon, Feb 19
Feb 15 2018
Feb 8 2018
This is on our workboard and Q3 goal list but https://wikifarm.wmflabs.org/mcr/index.php/Main_Page has it assigned to Adam, I assume that is @Addshore. Is it OK to assign this task?
Feb 7 2018
January 31 meeting notes: https://tools.wmflabs.org/meetbot/wikimedia-office/2018/wikimedia-office.2018-01-31-22.00.html
Feb 5 2018
I don't think there's any need to handle it as a security release when there's no demonstrated vulnerability. I think the patches on this bug should be published on Gerrit. In any case, I've reviewed them and they look fine to me. I was a bit concerned as to whether the timing resolution thing is overly paranoid, but I suppose it is OK.
Feb 1 2018
Why do you need the scanned page to migrate wikitext to the new parser? You have the old parser output, which should match the scan well enough. With three columns, it would be very wide.
The history page is simpler since there is at most one rollback link per page. A rollback button embedded in the current revision row would suffice, at least as a non-JS fallback.
The dropdown could have "rollback" selected by default. Since there is a single confirmation page for bulk rollbacks, it would be possible to provide a button to undo the bulk rollback, improving the feeling of safety and thus the justification for "rollback" as default. Rollback certainly makes sense as the default for users without access to other bulk actions.
I suggest modifying the contributions page as follows:
Jan 31 2018
Per testing on deployment-prep:
Jan 30 2018
Jan 29 2018
Jan 26 2018
I don't think the derived slots idea made it into the current MCR plan. @daniel can confirm.
Jan 24 2018
Jan 23 2018
Jan 12 2018
Jan 9 2018
Jan 3 2018
Jan 1 2018
The thing that has been approved is in the task description section labelled "Current proposal". Some time before April 2018, we will migrate remaining uses of PHP 5.x in WMF production to either PHP 7 or HHVM. Then, we will update the version requirements in MW core master, before the release of MW 1.31.
Dec 13 2017
This is now moving to last call after a TC discussion.
Dec 12 2017
One alternative is to use the reference form of foreach:
Dec 8 2017
Incredible how a single line of rubbish code I wrote in 2004 can have so many people scratching their heads for so long. I hadn't seen this task before today.
The fix is merged, and searching logstash for SiteConfiguration shows no further errors of this type.
Dec 7 2017
Dec 4 2017
Nov 30 2017
Nov 29 2017
ll_lang is actually the interwiki prefix, it's written by LinksUpdate based on what's currently in the wikitext on the page in question, you can't just change it in the database. You'd have to change it on every page with an explicit (non-Wikidata) language link to nowiki.