@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
Oct 24 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.
May 13 2019
@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 12 2019
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.
Dec 6 2018
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.).
Nov 27 2018
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.
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.
Jan 4 2018
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.
Oct 10 2017
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.
Sep 27 2017
@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.
Jul 24 2017
Jul 23 2017
@Jalexander: the workaround is to suppress the log event manually, no? Doesn't seem worth keeping private accordingly unless I am misunderstanding..
Jul 13 2017
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.
Jul 6 2016
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 4 2016
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.
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.
Jul 2 2016
Mar 21 2016
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.
Feb 27 2016
Dec 4 2015
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?
Nov 19 2015
Nov 10 2015
(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 8 2015
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.
Sep 18 2015
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.
Sep 3 2015
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.
Aug 27 2015
Aug 3 2015
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.
Jul 12 2015
@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.)
@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.
Jul 8 2015
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 7 2015
@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.)
Jun 30 2015
Change 222025 had a related patch set uploaded (by CSteipp):
Log privileged users with short passwords
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?
Jun 14 2015
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 10 2015
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 8 2015
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 4 2015
Jun 3 2015
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.
May 19 2015
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.
Apr 7 2015
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.
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.
Mar 10 2015
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 9 2015
@ 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 7 2015
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 1 2015
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.
Feb 4 2015
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.