OK. Marking as stalled.

I think you also want to give view-voter-pii to scrutineer

Note that this task is now partially complete. It should be possible to create a user group just for editing an election, and an additional user group for both editing an election and scrutineering an election.

Note that if you use this config:

Still shows a stack trace, which may be a bit confusing to folks that don't know how to program. However it's an improvement since it now mentions $wgLocaltimezone, and links to the timezone allow list.

In T374408#10357793, @Wargo wrote:

In T374408#10355968, @Novem_Linguae wrote:

Unable to reproduce in localhost.

Screenshot?

The fix here is probably to add a check to the "Set filters" function that is something like...

I like Wargo's idea, but it would be a more complicated solution. So I think it's good that that's a separate ticket.

Unable to reproduce in localhost. Able to reproduce on testwiki and enwiki.

Last week's patch looks promising, but sounds like it may be hard to measure because it's going to kick in gradually.

I worked on this today, trying to implement the algorithm I described in the previous post. I couldn't find a good hook.

Some additional discussion can be found at https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Special%3ABadtitle_in_pending_changes_notice

In T341760#9269957, @Pppery wrote:

A log entry at the target was separately requested in T118132: Merging pages should add a log entry to the destination page. I personally don't see the point of any of these requests, though - history merging should if done properly be seamless and not need an annotation.

Good idea. But consider narrowing the scope of this ticket to just providing this feature for OpenSSL. I think the plan is to remove GPG support soon/eventually since Wikimedia servers no longer support it.

There doesn't appear to be a standard way to handle errors before the skin is loaded. Lots of variation.

Selena / Suman are investigating "some challenges on the database side".

I have never encountered this bug. Is there something that editors in this thread all have in common? Skin, browser, Special:Preference, gadget, userscript, wikis edited, etc?

Also, looks like the error message when visiting https://vote.wikimedia.org/wiki/Special:SecurePoll/login/1750?lang=*&site=* has changed from "PHP Notice: Undefined index: isSitewideBlocked" to "
[928aa0ce-7308-4ddc-af90-cb869ef324f4] 2024-11-19 14:28:25: Fatal exception of type "InvalidArgumentException""

Reproducing in production is easy. Just visit https://vote.wikimedia.org/wiki/Special:SecurePoll/login/1750?lang=*&site=*

In T379526#10308474, @kostajh wrote:

@Novem_Linguae has already started on this with https://www.mediawiki.org/w/index.php?title=Writing_an_extension_for_deployment&diff=prev&oldid=6846281.

I'd be in favor of getting this deployed so the electionadmin group exists. This would get the technical part out of the way. Then, onwiki and at the community's convenience, we can workshop a policy/guideline for which users it can be granted to.

Patch is written and merged. I'm leaning towards marking this ticket as resolved unless there's further comments. The patch changed things to look like this:

• Isn't it really hard or impossible to rename WMF-deployed extensions? Not sure it'd be worth the engineering time.
• Could result in a situation where there's 2 names for it floating around, kind of like what happened to Extension:Flow when they tried to rename it to StructuredDiscussions. I found that very confusing.

In T379671#10314205, @Pppery wrote:

Why now?

I would think it should still be documented until the extension is fully undeployed and archived.

I still can't reproduce this locally.

Option 1 - Current:

I just +2'd a patch to replace the eye icon with "Review".

Doesn't beta cluster refresh based on the master branch every 10 minutes? Might not need a backport for the link in that post to have the latest patch.

I took a look at this one today. The code (delete.js -> tagPage()) is set up to read some JSON in deletionTags.json, then use that to figure out what tag to add to the top of a page. To envelop the existing page's wikicode in a tag would require doing something custom for RFD. Possible but not a quick fix.

In T355150#9907769, @Tgr wrote:

On an aside, can this requirement be documented at Writing an extension for deployment, preferably with an explanation of what "basic support" means? It's disrespective of volunteer contributors' time, to put it mildly, if they only find out at the end of a long development and review process that their extension cannot be deployed for reasons they have no control over.

Yeah, InfoChip seems the way to go. Although I think we should override its background color to be the old shade. Perhaps we can declare a CSS var --background-color-warning-strong and then use that.

Most of these prefixes are commonly overridden with : true. For this reason, it'd be messy to include them in defaultMaps.

Awesome. Sounds good to me.