Ok, Samwilson pointed out this is an en-WS side problem: https://en.wikisource.org/w/index.php?title=Wikisource:Scriptorium&diff=10910337&oldid=10910334&diffmode=source

This is still broken, see https://en.wikisource.org/wiki/Page:Seventeen_lectures_on_the_study_of_medieval_and_modern_history_and_kindred_subjects.djvu/178

Oops, this is T220767. Closing....

It is a problem: firstly because of transparency, per Xaosflux, and secondly because it is a change that was not advertised in the consultation. This change was about removing the ability to edit, not the ability to view; why should that not also apply to deleted pages?

I think this is a dupe of T198688.

For clarity, I believe this is restricted to page creation; I have not been able to reproduce it on already existing pages.

Similar behaviour confirmed on my various mobile devices. Inspecting the source, the <div> tag ( of class "oo-ui-widget oo-ui-widget-enabled oo-ui-inputWidget oo-ui-textInputWidget oo-ui-textInputWidget-type-text oo-ui-textInputWidget-php") which immediately surrounds the <textarea> has CSS attributes "width: 100%; max-width: 50em;". Just getting rid of the max-width property in my browser console worked for me, so just remove that rule? Though why anyone put it there in the first place baffles me.

Indeed, thank you!

In T120288#3296015, @Koavf wrote:

there is nothing stopping anyone from cropping one-pixel line off an image and calling it "CC-BY, my own work"

@SPoore I wasn't under the impression that "the current configuration is that the blacklist is an openly-viewable subpage in userspace". Maybe that's how Legoktm's patch is set up, I don't understand the code. In any case, the community discussion at the wishlist did not answer the public/private discussion; it is my opinion, and the opinion of the only user who expressed a definite preference there, that the blacklists should be private. I personally do not even believe that admins ought to be able to see other people's blacklists: currently users' Echo notification preferences are complete private (AFAIK?) and I don't see any reason for this to change.

I can't speak to the underlying technical considerations, but from a user's point of view, and considering your comments, I'd much rather have it at Special:RangeContributions than have to wait possibly additional months for it to be released: given how often the Labs tool goes down, this feature is badly needed in MediaWiki.

There were two flow boards: the ORES talk page has been moved to mw.org and the contributions can be seen there (also in Special:Contributions). As for the development test page, I daresay I won't miss that. The comments on there were: 1 thread of complaint and 1 thread of test. Given the clear, explicit consensus to remove the extension in the RfC, this isn't an excuse not to honour it.

In T130470#2909982, @Aklapper wrote:

[offtopic] @BethNaught: Please criticize ideas, not people. Thanks for keeping Phabricator a respectful place.

I'll copy what relevant things I wrote in the discussion Nemo bis linked:

FYI, enwiki filters 755 and 756 are mine and they're not affected AFAICT: they don't use variadic functions and the ,) arises inside a regex. May I also suggest sending any enwiki message also to the Edit Filter Noticeboard? Thanks.

In T153438#2880816, @Aklapper wrote:

I'm surprised that someone expects "community approval" for software changes and I wonder what exactly this expectation is based on.

Moreover, when the watchlist used to completely reload, that updated my notifications. Not sure if that happens any more on marking the watchlist as read?

Negatively influences workflow: requires extra clicks to perform a task. IMO risk of accidental clicking is small and doesn't really damage anything. Those who had a problem with this already had a user script available which inserted a confirmation window.

In T153438#2880543, @Krd wrote:

Please revert this change globally. Totally unusable, complaints on all major wikis.

This is T150045. Related discussion at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical).

In T150045#2876153, @Sn1per wrote:

Adding

$(function() {
    $watchlistReset = $('#mw-watchlist-resetbutton');
    $watchlistReset.submit( function ( event ) {
        $watchlistReset.off( 'submit' ).submit();
    });
});

to common.js should restore original functionality (although the confirm dialog does pop up, the page immediately reloads).

How can I opt out of this? It's really annoying. Please provide an opt-out option in preferences.

Simply with the large number of options and checkboxes on for example the watchlist panel, an OOUI version risks taking up all of my screen (in landscape mode). I couldn't find a document describing the design vision for this, and so I don't know if this has already been considered, but I would suggest making an option to have smaller checkboxes and other widgets. This would help combat the bloat seen in e.g. T117790: Convert Special:EditWatchlist to OOUI and complained about re T134525: Convert Special:DeletedContributions to OOUI.

For my taste and I suspect for many other users' the new normal edit mode is far too big. For users with long watchlists, the fact you are more than doubling the vertical space used is a serious decrease in usability, as excessive amounts of scrolling will be required. And the reason for all this?

In T150421#2804863, @Ciencia_Al_Poder wrote:

In those situations, I reply on the talk page, not from email

In T150421#2794768, @Nemo_bis wrote:

Why send an email if you don't want to see replies?

In T120867#2663118, @Whatamidoing-WMF wrote:

It might also be appropriate to have such a discussion at Meta. This decision affects editors at all projects, not just Commons users.

The description of T135170 wrote "Any gadgets/JS for users with 'purge' rights can be updated to use POST instead of GET." This ignores the fact that many pages have direct purge links, such as https://en.wikipedia.org/wiki/Category:Pending_AfC_submissions in the progress indicator. Action should be taken to restore these to their prior behaviour. At the very least @Glaisher 's script or something like it should be incorporated into site JS for logged-in users.

In T29987#2482574, @kaldari wrote:

Fuller list of filters that will need to be fixed at P3522. (The list is restricted access since some of the filters are private.)

Guys, your list above is missing some filters. Specifically, as an example, enwiki filter 58 uses ccnorm, but is private, which I suspect is why Pathoschild's query above didn't catch it. Please make sure you fix all the filters including private ones.

In T141576#2538735, @Xaosflux wrote:

Any word back from the foundation staff on this @BethNaught ?

In addition to the legal concerns, on which we are now awaiting input from the legal team, has it occured to you that a) private drafts are inherently un-wiki (but that's a side issue here), b) that on a point of principle we find it highly concerning and disasteful that such activites could be carried out on Wikipedia. It is not like tapping people's phones, because Wikipedia is not a social network nor a telecommunications service; it is a collaborative project to build an encyclopaedia, and (theoretically speaking) all activity on it should be pointed in that direction. Also "insult" is a strawman, this isn't about trying to be Thought Police; note also that drafts are shareable (via shared passwords) and I believe (though I can't find the ticket) that the language team are planning to implement collaborative translation drafts in the future.

P.S. In addition to my above comments, given that public drafts would require moderation, the question arises as to who would do it. The EnWP community strongly rejected the WMF's presumption it would moderate Gather. Perhaps since CX is more content-focused they would be more willing, but that is not a given.

Some comments about the long-term changes this will require.

At VPT the problem has been reported with Chrome 51; I am also experiencing it on Firefox 47.

Not going to happen. I see you got the article you were concerned about userfied [https://en.wikipedia.org/w/index.php?title=Poligon&action=edit&redlink=1]. In the future you can always request a copy from the deleting administrator.

As to how to solve this, either we make it so the admin does not see a warning (making it consistent with non-admin autoconfirmed accounts) or we make the warning say "restricted to autoconfirmed users". I don't see the utility in having a warning when the page is restricted to autoconfirmed only, so I suggest just removing it.

In T136375#2333909, @K6ka wrote:

At the very least, couldn't there be an option in Special:Preferences to revert this change?

Changing it to require confirmation when opening in a new tab or window was a terrible idea which really should have been consulted on beforehand. It breaks the workflow of opening a user's contributions and opening all the rollback links in a new tab. I'm also getting inconsistent behaviour of rollback links on history pages.

I posted a bug about this at T113718 before seeing this.