Change Details

In 2014, Brad introduced the "Populate list automatically" checkbox and PopulateVoterListJob, which provides a web UI for voter list construction. This would have almost met the present desire for a simple procedure for creating a board election. However in 2015, the voter qualification criteria were changed such that edit counts needed to be summed over all centrally attached user accounts. Under time pressure, I introduced the need-central-list feature without a UI, relying on an adaption of the previously used maintenance scripts to implement the new requirement for edit counts for a global user to be summed over all wikis. As a result, Brad's UI was not used. For the 2015 and 2017 Board elections, edit counts were collated by running the old maintenance scripts, with an adapted voterList.php summing edit counts over attached accounts. I propose providing a web UI for central voter lists, to be used in the next election after the current one (2024?). The amount of work which would need to be pushed into the job queue is comparable to Brad's original feature -- the same number of edits need to be counted. They are just added and stored in a different way.

There is currently no UI for the needs-central-list property in SecurePoll. This property allows lists to be stored only once instead of duplicated to all wikis. It would have been nice to have such a UI for the 2021 Board Election, but instead we used maintenance scripts. The requirements are: * Populate a central list according to globally summed edit counts in certain timestamp ranges. * Allow ~700 staff members and developers to be manually added to a list. Or allow SecurePoll to check two lists and have both a manual list and an automatic list. In 2021, edit counts were calculated using an adaption of the old maintenance scripts. These scripts take two days to run. Because Board elections are always organised at the last minute, it would be nice if edit counts could be calculated more quickly. Analytics has the [[https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Edit_hourly|wmf.edit_hourly]] table with hourly aggregated edit counts across all wikis. This would probably be much faster to query. The current UI for lists just has a big textbox with usernames separated by line breaks. That would be fine as an import interface for staff and developers, but as an edit interface for a list with 70k members, it is underpowered. For viewing and removing members, a TablePager with checkboxes and a search box is probably needed. Note that votewiki does not have CentralAuth enabled (for good reason) and yet we are storing lists in the centralauth database with a join against globaluser. SecurePoll on votewiki does not query the lists when a user comes to vote -- the jump wiki is responsible for telling votewiki what the user's lists are. It is conceptually awkward for voter lists to be on votewiki when votewiki does not even have a concept of a central user -- it is a completely separate authentication domain. Lists are not linked to elections by a foreign key relation -- lists are named by the election. Once you've made a list of 70k voters, it is convenient for testing purposes to be able to share lists between elections. So please consider putting an election-independent list builder UI on metawiki. When you create the election on votewiki, there should be a dropdown to select the authentication domain. When you select Wikimedia as the authentication domain, votewiki should query metawiki via an API for the list of available lists.

In 2014,There is currently no UI for the needs-central-list property in SecurePoll. Brad introduced the "Populate list automatically" checkbox and PopulateVoterListJob,This property allows lists to be stored only once instead of duplicated to all wikis. which provides a webIt would have been nice to have such a UI for voter list construthe 2021 Board Election., This would have almost met the present desire for a simple procedure for creating a board electionbut instead we used maintenance scripts. However in 2015, the voter qualification criteria were changed such that edit counts needed to be summed over all centrally attached user accounts. Under time pressure, I introduced the need-central-list feature without a UI, relying on an adaption of the previously used maintenance scripts to implement the new requirement for edit counts for a global user to be summed over all wikis. As a result, Brad's UI was not used. For the 2015 and 2017 Board elections, edit counts were collated by running the old maintenance scripts, with an adapted voterList.php summing edit counts over attached accounts.The requirements are: I propose providing a web UI for central voter lists,* Populate a central list according to globally summed edit counts in certain timestamp ranges. * Allow ~700 staff members and developers to be manually added to a list. Or allow SecurePoll to check two lists and have both a manual list and an automatic list. In 2021, edit counts were calculated using an adaption of the old maintenance scripts. These scripts take two days to run. Because Board elections are always organised at the last minute, it would be nice if edit counts could be calculated more quickly. to be used in the next election after the current one (2024?)Analytics has the [[https://wikitech.wikimedia.org/wiki/Analytics/Data_Lake/Edits/Edit_hourly|wmf.edit_hourly]] table with hourly aggregated edit counts across all wikis. This would probably be much faster to query. The amount of work which would need to be pushed into the job queue is comparable to Brad's original feature -- the same number of edits need to be counted.current UI for lists just has a big textbox with usernames separated by line breaks. That would be fine as an import interface for staff and developers, but as an edit interface for a list with 70k members, it is underpowered. For viewing and removing members, a TablePager with checkboxes and a search box is probably needed. Note that votewiki does not have CentralAuth enabled (for good reason) and yet we are storing lists in the centralauth database with a join against globaluser. SecurePoll on votewiki does not query the lists when a user comes to vote -- the jump wiki is responsible for telling votewiki what the user's lists are. It is conceptually awkward for voter lists to be on votewiki when votewiki does not even have a concept of a central user -- it is a completely separate authentication domain. Lists are not linked to elections by a foreign key relation -- lists are named by the election. Once you've made a list of 70k voters, it is convenient for testing purposes to be able to share lists between elections. So please consider putting an election-independent list builder UI on metawiki. When you create the election on votewiki, there should be a dropdown to select the authentication domain. When you select Wikimedia as the authentication domain, They are just added and stored in a different wayvotewiki should query metawiki via an API for the list of available lists.