On Wed, 20 Oct 2021 at 10:10, Dan Garry (Deskana) djgwiki@gmail.com wrote:
You're definitely right about that. SecurePoll is a mess. I was the product lead for a project to improve it in 2014, and whilst we did manage to make quite a few improvements to the functionality and management, we only got a fraction done of what we wanted to, the tool is still sorely deficient. There's documentation about the project https://www.mediawiki.org/wiki/SecurePoll_2014_Redesign, if you're interested. I'm not surprised that WMF leadership is very reluctant to improve it, and if I were in their shoes, I'd be avoiding it, especially since none of the people involved in the 2014 project work at the WMF anymore.
I think we need to get over the "not invested here" https://en.wikipedia.org/wiki/Not_invented_here tendency when it comes to running elections, and research to see if there's a good third-party solution. I suspect we'd actually save money using a third-party solution compared to trying to improve SecurePoll. I've not done a competitive analysis, so I don't know what sorts of things are available, and maybe there aren't any. But, at least, we should look.
Or, scope out designing a lightweight tool hosted on Toolforge or similar infrastructure, that integrates with the wikis and other data sources via the API, rather than actually being a MediaWiki extension. So many of the things that SecurePoll does (voter eligibility list generation, authentication, vote collection and collation, etc.) can be done using API integrations or data dumps; there's nothing instrinsic to it that requires it to be a MediaWiki extension, it was only done that way because that's the way we did everything back when. Developing a tool like that on Toolforge is so much easier and less complex than developing a MediaWiki extension. There's so many successful examples of this way of doing things; pageviews.toolforge.org is a good example.
(Sorry for the follow-up email spam, the thought occurred to me as soon as I hit send.)
Dan