Just found out its a bug in VisualEditorPlus. Sorry for the inconvenience. Ticket can be closed.

Yes, i think so.

"wiki" is coming from CentralAuth. Its the wiki ID (database name).
"domain" is coming from $wgServer config. Its the base URL of the server, including protocol but without the trailing slash and without the subdirectory if any (e.g., https://www.mediawiki.org).

I updated the existing phpunit test for tallying.
I added a comparison between the new declaredWinners array and elected winners end result array to the existing test. They have to be equal. This tests the added functionality.
However, there is no test case which could reproduce that an election outcome has been wrong without storing declared winners between rounds and would now be correct.
Im not able to create such a test case.
This bug seems to occur only on elections with thousands of votes.

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

Hello!
Great that we have seperated tickets for the tasks now, thanks for that.

Rebase done.

Thanks for your answers!

Ok great, then

In T291821#9745815, @jsn.sherman wrote:

Hi there, @TAdeleye_WMF asked if I could provide code review support on this, which I'm happy to do whenever there is a patch against the master branch. However, I don't have a clear way to reproduce the issue against master. Could @dom_walden or @Driedmueller offer me (a person with mediawiki experience, but no subject matter expertise for SVT polls) a concise way to reproduce the "declare winners" issue locally? I updated STVTallierTest_drw.php to the point where unit_test_stv.sh, but it eventually dies out (I'm assuming due to memory issues). Maybe an updated/smaller test file? The patch looks good on a read through, but wouldn't be comfortable giving a +2 just based on that. It looks like there are some good findings here from live testing, but most of the discussion about that seems to be dealing with the rounding error.

In T291821#9649754, @dom_walden wrote:

In T291821#9645629, @Driedmueller wrote:

I would also present and discuss a thing i also noticed, when i tried to reproduce the alternating surplusses between 0 and 1.7053025658242404E-13.
The reason for this behaviour lies in the incapability of PHP to do correct arithmetic operations on floating numbers.
A famous example of this is in PHP: 0.1 + 0.2 = 0.300000000000004.

I thought most/all programming languages had this problem. I tried this on python 3.9:

>>> 0.1 + 0.2
0.30000000000000004

We did look into implementing the PHP BC library for arbitrary precision arithmetic. But apparently it wasn't successful T289185.

I had thought that OpenSTV used fixed-point arithmetic instead, which I have read in some places might be better for this sort of thing. But, when I re-read the code, I cannot find evidence for this. Moreover, I am not a numerical analyst :).

Implementation is nearly finished.
This is what it looks like currently:

I would propose not to create the independent cli/tallyBLT.php for now in a first step, rather enhance existing cli/tally.php in such way

• that there is additionally the option to use .blt as input (besides a election name or the dump from cli/dump.php)
• and additionally the option to get the result as "Opavote's Online Elections (JSON)"

Note: The other output options right now are

• HTML, which does throw an error on my machine, but i did not yet look into it (PHP Fatal error: OOUI\Exception: OOUI\Theme::singleton was called with no singleton theme set. in /app/wikimedia/vendor/oojs/oojs-ui/php/Theme.php:31)
• and default: Text, which is actually HTML

Im able now to reproduce the issue with both ballots and could debug the process.
The algorithm and calculations thats going on there is rather complex, so that we can not provide a solution involving mathematical magic, but we suggest to implement the first solution, like OpenSTV: persist the winners from round to round.

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. e.g.

$centralUser = CentralAuthUser::getInstanceByName( $user->getName() );
$attached = $centralUser->queryAttached();

One technical question:
Where does the logging of the users "homewiki" actually occur in the code? We were not able to find it.
Like the data to create statistics that can be seen in recent UCoC ratification vote. Where does that come from?
In VotePage::logVote there is this snippet which inserts logging data into the database:

		$dbw->insert(
			'securepoll_votes',
			[
				'vote_election' => $this->election->getId(),
				'vote_voter' => $this->voter->getId(),
				'vote_voter_name' => $this->voter->getName(),
				'vote_voter_domain' => $this->voter->getDomain(),
				'vote_record' => $encrypted,
				'vote_ip' => IPUtils::toHex( $request->getIP() ),
				'vote_xff' => $xff,
				'vote_ua' => $_SERVER['HTTP_USER_AGENT'],
				'vote_timestamp' => $now,
				'vote_current' => 1,
				'vote_token_match' => $tokenMatch ? 1 : 0,
				'vote_struck' => 0,
				'vote_cookie_dup' => 0,
			],
			__METHOD__
		);

By looking at this, i could guess that 'vote_voter_domain' => $this->voter->getDomain() contains the info, maybe. In this case the corresponding data to create homewiki statistics is stored in the db field vote_voter_domain.
If you could point us to that, that would be really helpful :)

Do you mean you were able to reproduce the bug?

I tried again with dcbad8c and ba9476b58d2d (with patch given) and get the same results.

I had a look into this topic and i would like to ask some questions / do proposals.

I tried to reproduce the bug, but was not successful yet.
I checked out the state of the STVTallier algorithm from Aug 19, 2021 (https://gerrit.wikimedia.org/r/c/mediawiki/extensions/SecurePoll/+/712409) to make sure the bug has not been fixed meanwhile.
I tried it with the two given ballot files (20_6_5000_1301235635.blt, 20_7_5000_425367464.blt).
For this i used the cli commands to reproduce the case:

php generateTestElection.php --ballots=/app/wikimedia/20_7_5000_425367464.blt --admins=WikiSysop --election=stv  --name=TestTally
php tally.php --name=TestTally

The result seems fine for me. All declared winners got carried over to later rounds.
Is there may be another (and more simple) example ballot, with which the bug could be reproduced?