Page MenuHomePhabricator

Risker (Risker)
Community member

Projects

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Sunday

  • Clear sailing ahead.

User Details

User Since
Oct 14 2014, 8:03 PM (529 w, 2 d)
Availability
Available
IRC Nick
Risker
LDAP User
Unknown
MediaWiki User
Risker [ Global Accounts ]

I wear several hats. I am an active editor, administrator, checkuser and oversighter on English Wikipedia, and as well periodically help out on the VRT queues addressing concerns from readers and (more often than one might expect) article subjects. I'm also a list admin for multiple mailing lists, including Wikimedia-L, Checkuser-L, and a couple of enwiki-specific lists. I'm a bureaucrat on the Checkuser-wiki. I'm currently an advisor for Toolhub as well as a member of the WMF Communications Committee. I spent November 2021 to July 2024 as part of the Movement Charter Drafting Committee. I am a former member of the Funds Dissemination Committee (a committee of the WMF's Board of Trustees), the Elections Committee, the Strategy 2030 project.

My primary interests here are to provide information and commentary on tasks that have an effect on my Wiki-roles. That range is far broader than one might think - any extension or interface that permits user-created content, many privacy and security-related issues, interactions between the developer team and the editorial communities.

Recent Activity

Fri, Nov 8

Risker added a comment to T377045: Message content lost when mailing list is the only recipient.

Looks like this has just happened on Wikimedia-l. Here's a link to the archived message: https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/message/DL2A5HHYG5RQPWNH26IGFGSCWFIUW25M/. Unsure if the message was held for moderation since I'm just a regular subscriber to the list.

The message ID I see in my email client is:

SG2PR01MB4518B0050887370F90FAD857F85C2@SG2PR01MB4518.apcprd01.prod.exchangelabs.com

Edit: I suspect the message was not held for moderation, as it is timestamped Thu, 07 Nov 2024 23:43:28 +0000, and I received it about the exact same time:

Received: from lists.wikimedia.org (lists.wikimedia.org. [208.80.154.81]) by mx.google.com with ESMTPS id ffacd0b85a97d-381eda1b59fsi1676990f8f.759.2024.11.07.15.43.36 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 07 Nov 2024 15:43:36 -0800 (PST)
Fri, Nov 8, 4:46 AM · collaboration-services, SRE, Wikimedia-Mailing-lists

Jul 8 2024

Risker updated Risker.
Jul 8 2024, 4:23 AM
Risker updated Risker.
Jul 8 2024, 4:21 AM

Jul 6 2024

Risker added a comment to T369341: Some VRTS emails to Gmail accounts fail the SPF check.

Noting that we have identified a further bounced email. (Again, it's from a restricted list with private info attached to the ticket, so many subscribers may not be able to view.) The one thing all of these emails have in common is that they are being sent from the "wikipedia.org" domain. Ensuring that domain has the proper SPF/DKIM authentications seems to be the straightforward solution.

Jul 6 2024, 5:55 PM · Infrastructure-Foundations, collaboration-services, vrts

Jul 5 2024

Risker added a comment to T369341: Some VRTS emails to Gmail accounts fail the SPF check.

I have received the same type of message as listed above for two tickets in checkuser-en-wp queue. (Private information in this queue).

Jul 5 2024, 11:11 AM · Infrastructure-Foundations, collaboration-services, vrts

Apr 14 2023

Risker added a comment to T309416: Allow re-tallying of STV elections.

I keep coming back to how and why we decided to use one of the more complicated STV processes. I know it makes the election geeks happy, but the purpose of these elections isn't to make them happy, it's to give us an unimpeachable decision that isn't going to wind up being revisited the second someone quits. There should be a system that ranks every single candidate right down to the last one, so that elections do not need to be rerun or restarted. There were so many things wrong with rerunning this election (including the fact that half of the MCDC members weren't elected, they were appointed from the candidate pool, so the results were already going to be messed up no matter what), and I note that nobody actually informed the individuals whose name was being put forward in the rerun election that this was going to happen.

Apr 14 2023, 3:32 AM · MediaWiki-extensions-SecurePoll

Apr 11 2023

Risker added a comment to T309416: Allow re-tallying of STV elections.

Normal processes would be to run the election, with advance processes for filling seats due to resignation. The appropriate solutions would be either (a) next past the post candidate (who may also need to meet any other additional requirements) or (b) run a new election.

That's fine to have additional processes or procedures to fill those seats if this happens, but technically, there is no "next past the post candidate" with Meek STV. Your only options are to re-tally or run the election a second time, and the latter option is extremely expensive in terms of staff time.

Apr 11 2023, 5:44 AM · MediaWiki-extensions-SecurePoll

Apr 6 2023

Risker added a comment to T309416: Allow re-tallying of STV elections.

Disagree that retallying is an acceptable solution. Normal processes would be to run the election, with advance processes for filling seats due to resignation. The appropriate solutions would be either (a) next past the post candidate (who may also need to meet any other additional requirements) or (b) run a new election.

Apr 6 2023, 7:07 AM · MediaWiki-extensions-SecurePoll

Mar 24 2023

Risker added a comment to T332927: Turn down summary digest frequency on wikimedia-l.

I am one of the list owners. Digest frequency has been set at "daily" since the earliest days of this mailing list. The next most frequent option is "weekly" and that's too long.

Mar 24 2023, 5:37 PM · SRE, Wikimedia-Mailing-lists

Feb 19 2022

Risker added a comment to T302139: Not receiving VRT notification emails.

Confirming that this has been identified by myself and several other users of oversight-en and checkuser-en queues (at minimum). Concur with the timeline identified above. There is currently an enwiki functionaries thread about this.

Feb 19 2022, 6:00 PM · SRE, Mail, Znuny, vrts, Infrastructure-Foundations

Jan 17 2022

Risker added a comment to T299351: Configuration variable to disable the "content was" on deletion pages.

The feature has been subverted in several large Wikipedia projects (English, German, Italian) for many years. On English Wikipedia, we subverted it because the automatic summary would include the very material that was the cause of the deletion in the first place; that is, libelous, offensive, or otherwise seriously problematic information (often about a real person). The alternative workaround (suppression and/or revision deletion of multiple logs) is very cumbersome. This may be a reflection of some of the editing on these projects (i.e., a proportionately high degree of deleted articles with highly inappropriate content in the autosummary) or simply a heavier volume of editing on these projects. There is generally almost no useful information in the summaries of any deleted article on a Wikipedia; a deletion reason should be sufficient.

Jan 17 2022, 3:08 PM · SecTeam-Processed, MediaWiki-Page-deletion

Jan 13 2022

Risker added a comment to T189943: Reveal email recipient's username in checkuser query results.

I'm having a hard time conceiving of a situation where a checkuser would need to know the name of the *recipient* of an email; the investigation focuses on the sender, not the recipient. The only way I can see this helping an investigation would be if we asked the recipient about the content of the email, which I believe would freak out the recipient. We would not have any way of knowing whether or not the recipient had even read the email.

Jan 13 2022, 6:43 AM · SecTeam-Processed, Privacy Engineering, WMF-Legal, Privacy, CheckUser, Stewards-and-global-tools

Oct 9 2021

Risker added a comment to T292882: Toolhub: Rename "administrator" permission to something like "sysadmin".

Provided the term "sysadmin" isn't used elsewhere in the Mediawiki world to represent an even higher level of permission than the (current) Toolhub administrator role, I have no problems with this. Please be very sure of this; in many non-Mediawiki settings, "sysadmin" has a significantly higher permission/access level than the current Toolhub admin role will have.

Oct 9 2021, 2:05 AM · Toolhub

Jul 13 2021

Risker added a comment to T286122: Make auditing members of mailing lists bound to a user right easier.

I think this is a solution in search of a problem. As a listadmin for checkuser-l, I can tell you that we periodically audit the list and haven't ever had a problem. We've done the same for the other two mailing lists covering private information that I also am a listadmin for, and again have never had a problem. As long as listadmins get notices of subscription and unsubscription, any issues are fairly easily addressed. I can also tell you that a truly amazing number of people use multiple email addresses that don't match their onwiki email addresses for mailing lists for reasons of their own, and I don't think it's necessary to require these folks to (a) change this behaviour or (b) set up a far more complicated mailman profile. I hadn't looked at my mailman profile for at least 5 years prior to the switchover, and I only would review it now because it's right there when I go to moderate posts.

Jul 13 2021, 4:00 AM · SRE, Wikimedia-Mailing-lists

Jun 21 2021

Risker added a comment to T282624: Limit IA granting/revoking to stewards only.

Note that there is a simple way to make every one happy, who wants to become interfaceadmin make a request in their local community (e.g. bureaucrat noticeboard, or where they did it in the past) and if the bureaucrats are agreed with the request then this request is addressed to the Stewarts who can perform the technical procedure. Conversely if bureaucrats, for local reasons or local policies, thinks the right should be removed to someone, they address the removel request to Stewarts who can again perform the technical procedure. In that way Bureaucrats (and therefore the local communities) still keep a part of that power, and the security aspect is managed by the Stewarts. Someone who need interfaceadmin right will need the agreement of both, the Bureaucrat and the Stewarts.

Jun 21 2021, 5:10 PM · Community-consensus-needed, Tech Ambassadors & Translators, [DEPRECATED] wdwb-tech, Chinese-Sites, Wikidata, Serbian-Sites, Commons, Wiktionary-fr, Stewards-and-global-tools, User-notice, Trust-and-Safety, Wikimedia-Site-requests

May 7 2021

Risker added a comment to T112147: Rename the oversight group on WMF projects to the MediaWiki standard (whatever that is).

However, this discussion is out of scope for this task.

May 7 2021, 8:19 PM · User-notice-archive, MW-1.38-notes (1.38.0-wmf.26; 2022-03-14), User-Urbanecm, Patch-For-Review, Trust-and-Safety, Wikimedia-Site-requests, MediaWiki-General
Risker added a comment to T112147: Rename the oversight group on WMF projects to the MediaWiki standard (whatever that is).

Just noting here that "suppress" is considered a very, very negative word in common English usage. "Oversighter" was bad enough; "Suppressor" is horrendous, and not the kind of user group name that's appropriate for diligent users taking care of some of the nastiest stuff on the projects. I have no idea why someone thought "suppress" was a good name way back in 2009, but it's even worse now in 2021, when we've had multiple opportunities to find a user group name with less authoritarian and negative connotations.

Thank you for your point of view. I don't agree that it applies to all native English speakers, however.

May 7 2021, 7:53 PM · User-notice-archive, MW-1.38-notes (1.38.0-wmf.26; 2022-03-14), User-Urbanecm, Patch-For-Review, Trust-and-Safety, Wikimedia-Site-requests, MediaWiki-General
Risker added a comment to T112147: Rename the oversight group on WMF projects to the MediaWiki standard (whatever that is).

Just noting here that "suppress" is considered a very, very negative word in common English usage. "Oversighter" was bad enough; "Suppressor" is horrendous, and not the kind of user group name that's appropriate for diligent users taking care of some of the nastiest stuff on the projects. I have no idea why someone thought "suppress" was a good name way back in 2009, but it's even worse now in 2021, when we've had multiple opportunities to find a user group name with less authoritarian and negative connotations.

May 7 2021, 6:34 PM · User-notice-archive, MW-1.38-notes (1.38.0-wmf.26; 2022-03-14), User-Urbanecm, Patch-For-Review, Trust-and-Safety, Wikimedia-Site-requests, MediaWiki-General

Apr 2 2021

Risker updated Risker.
Apr 2 2021, 10:48 PM

Oct 18 2020

Risker added a comment to T265810: mw-ext-FileImporter uses a WMF IP address, does not include XFF for users using this extension (CVE-2020-27621).
Oct 18 2020, 7:03 PM · Vuln-Misconfiguration, MW-1.36-notes (1.36.0-wmf.13; 2020-10-12), WMDE-QWERTY-Sprint-2020-10-07, Unplanned-Sprint-Work, Move-Files-To-Commons, Security, Security-Team
Risker updated subscribers of T265810: mw-ext-FileImporter uses a WMF IP address, does not include XFF for users using this extension (CVE-2020-27621).
Oct 18 2020, 7:02 PM · Vuln-Misconfiguration, MW-1.36-notes (1.36.0-wmf.13; 2020-10-12), WMDE-QWERTY-Sprint-2020-10-07, Unplanned-Sprint-Work, Move-Files-To-Commons, Security, Security-Team
Risker created T265810: mw-ext-FileImporter uses a WMF IP address, does not include XFF for users using this extension (CVE-2020-27621).
Oct 18 2020, 4:46 AM · Vuln-Misconfiguration, MW-1.36-notes (1.36.0-wmf.13; 2020-10-12), WMDE-QWERTY-Sprint-2020-10-07, Unplanned-Sprint-Work, Move-Files-To-Commons, Security, Security-Team

Oct 1 2020

Risker added a comment to T261023: Explore content moderation issues.

@bd808 and I spoke today about some concepts, which I will document here:

Oct 1 2020, 12:59 AM · Developer-Advocacy (Oct-Dec 2020), User-bd808, Toolhub

Sep 14 2020

Risker added a comment to T262733: Cannot change password for role account that is not an attached global account - Assistance required from someone with shell access.

Our thanks to Urbanecm, who made the change to the email address for us. We will arrange for its reversion at the end of the OTRS downtime. We will further follow up with other wikis to resolve the "non-attached" issue.

Sep 14 2020, 12:57 AM · User-Urbanecm, Wikimedia-Site-requests, MediaWiki-extensions-CentralAuth, MediaWiki-General

Sep 12 2020

Risker added a comment to T262733: Cannot change password for role account that is not an attached global account - Assistance required from someone with shell access.

User:Oversight is in this weird case because each wiki wanted the email to point to their address but if the account was globalized/unified it could only have one email address, so we punted on unifying it during SULF.

Sep 12 2020, 7:59 AM · User-Urbanecm, Wikimedia-Site-requests, MediaWiki-extensions-CentralAuth, MediaWiki-General
Risker updated the task description for T262733: Cannot change password for role account that is not an attached global account - Assistance required from someone with shell access.
Sep 12 2020, 6:22 AM · User-Urbanecm, Wikimedia-Site-requests, MediaWiki-extensions-CentralAuth, MediaWiki-General
Risker added projects to T262733: Cannot change password for role account that is not an attached global account - Assistance required from someone with shell access: MediaWiki-extensions-CentralAuth, Wikimedia-Site-requests.
Sep 12 2020, 6:20 AM · User-Urbanecm, Wikimedia-Site-requests, MediaWiki-extensions-CentralAuth, MediaWiki-General
Risker created T262733: Cannot change password for role account that is not an attached global account - Assistance required from someone with shell access.
Sep 12 2020, 6:16 AM · User-Urbanecm, Wikimedia-Site-requests, MediaWiki-extensions-CentralAuth, MediaWiki-General

Sep 10 2020

Risker added a comment to T259721: Create a front end option for administrators to create a local account from a global account.

This would be helpful. Stewards will often create a global account, or the user may create their account and start editing on another project, but then is unable to edit English Wikipedia (or another project) that has their IP/IP range account-creation blocked for valid local reasons. It's particularly problematic if the user has already edited on other projects, because their accounts will then be split, leaving them open to allegations of inappropriate sockpuppetry.

Sep 10 2020, 5:45 AM · User-notice-archive, User-Majavah, MediaWiki-Special-pages, MediaWiki-extensions-CentralAuth

Apr 24 2020

Risker added a comment to T247540: Should CheckUser track bot edits?.

Having been around longer than some of the other checkusers, I can say that I *have* checked bots, and that there have been abuse issues and other technical problems identified through these checks. (Example of technical issues previously identified in times past - finding that a bot was using a *non-existant* IP address, finding bots that were using the WMF server addresses, both apparently due to misconfigurations.)

Apr 24 2020, 4:08 AM · Stewards-and-global-tools, Anti-Harassment, CheckUser

Nov 27 2019

Risker added a comment to T118219: Nothing happens when clicking on the glowing blue (education) dots in Firefox 41/Windows 7.

@Aklapper : Unless I miss my guess, the underlying extension isn't in use anymore on enwiki. I don't think I've seen it in a very long time - last comment is four years ago. I propose that this be closed in the manner that you feel most appropriate.

Nov 27 2019, 3:30 AM · VisualEditor-MediaWiki, VisualEditor

Oct 24 2019

Risker added a comment to T235983: Lengthy delays in emails being received from mailing lists in October 2019.

Confirming that this is a serious issue. Two time-sensitive enwiki mailing lists, Oversight-L and Functionaries-en-L, do not seem to be sending out emails.

Oct 24 2019, 2:40 AM · Mail, Wikimedia-Mailing-lists, SRE

May 13 2019

Risker added a comment to T223043: Group-oversight-member: Replace "oversight" by "oversighter".

@Risker, I am very disappointed by this bureaucratic objection to a typo fix that is backed by a local policy and can easily be overridden by creating the page with any content that the enwiki community decides on in an RFC.

May 13 2019, 2:42 AM · Patch-For-Review, WikimediaMessages

May 12 2019

Risker added a comment to T223043: Group-oversight-member: Replace "oversight" by "oversighter".

Please see the comments on the thread at https://en.wikipedia.org/wiki/Wikipedia_talk:Oversight#Request_for_creation where there is clearly NO CONSENSUS for this change, particularly as it does not actually fix anything that is an actual problem.

May 12 2019, 11:40 PM · Patch-For-Review, WikimediaMessages

Dec 6 2018

Risker added a comment to T197160: All security-sensitive MediaWiki functionality should require elevated security.

Two things come to mind. First, even if we *only* require people with admin or higher permissions/private wikis/etc, we're talking over 5000 users who would require 2FA. This number of users would require the WMF to have dedicated resources available 24/7 to assist users who get locked out of their accounts due to some sort of systemic or user issue. That's a minimum of 5 FTE whose "drop everything and do it now" job would be dealing with 2FA failures, although obviously they could be doing other things too. I'm well aware that WMF staff developers are already overloaded with real and potential tasks, so I'm concerned that it would mean additional staffing. There are less weighty steps that can be taken first (e.g., the planned changes in password requirements, socialization to the use of previously unused passwords unique to the Wikimedia SUL account, etc.).

Dec 6 2018, 6:18 AM · Security, User-Tgr, Epic, MediaWiki-Core-AuthManager

Nov 27 2018

Risker added a comment to T150826: Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).
In T150826#4778848, @Adotchar wrote:

There's discussion on enwiki about also having a rate limit on blocking users. Seems like a reasonable enough idea, but we'd want it high, as we really only want it in cases of truly malicious users.

Please, please, please do not do this globally without a meta RfC or some form of other discussion. (and should require every wiki’s community to be notified, or for it to be handled on a wiki-by-wiki basis)

I am strongly opposed to this, and I’m sure many others are as well who are not watching this ticket.

Not planning to implement that at this time (unless people start explicitly asking for it), just recording it as an idea.

I think the problem is, in order not to be annoying it would have to be a high limit (imo, I think the lowest that would be reasonable would be 30 blocks / minute) And then it becomes not that useful in the attack scenario.

My general plan for alleviating the threat of someone blocking all admins is tgr's idea about being able to block the person who blocked you.

Nov 27 2018, 8:39 PM · User-notice-archive, MW-1.33-notes (1.33.0-wmf.8; 2018-12-11), MediaWiki-User-management, Community-consensus-needed, Wikimedia-Site-requests
Risker added a comment to T150826: Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).

Before freaking out about unintended workflow impacts, can we actually check if any wiki used self-unblocks to any significant degree? Apparently there were about five self-unblocks a year on enwiki, and most of those undid self-blocks (which is still possible). If that's any indication this should be a total non-issue for smaller projects, and mentioning it in the next Tech News is a more than appropriate notification mechanism. Maybe wikis with different usage patterns exist, but let's verify that first instead of just assuming it is so.

Nov 27 2018, 6:06 AM · User-notice-archive, MW-1.33-notes (1.33.0-wmf.8; 2018-12-11), MediaWiki-User-management, Community-consensus-needed, Wikimedia-Site-requests
Risker added a comment to T150826: Remove unblockself right on wikimedia wikis (but allow blocked admins to block their blocker).

I'm inclined to agree with Majora on this point. I see good reason to move ahead with this change on enwiki; there is a pretty clear case for doing so there. However, I don't see any indication that anyone has researched whether or not self-unblocks are happening on other wikis, or what the circumstances of those hypothetical unblocks are. We just don't know if there aren't some really different workflows on other projects for which this particular permission is important.

Nov 27 2018, 2:46 AM · User-notice-archive, MW-1.33-notes (1.33.0-wmf.8; 2018-12-11), MediaWiki-User-management, Community-consensus-needed, Wikimedia-Site-requests

Jan 4 2018

Risker added a comment to T182541: Update Wikimedia configuration to prevent some users from sending emails.

The solution solved a problem that wasn't really the problem. The issue was bots generating email messages to users who simply read a page. The solution was to give the users a global option to determine which wikis they wished to receive bot email messages from - or alternately to prevent bots from sending emails. (There is no evidence at all that bot email messages ever bring users to wikis.)

Jan 4 2018, 10:20 PM · Anti-Harassment (AHT Sprint 12), Trust-and-Safety, Patch-For-Review, Wikimedia-Site-requests
Risker added a comment to T178842: If a user has never triggered a logged action on a wiki, they should not be able receive emails by non-privileged users from there.

Noting in passing that this disabled the ability of enwiki users to email role accounts (User:Oversight and similar) which are expressly intended to receive emails only. Seems to me that the much better solution would have been to allow people to stop bot emails at their global preferences, or to select wikis from which they receive emails at the same point. This created unnecessary distress as people could not submit suppression requests.

Jan 4 2018, 10:16 PM · MW-1.31-release-notes (WMF-deploy-2017-12-12 (1.31.0-wmf.12)), Anti-Harassment (AHT Sprint 11), Patch-For-Review

Oct 10 2017

Risker added a comment to T171027: "Read timeout is reached" DBQueryError when trying to load specific users' watchlists (with +1000 articles) on several wikis.

This is a hugely political issue. Let's please not do this unless necessary. Daniel has provided a patch for T177707 and Marius has been working on various other improvements.

Oct 10 2017, 8:50 PM · User-notice-archive, Growth-Team, MW-1.31-release-notes (WMF-deploy-2017-10-03 (1.31.0-wmf.2)), MediaWiki-extensions-WikibaseRepository, Wikidata-Former-Sprint-Board, Patch-For-Review, Collaboration-Team-Triage (Collab-Team-This-Quarter), DBA, Wikidata, Commons, Contributors-Team, Wikimedia-production-error, MW-1.30-release-notes (WMF-deploy-2017-08-08_(1.30.0-wmf.13)), Russian-Sites, WMF-General-or-Unknown, Performance Issue, MediaWiki-Watchlist

Sep 27 2017

Risker added a comment to T175450: Support suppression (oversight) of newsletters.

@Risker Do you have better memory as if title suppression did removed in the past the page title as well from related logs? I know hideuser does, but I cannot remember if page suppression did as well.

Sep 27 2017, 2:50 AM · Security, Stewards-and-global-tools, OKR-Work, MediaWiki-extensions-Newsletter, Security-Extensions

Jul 24 2017

Keegan awarded T171405: Cannot suppress pages while deleting following change to page deletion interface a Love token.
Jul 24 2017, 3:24 AM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion

Jul 23 2017

Risker added a comment to T171405: Cannot suppress pages while deleting following change to page deletion interface.

@Jalexander: the workaround is to suppress the log event manually, no? Doesn't seem worth keeping private accordingly unless I am misunderstanding..

Jul 23 2017, 10:01 PM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion
Risker updated subscribers of T171405: Cannot suppress pages while deleting following change to page deletion interface.
Jul 23 2017, 9:17 PM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion
Risker triaged T171405: Cannot suppress pages while deleting following change to page deletion interface as High priority.
Jul 23 2017, 4:47 PM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion
Risker updated subscribers of T171405: Cannot suppress pages while deleting following change to page deletion interface.
Jul 23 2017, 4:41 PM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion
Risker created T171405: Cannot suppress pages while deleting following change to page deletion interface.
Jul 23 2017, 4:37 PM · Security, MW-1.30-release-notes (WMF-deploy-2017-07-18_(1.30.0-wmf.10)), Patch-For-Review, MediaWiki-Revision-deletion, Security-Core, Vuln-Infoleak, Regression, MediaWiki-Page-deletion

Jul 13 2017

Risker added a comment to T170601: Massive spam to -owner mailing lists from *@qq.com emails.

Further note - being reported on other -owner lists via the List Admins mailing list.

Jul 13 2017, 5:45 PM · SRE, Security, Wikimedia-Mailing-lists
Risker added a comment to T170601: Massive spam to -owner mailing lists from *@qq.com emails.

Just to provide more complete information - approximately 1200 emails were received from the *@qq.com email addresses between 1330 UTC and 1634 UTC (when most of the list admins were removed as a stopgap measure, to stop the flooding of our personal email inboxes). They started at a rate of 1-2/minute and by the time I stopped receiving, they were coming at a rate of 15/minute. As best I can tell, this is the only *-L-owner mailing list affected - I am also a listadmin on a bunch of other lists and none of them were affected.

Jul 13 2017, 5:23 PM · SRE, Security, Wikimedia-Mailing-lists

Jul 6 2016

Risker added a comment to T131132: Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action.

I can see your point, TheDJ. At the same time, this change is being based on 2009 interviews with 8 users from the San Francisco area in English only, and only one of them even mentioned the word "publish" in their interviews. All 8 of the interviewees understood that "save" meant their work was going to be saved, although there were some different understandings of what "save" meant. Such a small sample size and small result would be laughed at anywhere outside of website design, but meh. For the record, all 8 users experienced serious difficulties in relation to templates, which have if anything become more complex and opaque since those 2009 interviews.

Jul 6 2016, 12:59 AM · User-notice-archive, MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), User-Ryasmeen, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-08-30_(1.28.0-wmf.17)), Community-Relations-Support, MW-1.27-release (WMF-deploy-2016-05-03_(1.27.0-wmf.23)), MW-1.27-release-notes, Patch-For-Review, WikiEditor (2010), VisualEditor, Contributors-Team, MediaWiki-Internationalization, MediaWiki-Page-editing

Jul 4 2016

Risker added a comment to T131132: Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action.

Mostly, I am saying "show why this change is better". There's no data to support that this change will have any different result. We have plenty of data to show that important and visible changes to the UI tend to foster significant hostility between the Wikimedia communities and the WMF if they are not well explained, well justified and well documented, and if the community is left to fix all the documentation and any unconsidered or ignored problems that may arise from it. Given there's no evidence "publish" is any more likely to result in better understanding on the part of new editors that their work will be immediately viewable on the internet (or alternately, that it won't be viewable in some cases, such as talk pages, draft space, and many other places where the "save" button currently appears), I don't think there is much benefit in burning off what little goodwill there currently exists between the editing community and the WMF over this particular "tweak".

Jul 4 2016, 9:49 PM · User-notice-archive, MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), User-Ryasmeen, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-08-30_(1.28.0-wmf.17)), Community-Relations-Support, MW-1.27-release (WMF-deploy-2016-05-03_(1.27.0-wmf.23)), MW-1.27-release-notes, Patch-For-Review, WikiEditor (2010), VisualEditor, Contributors-Team, MediaWiki-Internationalization, MediaWiki-Page-editing
Risker added a comment to T131132: Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action.

Please don't be patronizing, Scott.

Jul 4 2016, 8:21 PM · User-notice-archive, MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), User-Ryasmeen, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-08-30_(1.28.0-wmf.17)), Community-Relations-Support, MW-1.27-release (WMF-deploy-2016-05-03_(1.27.0-wmf.23)), MW-1.27-release-notes, Patch-For-Review, WikiEditor (2010), VisualEditor, Contributors-Team, MediaWiki-Internationalization, MediaWiki-Page-editing
Risker added a comment to T131132: Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action.
In T131132#2425750, @Scott wrote:

Incidentally, Scott...Base is not just referring to printed works. He is also referring to the hundreds of pages on every wiki in the Help space, and often in the Wikipedia or similar spaces that teach editors how to operate. It will take years, literally, to get those all cleaned up...

That's really not much of a problem on WMF wikis, where rapid mass changes are easily within technical ability, and again, it's not MediaWiki developers' responsibility to update other people's out of date documentation.

Jul 4 2016, 2:36 PM · User-notice-archive, MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), User-Ryasmeen, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-08-30_(1.28.0-wmf.17)), Community-Relations-Support, MW-1.27-release (WMF-deploy-2016-05-03_(1.27.0-wmf.23)), MW-1.27-release-notes, Patch-For-Review, WikiEditor (2010), VisualEditor, Contributors-Team, MediaWiki-Internationalization, MediaWiki-Page-editing
Risker added a comment to T131132: Re-label the "Save" button to be "Publish", to better indicate to users the outcomes of their action.

I'm going to agree with Base. I cannot understand why anyone would think "Publish" is a more appropriate word than "Save" in this context, especially as it does not apply to many of the tasks that are, erm, saved. A single universal word is going to be much easier for editors to use and understand.

Jul 4 2016, 5:35 AM · User-notice-archive, MW-1.35-notes (1.35.0-wmf.37; 2020-06-16), User-Ryasmeen, MW-1.28-release-notes, MW-1.28-release (WMF-deploy-2016-08-30_(1.28.0-wmf.17)), Community-Relations-Support, MW-1.27-release (WMF-deploy-2016-05-03_(1.27.0-wmf.23)), MW-1.27-release-notes, Patch-For-Review, WikiEditor (2010), VisualEditor, Contributors-Team, MediaWiki-Internationalization, MediaWiki-Page-editing

Jul 2 2016

Risker added a comment to T131123: Send out browser testing user satisfaction survey.

What's the privacy policy for this survey?

Jul 2 2016, 3:55 AM · User-zeljkofilipin, Surveys, Malu (Malu-Prototype), releng-201516-q4

Mar 21 2016

Risker added a comment to T107707: Login alert when user logs in from new machine.

Speaking as someone who has recently run into about a dozen different sites sending me these warnings when I logged in (a) on a new tablet and (b) on an old machine using a different ISP... these were such a royal pain in the neck (in several cases I was required to "verify" my account if I wanted to use it) it resulted in my simply not bothering to log into some of those sites again.

Mar 21 2016, 3:30 AM · Community-Tech, MW-1.30-release-notes (WMF-deploy-2017-07-11_(1.30.0-wmf.9)), Patch-For-Review, MediaWiki-extensions-LoginNotify, Security-Core, MediaWiki-User-login-and-signup

Feb 27 2016

Risker added a comment to T128247: Broken section editing link.

Kolakoski.PNG (486×487 px, 28 KB)

Feb 27 2016, 4:11 AM · MediaWiki-User-Interface
Risker created T128247: Broken section editing link.
Feb 27 2016, 3:58 AM · MediaWiki-User-Interface

Dec 4 2015

Risker added a comment to T119412: provide contribs link and prevent mobile user without user page from being dumped into blank screen when they click their username.

I can't tell who the intended "user" of this proposed page design is. Are you trying to create something useful for casual readers who don't really edit? Experienced editors? New users?

Dec 4 2015, 4:55 AM · Reading-Web-Sprint-63-Ellip…, Patch-For-Review, MW-1.27-release (WMF-deploy-2016-01-12_(1.27.0-wmf.10)), Reading-Web-Planning

Nov 19 2015

Risker updated subscribers of T85929: [EPIC] Kill SpecialUserProfile or Move MobileFrontend extension's Special:UserProfile.php and related code to a separate MediaWiki extension.
Nov 19 2015, 7:08 PM · Epic, Reading Web Sprint 62 - DJ-Jazzy-Jeff-and-the-Fresh-Sprints, Reading-Web-Planning, MobileFrontend, Patch-For-Review, MediaWiki-extension-requests, Technical-Debt, MediaWiki-Special-pages

Nov 10 2015

Risker added a comment to T118219: Nothing happens when clicking on the glowing blue (education) dots in Firefox 41/Windows 7.

(copied from the enwiki feedback page, so you'll have it here)
I did some work tonight with Krenair (thanks for taking the time, Krenair!) and we worked out that there were a few things happening. First, it appears that my anti-virus software (Kaspersky) was blocking the popups that should come from the blue dots. I did a bunch of tweaking with that and with the browser, and eventually found a combination that allowed the popups. I don't think I'll leave things at these settings, though; they're less protective than the "factory settings" and in just the few hours since I did that I've had quite a bit more spam and other junk showing up. I also haven't had any problems with other popups on Wikipedia, which were able to show up through the AV software, so it is odd that these particular ones got caught. But, and this is an important but...even with all that, clicking on the blue dots did nothing for me. However, clicking on the actual link symbol or the word "cite" resulted in a popup. The popups had a brief bit of text describing that one can make links to internal or external web pages, or that citations improve your content. Neither described how to use the button, though, and I needed to click "Okay, got it" to dismiss the popup. I could, however, edit with the popups in place, just as long as I didn't want to edit anything that was covered by them. These were also pretty big popups and most of the space seemed to be taken up by images that weren't great illustrations, but I realise this is an early iteration. (I won't even go into my usual tirade about live content production being not the right place for alpha testing.) But this needs a lot of work. And the flashing dots still don't do anything, the popup is actually on the button.

Nov 10 2015, 6:48 AM · VisualEditor-MediaWiki, VisualEditor

Nov 8 2015

Risker added a comment to T102398: Migrate wikis to use a single edit tab which has both visual and wikitext modes and allows on-the-fly switching between them.

There is no benefit to this from the editorial perspective. This is a design change driven by people who do not edit. Please do not implement.

Nov 8 2015, 9:21 PM · User-notice, Epic, Design, VisualEditor-MediaWiki, VisualEditor

Sep 18 2015

Risker added a comment to T112912: @txt.att.net bounce notifications being sent to list admins.

I'm going to agree with John here that bounces are important. They are flags that there is a problem with the process - the level of importance of the problem will vary. That lots of lists are getting the same flag repeatedly is actually quite useful information that helps to define and prioritize this issue.

Sep 18 2015, 4:05 PM · SRE, Wikimedia-Mailing-lists
Risker added a comment to T112912: @txt.att.net bounce notifications being sent to list admins.

This has happened before, to varying extents. It strikes me that someone has found a way to spoof the WMF mailing list addresses, and the ATT group is sending bounces. We get a lot of bounces like this for the (very longstanding) checkuser list - not just from ATT - a few a week, at least.

Sep 18 2015, 2:05 AM · SRE, Wikimedia-Mailing-lists

Sep 3 2015

Risker added a comment to T100067: Enable the visual editor in the Wikipedia namespace on the English Wikipedia.

Okay...please undo this. Contrary to what is suggested above, Wikipedia space is FULL of pages where people need to sign. Noticeboards, AfDs, checkuser pages...pretty much every page I've edited since this has been uploaded.

Sep 3 2015, 3:44 AM · Community-consensus-needed, Wikimedia-Site-requests, VisualEditor

Aug 27 2015

AKoval_WMF awarded T58525: Improve spam filtering for Mailman mailing lists a Like token.
Aug 27 2015, 3:41 PM · Wikimedia-Mailing-lists

Aug 3 2015

Risker added a comment to T102199: Reports of a high number of edits being rejected due to loss of session data.

Hello Ori - Since the change you made, I have had NO unexpected losses of sessions. This is a massive improvement, as I was verging toward 90% on checkuserwiki when I had the page open for as little as 2 minutes, and 100% if open more than 10 minutes.

Aug 3 2015, 3:08 AM · Performance-Team, User-notice-archive, SRE, WMF-deploy-2015-07-28_(1.26wmf16), WMF-deploy-2015-08-04_(1.26wmf17), Patch-For-Review, MediaWiki-Core-AuthManager, Sustainability, MediaWiki-libs-BagOStuff, WMF-deploy-2015-06-23_(1.26wmf11), Performance Issue, MediaWiki-Page-editing, WMF-deploy-2015-06-09_(1.26wmf9), MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10), WMF-General-or-Unknown

Jul 12 2015

Risker added a comment to T62373: Convert Oversight revisions to (revision deleted) suppressed on Wikimedia wikis.

@Krenair - Enwiki has over 80% of all edits that were ever oversighted, around 10K as I recall. As noted, we do look at them from time to time. It would be helpful to have the problems identified on other wikis fixed and the fixes confirmed to be effective before running it on enwiki. (In fact, I thought the purpose of running it on the smaller wikis first was specifically to identify and fix problems before it was done on enwiki, where a much bigger mess could result.)

Jul 12 2015, 4:13 AM · Wikimedia-maintenance-script-run, WMF-deploy-2015-07-21_(1.26wmf15), Patch-For-Review, WMF-General-or-Unknown
Risker added a comment to T62373: Convert Oversight revisions to (revision deleted) suppressed on Wikimedia wikis.

@Krenair I checked it again and it's kinda weird.... I searched in the suppression log on nlwiki and actually, there *is* an entry in the log (look for the date "19 dec 2010 15:04"), BUT... the log entry isn't mentioned on the suppression log of the suppressed edit as can be seen here: https://nl.wikipedia.org/w/index.php?title=Speciaal:VersieVerwijderen&type=revision&target=Ad_van_den_Berg_%28activist%29&ids=23646821 (if you know what I mean) And that should be fixed ofc.

Jul 12 2015, 3:59 AM · Wikimedia-maintenance-script-run, WMF-deploy-2015-07-21_(1.26wmf15), Patch-For-Review, WMF-General-or-Unknown
Risker added a comment to T62373: Convert Oversight revisions to (revision deleted) suppressed on Wikimedia wikis.

Hold on - have the oversighted edits on English Wikipedia been converted yet? Please don't disable until that has been done, we do periodically have to review some of that information.

Jul 12 2015, 3:58 AM · Wikimedia-maintenance-script-run, WMF-deploy-2015-07-21_(1.26wmf15), Patch-For-Review, WMF-General-or-Unknown

Jul 8 2015

Risker added a comment to T102199: Reports of a high number of edits being rejected due to loss of session data.

I agree with Amire80, this is getting significantly worse. I made 13 edits and performed 13 checkusers between 0056 and 0415 hours UTC today (July 8). Of those, all but two of the edits failed on the first attempt, and at least 5 of the checkusers failed on the first attempt (usually when doing a second check but switching checking parameters). I am concerned that new users in particular may become frustrated and abandon attempts to edit.

Jul 8 2015, 6:50 PM · Performance-Team, User-notice-archive, SRE, WMF-deploy-2015-07-28_(1.26wmf16), WMF-deploy-2015-08-04_(1.26wmf17), Patch-For-Review, MediaWiki-Core-AuthManager, Sustainability, MediaWiki-libs-BagOStuff, WMF-deploy-2015-06-23_(1.26wmf11), Performance Issue, MediaWiki-Page-editing, WMF-deploy-2015-06-09_(1.26wmf9), MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10), WMF-General-or-Unknown

Jul 7 2015

Risker added a comment to T102199: Reports of a high number of edits being rejected due to loss of session data.

@Aklapper, I had six session errors last night, including two while I was using the checkuser interface. I received the message that is described in the initiating post. (The system also separately logged me out twice, which was very unhelpful, but I do not know if there is a link between these two actions.)

Jul 7 2015, 1:01 PM · Performance-Team, User-notice-archive, SRE, WMF-deploy-2015-07-28_(1.26wmf16), WMF-deploy-2015-08-04_(1.26wmf17), Patch-For-Review, MediaWiki-Core-AuthManager, Sustainability, MediaWiki-libs-BagOStuff, WMF-deploy-2015-06-23_(1.26wmf11), Performance Issue, MediaWiki-Page-editing, WMF-deploy-2015-06-09_(1.26wmf9), MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10), WMF-General-or-Unknown

Jun 30 2015

Risker added a comment to T94774: Password policies by group.

Change 222025 had a related patch set uploaded (by CSteipp):
Log privileged users with short passwords

https://gerrit.wikimedia.org/r/222025

Jun 30 2015, 11:14 PM · User-notice-archive, TechCom-RFC (TechCom-RFC-Closed), MW-1.26-release, Security-Team, MediaWiki-User-login-and-signup
Risker added a comment to T94774: Password policies by group.

Thank you for your clarification, csteipp; it's very helpful. I've sent an email to the checkuser mailing list to alert the checkusers who subscribe (and also includes most if not all stewards) with links to the applicable phab tasks so that the discussion (if any) can start for those groups. -I'm pretty sure just about everyone in those groups would already meet the 8-byte requirement, but one never knows.

Jun 30 2015, 8:04 PM · User-notice-archive, TechCom-RFC (TechCom-RFC-Closed), MW-1.26-release, Security-Team, MediaWiki-User-login-and-signup
Risker added a comment to T94774: Password policies by group.

The joys of not reading code - I am unable to determine exactly what is being changed here, other than that it will undoubtedly affect groups of which I am a member. Can things be spelled out more clearly here, please?

Jun 30 2015, 4:51 PM · User-notice-archive, TechCom-RFC (TechCom-RFC-Closed), MW-1.26-release, Security-Team, MediaWiki-User-login-and-signup
Risker added a comment to T94774: Password policies by group.
Jun 30 2015, 12:15 PM · User-notice-archive, TechCom-RFC (TechCom-RFC-Closed), MW-1.26-release, Security-Team, MediaWiki-User-login-and-signup

Jun 14 2015

Risker added a comment to T102199: Reports of a high number of edits being rejected due to loss of session data.

Noting in passing that today I had such a notice for at least 30% of my edits, and also received that message when opening the checkuser interface.

Jun 14 2015, 10:54 PM · Performance-Team, User-notice-archive, SRE, WMF-deploy-2015-07-28_(1.26wmf16), WMF-deploy-2015-08-04_(1.26wmf17), Patch-For-Review, MediaWiki-Core-AuthManager, Sustainability, MediaWiki-libs-BagOStuff, WMF-deploy-2015-06-23_(1.26wmf11), Performance Issue, MediaWiki-Page-editing, WMF-deploy-2015-06-09_(1.26wmf9), MW-1.26-release, WMF-deploy-2015-06-16_(1.26wmf10), WMF-General-or-Unknown

Jun 10 2015

Risker added a comment to T85929: [EPIC] Kill SpecialUserProfile or Move MobileFrontend extension's Special:UserProfile.php and related code to a separate MediaWiki extension.

Jon, I don't think you're the bad guy, I think you're just seeing things
from a very different perspective than many of the commenters.

Jun 10 2015, 11:10 PM · Epic, Reading Web Sprint 62 - DJ-Jazzy-Jeff-and-the-Fresh-Sprints, Reading-Web-Planning, MobileFrontend, Patch-For-Review, MediaWiki-extension-requests, Technical-Debt, MediaWiki-Special-pages

Jun 8 2015

Risker added a comment to T94852: C8. Only change editor preference if the user makes a change with the editor.

Hello Etonkovidova - your chart is not matching my situation. I use markup by default (i.e., I have VE disabled at present) - this is the choice I make in my personal editing preferences. But when I am using a browser that supports VE, the default editing option I get for Flow is VE, not markup. It should be markup, with the option to toggle to VE.

Jun 8 2015, 6:36 PM · WMF-deploy-2015-06-09_(1.26wmf9), Patch-For-Review, Collaboration-Team-Sprint-C-2015-06-17, Collaboration-Team-Triage, StructuredDiscussions

Jun 4 2015

Risker created T101352: Editing in Flow defaults to Visual Editor despite user preference disabling VE.
Jun 4 2015, 3:10 AM · Collaboration-Team-Triage, StructuredDiscussions
Risker created T101351: Flow post being edited using Wikitext reverts to Visual Editor if previewed.
Jun 4 2015, 2:51 AM · StructuredDiscussions, Collaboration-Team-Triage
Risker created T101350: Conflict between user preferences for emails and user preferences for notifications via email.
Jun 4 2015, 2:40 AM · Growth-Team-Filtering, Growth-Team, StructuredDiscussions, Notifications

Jun 3 2015

Risker added a comment to T85929: [EPIC] Kill SpecialUserProfile or Move MobileFrontend extension's Special:UserProfile.php and related code to a separate MediaWiki extension.

As I just commented on the patch https://gerrit.wikimedia.org/r/#/c/194451. We need to discuss the broader context of user to user interaction on mobile, which userpage would be part of.

Jun 3 2015, 5:02 AM · Epic, Reading Web Sprint 62 - DJ-Jazzy-Jeff-and-the-Fresh-Sprints, Reading-Web-Planning, MobileFrontend, Patch-For-Review, MediaWiki-extension-requests, Technical-Debt, MediaWiki-Special-pages

May 19 2015

Risker added a comment to T99690: Mailman rejecting emails by members of private mailing list.

Also occurring on (non-public, non-archiving, subscriber-only) checkuser-L - this is flat-out rejecting emails from subscribers, not sending to moderation.

Not occurring on some other non-public lists, such as functionaries-en-L (which allows moderation and is an archiving list but is non-public) or oversight-L (non-public, subscriber-only, non-archiving).

May 19 2015, 7:45 PM · SRE, Wikimedia-Mailing-lists
Risker added a comment to T99690: Mailman rejecting emails by members of private mailing list.

Also occurring on (non-public, non-archiving, subscriber-only) checkuser-L - this is flat-out rejecting emails from subscribers, not sending to moderation.

May 19 2015, 7:26 PM · SRE, Wikimedia-Mailing-lists

Apr 7 2015

Risker added a comment to T94782: Convert Gather collections into "wiki pages".

I strongly support moving these out of the "Special" namespace because administrators need to be able to delete them. I personally can foresee these pages being easily abused, and also foresee that creators may wish to no longer keep or maintain some of these personal lists. The survey used to determine the use of the name "collection" was seriously flawed, in that it shouldn't have given the term "collection" as an option (we already have collections). It should be re-run, at least 100 responses received, and then a name can be chosen that is appropriate. And yes, it should have its own wiki page namespace.

Apr 7 2015, 3:20 PM · Web-Team-Backlog, Gather
Risker added a comment to T95250: API: Log when admin hides or unhides collection.

The naming of Gather items as "collections" is a case where we made things harder for everyone close to the project, including WMF, in order to make it easier for the 99% of our users who are not close the project. I know it is hard, but appreciate your patience.

Apr 7 2015, 11:42 AM · Patch-For-Review, Gather Sprint Forward, Gather
Risker added a comment to T95250: API: Log when admin hides or unhides collection.

@JKatzWMF - you've managed to confuse me already, because there are two separate types of "collection". (I've made some suggestions on the mailing list for different names that could be used.) I'm assuming you mean whatever the result is when the user does something using Extension:Gather, based on the fact that you've added Gather as the project. In any case, I would suggest mimicking the current log entries as closely as possible. I've yet to see an explanation of why it isn't in the user's namespace, like User:Risker/Gather_1, User:Risker/Gather_2, etc. - if it's intended to be personal, it probably shouldn't be in what's essentially an administrative namespace.

Apr 7 2015, 3:30 AM · Patch-For-Review, Gather Sprint Forward, Gather

Mar 10 2015

Risker added a comment to T44894: Please restrict anonymous users from creating new pages at sw.wikipedia.

Given the report that the main editing community at swwiki is not technically knowledgeable, the majority of suggested alternatives here are far more opaque than helpful. Abuse filters only work if you have people who are knowledgeable and skilled enough to develop and manage them. Flagged revisions don't prevent page creation, and someone has to patrol the pages. ClueBot doesn't prevent page creation either.

Mar 10 2015, 8:22 PM · User-MarcoAurelio, Patch-For-Review, Wikimedia-Site-requests

Mar 9 2015

Risker added a comment to T91890: Wikitable padding.

@ kaldari, lots of people use the desktop view on mobile, especially on tablets - some of those screens are as big as a laptop's.

Mar 9 2015, 6:38 PM · Patch-For-Review, Design, MediaWiki-User-Interface

Mar 7 2015

Risker added a comment to T91890: Wikitable padding.

What I am seeing here is a lot of highly subjective opinion about what "looks better". On poking around on a few text-based software programs that permit table creation, the default seems to be 0.2 em pretty consistently. Tables that are in existence now were designed with the pre-existing defaults in mind (either finding them acceptable for the table design, or including variants from the default in the design), and any that used those defaults in their design will now have to be reviewed for formatting problems.

Mar 7 2015, 11:42 PM · Patch-For-Review, Design, MediaWiki-User-Interface

Feb 4 2015

Risker added a comment to T23928: oversight-l subscriber list: "Visit Subscriber List" results in "You must supply a valid email address.".

From https://lists.wikimedia.org/mailman/subscribe/oversight-l it is not possible to access the mailing list roster. One receives this message:

Feb 4 2015, 3:45 AM · Wikimedia-Mailing-lists
Risker added a comment to T78550: The undo link in the page history leads to the source editor and not VisualEditor.

Suggest that specifically the undo link should lead to the editing interface selected in the user preferences or, in the absence of preference, to the default editor.

Feb 4 2015, 2:07 AM · Patch-Needs-Improvement, VisualEditor-MediaWiki-2017WikitextEditor, VisualEditor-MediaWiki, VisualEditor