In T368610#10016978, @SCP-2000 wrote:

@jrbs Hello, the vote is ended. Could you please grant the right to Scrutineers for checking votes? Thanks.

In T326412#10001381, @Aklapper wrote:

@jrbs: Hi, the Due Date set for this open task passed a while ago. Should this task be resolved per last comment?
If not, could you please either update or reset the Due Date (by clicking Edit Task)? Thanks!

Probably the best way to implement this would be to create an additional voting method alongside those which already exist. For T368610 we're using Histogram Range with dummy options which just read "Blank" and a question which just says "this has no effect". Definitely confusing.

In T368610#9979773, @SCP-2000 wrote:

@jrbs Hello, could you please add WiTo7946@zhwiki into the voter list? His username was changed recently. Thanks.

In T368610#9975726, @0xDeadbeef wrote:

After some internal discussion, this was a misunderstanding on @3301796's part. The configuration was correct and there is no need to change the options.

In T368610#9975680, @3301796 wrote:

The content of the poll has not written yet! (It should be您是否同意解任 Mys_721tx 的管理員？, 支持, 中立, 反对)

In T368610#9975673, @3301796 wrote:

There is an error on the poll. Can someone edit it?

In T368610#9972203, @SCP-2000 wrote:

@jrbs Hello, could you please change the end date to 26 July 2024 00:00. The voting period is 14 days. Thanks.

Should be done. Election admins (Jimmy Xu, AT, Wong128hk) may check everything looks OK.

I aim to set this up today.

I think this is OK. It will be during the end of the Charter ratification vote that is ongoing, but I think we were comfortable with votewiki being in English for these elections (the options etc would be in Mandarin as usual though).

In T344018#9938842, @Driedmueller wrote:

Hello!

Implementation is finished and ready for review: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/1049558

I chose not to implement a dropdown, because this would be more complicated. This would need to implement a form in the special page.
The solution right now looks like this:

Is this sufficient?

If the user wants to dump in blt format

• via cli, the dump.php command has now the option --blt
• via SpecialPage: title=Special:SecurePoll/dump/<ELECTION ID>&format=blt

Dumping in .blt is possible if

• there are votes
• election has only one question

In T368577#9928221, @Xaosflux wrote:

@jrbs - I think this is just a procedural thing, do you want us to remove this group from those users?

Sorry for my delay:

In T368305#9918953, @Novem_Linguae wrote:

This procedure might help with generating an SSL key: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/1003091/comments/f43b4da5_a507a52d?tab=comments

Escalating to UBN as an election is scheduled for midnight UTC.

Thanks all for the discussion and work while I was away.

In T359603#9883252, @kostajh wrote:

Just to check my understanding--that would mean setting disablemail excludes one from participating in the vote? (There is no other way to access the poll?)

My sense is that modifying the scripts that send email to respect the disablemail preference would be better than modifying the script responsible for determining the pool of eligible voters.

With the caveat that I am not a PHP programmer in the slightest, I think the best approach here is actually to add code to PopulateEditCount.php to also check for that disablemail preference on each wiki. It could then also check for the global preference as well, but we could also just hack that by querying the centralauth database and adding the result to the nomail list (or something like that) for now.

In T359603#9881214, @jrbs wrote:

I think my path of action, given the time pressure we have on this (needs to be in place for the MCDC vote, I'm told) would be to adapt makeMailingList.php to accept a file containing users who have the disablemail global preference enabled -- that is, the results of this SQL query:

SELECT gu_name FROM globaluser INNER JOIN global_preferences ON globaluser.gu_id = global_preferences.gp_user WHERE gp_property = "disablemail" AND gp_value = 1;

That outputs around 3,000 users. From a cursory check, some but not all of them are on the nomail list.

I think my path of action, given the time pressure we have on this (needs to be in place for the MCDC vote, I'm told) would be to adapt makeMailingList.php to accept a file containing users who have the disablemail global preference enabled -- that is, the results of this SQL query:

Possibly we can make use of the disablemail property in the global_preferences table. 3,000-ish users have an entry for this:

This is also the case for the recent U4C election, which has 1444 - 144 - 6 = 1294 votes listed, but the table shows there are actually 1295 unique usernames (from accounts whose votes were not struck).

Sorry, I was on sabbatical until yesterday.

In T361415#9674264, @Reedy wrote:

What are they planning on doing with the extension on the beta cluster?

Confirming here @Lhuyghe's comment, I think the steps sound very reasonable.

In T289388#9640251, @jrbs wrote:

I brought this up internally to work out our stance on this. I think the ideal solution here would be having a no-JS backup option (that users can be automatically driven to, or click a button to get, whichever is most feasible).

Hey @Skizzerz, thanks for submitting a patch. This task was listed in our contractors' work package and I was just wondering what the status of the CR is?

Ah! I tested this myself and it does already seem possible even if the options are "0" and "1", as long as the option to require votes is selected. So I think indeed this task is already resolved.

In T329922#9645557, @Driedmueller wrote:

Ok, cool!
So then, we would implement a "most active wiki" input field on the vote page and populate it with the wikis where the user has more than X% of their edits.
I would suggest introducing a config variable to define X, e.g. with value of 10 for the wikis with more than 10% edits from the user.
The users choice is not stored, for now.
We can get the necessary data from CentralAuthUser::queryAttached method. [...]

Scripts now running, should be done by EoW.

In T326412#9643631, @jrbs wrote:

I do wonder how those "blank" votes work out in the tally. The system does not seem to warn me when I submit a totally blank vote and I wonder if that vote even counts at all?

In T326412#9641675, @Miriamin wrote:

[...]
I understand that the goal of this ticket has already been achieved, but if I have misunderstood something, I would be grateful if I could get some more information so that I can solve the problem.

I created a poll with no default value and this is how the ballot looks like if I want to vote:

Thanks to @jsn.sherman for CR back in August, much appreciated!

Sorry for the delay in getting back to you here @Driedmueller.

Sorry for my delay as I investigated these questions @Osnard.

In T359211#9602928, @bd808 wrote:

@Bugreporter There is no similar comment in the log for blocking done directly in Phabricator, so I guess I'm wondering what you think people will write as a reason other than "spamming".

@phuedx Would you be able to help shed some light on the above? In particular, is the revert due to any code issues or just a case of product ownership changes (i.e. could we just re-merge that patch again)?

In T288784#9570365, @Krinkle wrote:

In T288784#7513397, @gerritbot wrote:

Change 724456 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@master] Remove DB writes to securepoll_voters on HTTP GET

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

For the record, this commit was reverted on the same day that it was merged (18 Nov 2021)

https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/739642
Change by @phuedx:
Revert "Remove DB writes to securepoll_voters on HTTP GET"

Reason for revert: T288784#7482853

This was performed successfully. Thank you!

Vote is complete! Thanks all.

I believe this is intentionally public yes. It's difficult to find (which may be a problem itself) but it's not intended to be secret

Done, sent 44,677 emails

In T348597#9471529, @Superpes15 wrote:

Hi @jrbs, I just noticed that we scrutineers have not yet been added as admins for this vote, thanks :)

In T355594#9479474, @Huji wrote:

Where in the code are these tables created? I don't recall the core code needing to create separate tables for elections. I know WMF has occasionally created tables (see ./cli/wm-scripts) but those are not for every single election either. And at least the present code (same link) only relates to 2022 and later.

I spoke with Legal and it doesn't seem that they would have a problem with deleting these old tables.

In T74449#9431902, @Aklapper wrote:

In T74449#8791700, @jrbs wrote:

Revisiting this very old task - I am not really sure what the ask is here - do you mean the history of edits to the SecurePoll election, or something else?

If nobody can clarify what's requested here, best to close this ticket as invalid?

In T310909#9367709, @Ammarpad wrote:

On the translate subpage, if $wgSecurePollTranslationImportSourceUrl is set, there's currently a message that presumably claims anyone can 'import translations'

You can import translations from http://localhost, translate manually or edit existing translations.

...but it's misleading, because you can't if you're not an election admin.

I'd suggest to show this message only if the user can actually do the action (along with the button)

Small update on this -- I can't find the task which changed this behaviour, but one is now able to update the election admins at any point. I believe this is possible even if the start date is in the past, but I will confirm this with the English Wikipedia elections which begin in about five hours.

No response so boldly closing this task given the successful implementation of T271276: Log when admins access voter data in SecurePoll.

Fantastic. Thank you!

I think that's fine if it wouldn't be locally controversial (I doubt that, since the rankings are already published)

The election has ended now. @jimmyxu / @Wong128hk - feel free to run your scrutiny of the new votes. We will see if the creation of a new tally works as expected once you are ready.

Hi everyone, is everything completed here? @Darafsh could you confirm the tally is OK?