Change #1090512 had a related patch set uploaded (by SD0001; author: SD0001):

[mediawiki/extensions/SecurePoll@master] Don't use separate namespace for SecurePoll

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

I think this is fine as a separate namespace.

Most of the friction involving the gadget namespace was the fact that nobody could edit it, its name clashed with a video game, and it wasn't actually being used on most wikis. Neither of the first two will be the case for SecurePoll. And as long as the namespace is only enabled on wikis that use local elections, the third one won't be a problem either.

Even if users aren't going to particularly dislike it being a separate namespace, I question the need for it to be separate. ContentHandler is the recommended way to segregate pages these days. It wasn't fully the case in 2013 when the extension was written (the same year that MediaWiki core added native support for content models).

Pros:

1. Namespace names are localisable, unlike prefixes in MediaWiki namespace
2. ... Help electionadmins complete Bilorv's "Polyonymous" challenge faster? (There's no second point I can think of, but phab list syntax seems to require >1 entries so I'm forced to include this.)

Cons:

1. Takes away an entire prefix worth of allowed titles in main namespace. Since namespace names are localisable, they actually take away 2-3 prefixes for most languages.
2. Worse, localisations can occasionally change over time for small languages for which patches weren't reviewed by other speakers, leading to broken links.
3. Clutter the filters in Advanced-Search interface. It's not everyday people are going to search for election configs. When they do, they would use intitle: or prefix: operators instead.
4. Show up in other user-facing contexts which require a namespace selector – various special pages like Block (for partial blocks), Watchlist, Contributions, WhatLinksHere, RecentChanges, NewPages, PrefixIndex, AllPages, etc. In contrast, content models are transparent and less visible.

All these costs are worth it for things that really need a namespace – such as a large set of openly editable pages. But I don't see the justification here for a small number of JSON blobs which are only editable indirectly through the special page by the 2-3 people listed as election admins for the particular election.

Existing deployments (votewiki, testwiki) can continue to use the namespace. No migration of pages are needed as proposal is only for local wiki deployments (T301180) – on which no pages exist yet.

This task came up at VPT today.

I've dusted off the old patch; it's ready for review.

I'm ready to +2 https://gerrit.wikimedia.org/r/1090512. Trust and Safety Product Team, are you OK with that, or do you want some time to take a look?

Change #1090512 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@master] Don't use a separate namespace for SecurePoll

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

Hi @Novem_Linguae, when wgSecurePollUseMediaWikiNamespace is enabled, is it possible for a user with the securepoll-create/edit-poll right but lacking the editinterface right to create or edit a SecurePoll? Thank you.

In T378444#10961715, @Stang wrote:

Hi @Novem_Linguae, when wgSecurePollUseMediaWikiNamespace is enabled, is it possible for a user with the securepoll-create/edit-poll right but lacking the editinterface right to create or edit a SecurePoll? Thank you.

Tested just now. Works. Thanks for checking.

Can the page under Mediawiki:SecurePoll/* looks like json page, just similar to the original SecurePoll namespace? Currently it's a pure raw page, which is not pretty enough, and it’s hard to check whether each field is filled in correctly.

Not sure what you mean. The pages look like other JSON pages, eg. https://en.wikipedia.org/wiki/MediaWiki:SecurePoll/837.

In T378444#11031009, @SD0001 wrote:

Not sure what you mean. The pages look like other JSON pages, eg. https://en.wikipedia.org/wiki/MediaWiki:SecurePoll/837.

Seems to be my local cache issue, sorry about that. Looks nice in incognito mode