Dump now complete

Related to T368098 apparently.

Closed this as declined, since this request was made by a globally banned user and no one supports this.

"All instances" is a bit misleading. That's searching for the "last3=Ist|" string.

This new limit is a significant pain in the ass. I'd be fine with throttling how often it can be used, but when browsing my own [over one quarter million] contributions, or any other highly-active editor's contributions [like a bot's], the ability to see more than 500 contributions at a time is a great time saver. Sometimes all I know if that I/a bot edited something in early 2019, but if I interpret that to mean January-March 2019, that can span 20,000 edits easily. Browsing 4 pages of edits is way better than browsing 40 such pages.

@Qgil, well one of the several links the user page could point to would be that Discourse / Wikimedia Space page.

Thanks for @Qgil for creating T232983. I agree that how to contact/ask question of the WMF it's better handled as a separate ticket/question.

Adapted from T227204#5494653

Re-opened, since this is a regression.

The talk page of the account would also be a general space to ask question to the WMF.

I suggest that this person creates/has access to the global account [[User:WMF]], so that people can easily ping the WMF on such issues.

Just reviewed the updated ticket. I very much like the new description!

This should be a very easy thing to implement and would tremendously help with the AFC backlogs!

The foundation should also consider making use of sitewide/watchlist notices for things like TOS changes and other high-priority stuff. Not everything needs to make use of those, but a TOS change is significant.

Indeed, the exact form of the distillation process really is up to the WMF, my 'internal newsletter' idea is only one possible form of it. A concern was raised that the WMF big wigs didn't have their fingers on the pulse, so this was one way of having that distillation process happen. If the issues are down in the 'gather' part of the process, then on enwiki your starting point is probably these two links

While related to the general issue of communications, my proposal above focuses on one specific aspect: Keeping the WMF people up to date on high-level discussions happening across the various projects. It's not that what results from this needs to be put to the exclusive use of the WMF, but what is interesting to the WMF may be completely different/irrelevant to what is interesting to most other people. So you could have the "communication officer" maintain a feed of high-level discussions on a widely distributed/publicized public space, to the benefit of everyone. I'll call this the "gather" part.

This is a phabricator ticket created in response to https://en.wikipedia.org/wiki/Special:PermanentLink/904657033#A_WMF_noticeboard_on_enwiki and also to https://en.wikipedia.org/wiki/Special:PermanentLink/904655589#Idea

Adapted from From https://en.wikipedia.org/wiki/Wikipedia:Edit_filter_noticeboard#Make_filter_table_sortable

The new Special:Relatedchanges is not very reliable... I might have to open a new ticket for that...

@Rjwilmsi
Well if you have something like

Going to ping @Reedy too on this.

@Rjwilmsi is there a regression here? The latest version seems to not do this anymore.

Can't do that dynamically AFAICT, that requires loading a second tool and we lose the one-click functionality.

That's rather trivial to prevent with edit filters.

Yes, clarified the original post, although I'm sure there would be uses for JavaScripts as well.

@Dinoguy1000 To my knowledge, JavaScripts need to be installed, which means templates can't make use of them.

+1 support for this feature. Would be very, very useful for <s>scripts</s> templates and modules, especially those that make calls to external APIs.

Would be absolutely amazing for Draft space and others. Support.

I strongly disagree with implementing this. It's an extremely bad idea to let new messages not interrupt runs. Bots depend on this behaviour, as do users in need of a trout, or users that are making a mistake without knowing they're making one.

@Reedy @Magioladitis hopefully this can make it in the next version

I'll point out here that I'm very available over the summer (I'll be much busier after August 15) to help with this.

In T195625#4250446, @Seraphimblade wrote:

Implementing this as a forced change would be entirely unacceptable. This change must be reverted, and going forward must be solely opt-in. [...]

This is possibly related to T63080 and T143409

Nope, doesn't work. If you have something like that, whatever you put in {{{1}}} will still be treated as wikicode to be rendered, before it gets passed to the template. It particular, if you want to say, codenowiki something like "(\d|-)", then the {{{1}}} parameter is '(\d'.

I'll point out that searching for

insource:"R from ISO 4"

It's not deployed now:

• https://en.wikipedia.org/w/index.php?title=Correlation_and_dependence&type=revision&diff=837431132&oldid=831279243

@kaldari Don't forget enwiki might want to transition to this system in the future, either because the new system is better, or because the bus factor (https://en.wikipedia.org/wiki/Bus_factor) kicks in.

I believe https://en.wikipedia.org/wiki/Template:Rp#Hyphens makes this ticket unneeded. This matches the guidance we have on other reference template, such as https://en.wikipedia.org/wiki/Help:Citation_Style_1#Pages

Since I can't be there to discuss this, I'll just say that as proposer, i believe the community supported something more in line with #2 (make a framework that individual wikis can customize), rather than have the WMF do all the customization work.

From my experience with workflows and such, #2 seems by far the easiest-to-code, most scalable option.

As a note, if you follow the #2 approach in T184304#3997523, the investigation doesn't really matter all that much. It might however reveal different ways workflows are set up, or some that can't be tracked with templates/categories, but that could be tracked in some other way.

Also, as a side note, it doesn't really require consensus in the usual sense, save perhaps on enwiki if you want to replace the existing system. For every other wiki, no such thing exists. Build the framework. If they want it, they can use it. If they don't want it, they can just not use it/ignore it.

'Lists of articles' are in theory workable. I've omitted it from the subscription methods simply because would be a real pain to maintain, and (at least on enwiki), it would simply duplicate the Wikiproject structure/functionality.

This is why I framed the proposed solution the way I did. "Have the WMF / larger Wikimedia community create a more solid and scalable framework for Article Alerts that can also be deployed to all languages." Framework is the important word here. It leaves the implementation details to the wikis.

Concerning "Can we think about making this work without wikiprojects but use categories instead? (Suggested in the proposal discussion)", really what the bot needs is a list of page, in any format. We [current system] do it based on

@EBernhardson well personally I don't run into this issue. Just offering a possible "compromise", increase that limit for trusted users (aka bots). Those searches could be increased to 100 000 / 1 000 000 / 10 000 000 or whatever makes sense. Perhaps with a limit of one such query per 10 seconds / 100 seconds / 1000 seconds or whatever makes sense.

How about limiting access to >10000 results to those with the bot flag?

This seems to be a ticket for a specific bot, rather than a bot framework issue that can affect several bots. I've removed the Bot-Frameworks tag from this, since I don't see what framework-level issue this addresses.