Change Details

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.

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. The username may have to be denormalized into the list table so that you can sort or search by username. 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.

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. The username may have to be denormalized into the list table so that you can sort or search by username. 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.