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.

In T309416#8761559, @jrbs wrote:

In T309416#8761398, @Risker wrote:

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.

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.

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.

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.

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.

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.

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.

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.

In T282624#7163881, @ChristianFerrer wrote:

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.

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

In T112147#7070245, @Jdforrester-WMF wrote:

In T112147#7070221, @Risker wrote:

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.

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.

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

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.

In T262733#6455835, @Legoktm wrote:

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.

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.

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.)

@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.

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.

In T223043#5175163, @ToBeFree wrote:

@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.

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.

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.).

In T150826#4779072, @Bawolff wrote:

In T150826#4778848, @Adotchar wrote:

In T150826#4778796, @Bawolff 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.

In T150826#4776651, @Tgr wrote:

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.

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.

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.)

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.

In T171027#3673060, @Lydia_Pintscher wrote:

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.

@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.

In T171405#3464081, @lfaraone wrote:

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

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

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.

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.

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".

Please don't be patronizing, Scott.

In T131132#2425750, @Scott wrote:

In T131132#2425266, @Risker 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.

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.

What's the privacy policy for this survey?

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.

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?

(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.

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.

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.

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.

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.

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.

@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.)

In T62373#952148, @Trijnstel wrote:

@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.

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.

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.

@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.)

In T94774#1415859, @gerritbot wrote:

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

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

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.

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?

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.

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.

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.

In T85929#1331506, @Moushira wrote:

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.

In T99690#1297246, @Risker wrote:

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).

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

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.

In T95250#1184721, @JKatzWMF wrote:

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.

@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.

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.

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

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.

I'm disturbed that this "improvement" was made without any attempt to identify the impact of the change. As it stands, about half of the tables I've viewed on English Wikipedia have been affected negatively by this change. That is suboptimal for both editors and readers. Readers wonder why our tables look so awful and even less professional than they did before, and the majority of editors have no idea how to resolve the problems, since only a small minority of active editors work on templates.

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

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.