And that’s over now. I don’t currently plan to run another announced test. Curiously, it says:
Election ended on December 14, 2024 at 1:31 AM UTC
So it ended about 3.5 hours after the configured ending time. Why? Don’t know, and no guess. My own time zone is UTC minus 5 hours, so that’s not it.
A few things are definitely wrong here:
Error making request: 401: Does not have permission (1aedfc99)So even if the software is good under the hood the UI and frontend in general has a few potentially serious issues before this site can be used. But a year of lead time and responsive developers should take care of this.
Thank you for trying! This one is shallow (I hope): I didn’t realize that I, as the election admin, needed to explicitly do something to make the results available after the election ended on its own. I clicked that button now, and the results should be visible to everyone now.
Bingo! Current local time for me too, but expressed in UTC (I messed up on what my UTC offset actually is before). I reported that via the “Feedback” button (lower right of page).
To my eyes, it’s gone very well so far for a beta release. I just contributed 100 bucks to help 'em out 
.
Primarily for @ArendPeter and @larry:
More thoughts on randomization: my little 16-bit generator has such a short period that “most” permutations of a 10-element list can never be generated. Essentially the same is true of all PRNGs, but in the case of the Mersenne Twister, with monstrously large period, it takes lists with a few thousand elements before most permutations are out of reach.
A saving grace for us is that we don’t much care about speed. Things like the Twister can be called trillions of times in a program run and speed matters a lot. Here we only need to shuffle a list of candidates, at most once per ballot.
There is a standard way to greatly increase the period and improve quality, which maybe takes twice as long: apply a “Bays-Durham shuffle” to the underlying PRNG. The real cost is that the .get() method can no longer guarantee to return unique results across 65536 consecutive calls.
This isn’t a problem for shuffling a list, but would be if you want a candidate -> unique_int mapping. I’m proceeding under the belief that shuffling is fundamental, and that if you want a candidate -> unique_int mapping instead, it can be easily built from a permutation (e.g., map a candidate to its index in the shuffled list).
So my working code now implements Bays-Durham (just a few lines of easy code), and a form of Fisher-Yates shuffling. It’s still working hard to avoid any Python-unique features or libraries, uses no floats, and never creates an int needing more than 32 bits.
A chi-square test confirms that across 16 * math.factorial(10) tries at shuffling list(range(10)), all possible permutations were generated “about equally as often” as truly random shuffling would do. Same for smaller lists.
Testing this kind of thing is much harder than writing it. Especially including the time tearing out hair when tests fail 
To my eyes, it’s gone very well so far for a beta release. I just contributed 100 bucks to help 'em out
Thank you! 
Bingo! Current local time for me too, but expressed in UTC (I messed up on what my UTC offset actually is before). I reported that via the “Feedback” button (lower right of page).
Feedback received, will look into it. I also confirmed it on my end.
- I can’t see the results, I am getting an error message
Error making request: 401: Does not have permission (1aedfc99)
I’ll work to update this error too. Perhaps “Election has results set to private” or something like that. I should also make it more clear for admins when the page they’re viewing are only visible to them.
So my working code now implements Bays-Durham (just a few lines of easy code), and a form of Fisher-Yates shuffling. It’s still working hard to avoid any Python-unique features or libraries, uses no floats, and never creates an int needing more than 32 bits.
A chi-square test confirms that across
16 * math.factorial(10)tries at shufflinglist(range(10)), all possible permutations were generated “about equally as often” as truly random shuffling would do. Same for smaller lists.
This is looking great! I’m happy to implement whatever version of TinyRand we end up with, and I’m also fine with moving away from candidate -> unique_int (we didn’t consider the possibility for the random generator to giving the same value multiple times 
)
Bays-Durham + Fisher-Yates sounds like a good way to go.
I created a GitHub repository so we can keep ongoing developments off Discourse:
Feel free to contribute implementations in other languages, in the src/ directory.
One thing I haven’t thought about yet is how to “version” the code. Sooner or later, some material improvement will be made, but I think it’s crucial that older results still be reproducible here. @larry can think about that too .
The Python implementation now exposes a factory function,
tinyrand.get(version=tinyrand.DEFAULT_VERSION, seed=0)
which returns an instance of the class implementing the given version. Testing was changed to exercise all supported versions.
A useful addition was creating a version 1, which uses 26-bit state. Since that never creates an int exceeding 52 bits, it’s suitable for a language (like JavaScript) whose native “number type” is IEEE-754 double-precision floats.
I’m at the limit for list sizes I can exhaustively test. Checking lists of size 11 requires doing 16 * factorial(11) = 638,668,800 shuffles, and even under PyPy that takes close to half an hour - and requires RAM to store a dict with about factorial(11) = 39,916,800 11-element tuple keys. That’s pushing the limit on the RAM I have too.
I think this is cute - this is the entire implementation for version 1:
class TinyRand1(TinyRand0):
VERSION = 1
BITS = 26
def __init__(self, seed=0):
super().__init__(seed)
So, at least in Python, supporting multiple versions “forever” looks to be quite easy.
And that’s been repaired. It displays the original end time now:
That’s great. The OFFICIAL RESULTS pages with the bar graphs look great as well. For documentation purposes, it might be a good idea to also include the starting and ending dates and times of the voting on each of those pages.
Probably better to make UI suggestions directly to them, yes?
Maybe, but rather than my sending a suggestion directly to them, it seemed preferable to either first allow an opportunity to form a consensus amongst us, or to allow Guido or you to make the decision. Too many cooks might spoil it.
Thanks for passing the suggestion on to them.
To be clear, I didn’t pass on the suggestion. The piece I quoted was in response to @MegaIng, saying that I passed on his bug observation: that the end time reported was current local time rather than the time the election ended.
My interest is in ensuring their service will be usable for us, and bugs are the only things I feel obligated to report to them. I’m not passing on others’ “UI improvements” that aren’t addressing clear errors.
It’s their project, and they have to balance “feature requests” across all their users. To do that, they need to hear from users directly.
I’m not saying I disagree with your idea (I don’t), but am saying I’m not a “contact point” for their project. @ArendPeter is, and may - or may not - notice your suggestion when he browses this topic.
I personally don’t want to see this topic become like an Ideas topic, with a hundred people bike shedding UI ideas, nobody responsible for “doing something”, and probably never reaching consensus anyway 
.
Ah, I see.
OK, will send the feedback to them directly.
Thanks! I got the feedback. It makes sense to me as well 
But yes, although I will do my best to keep up with this thread, please don’t be shy about using the feedback button on the website. I’m happy to receive all feedback (UI improvements, bug reports, general suggestions, etc), and that’ll be the best way to ensure that it’s on my radar
Waking up this topic, I believe we still don’t have an answer to my original question, which was, which tool to use, and (implicitly) also what do we tell Ee about how we want that tool to be used.
Have we settled on Bettervoting.com? Which things do we require them to fix before we are happy with them? Do we ask Bettervoting.com to run the election for us (at a fee, of course) or do we use their site to run it ourselves? (IIUC both options are open.)
Do we have a good understanding of the configuration we will need to use to satisfy all the requirements for the SC election set forth in PEP 13?
Is there still an option open to use @larry’s library? What would it take to host such an election, assuming Larry doesn’t want to be involved? (And as a core dev and voter, he probably shouldn’t be involved in running the election, other than by having written the code?) Or is this door closed?
Using the STAR voting service is the only option that’s been seriously discussed here, and it’s been discussed a lot. I posted an exhaustive account for @EWDurbin of every step needed to configure the service for what we want.
I have. Nobody else I recall has suggested anything else.
I ran test elections here and the STAR folks already fixed every gripe we had. Crucial feedback still needed would have to come from @EWDurbin. who needs to do his own playing with the system…
Not up to me. I assume @EWDurbin would run it. But If there are “enough” voters, the service will charge a fee even if we do run it ourselves (I understand that’s negotiable).
I’ll leave that for you to answer, since you made the PEP changes. As I recall, the PEP is very light on “requirements”.
I don’t believe there ever was, since @larry doesn’t want to run elections, and nobody else has volunteered to do so either.
In the background, we’re (the STAR folks, Larry, & I) still working on ensuring Larry’s library can be used to verity the precise results the STAR service claims. Anonymized ballots are already available for downloading when an election ends.
Since it’s purely hypothetical, I don’t see value in speculating about it. Obviously, “we” would need to write our own app(s) to host the election. Nobody I’ve heard from has any interest in doing that.
To be clear, I declined to volunteer to create and run a new online voting service for the Python community because I’m not really a web guy, and I’m definitely not a system administrator. I suspect Guido asked me if I’d be interested in the job because I wrote the election tabulation library we’d want to use–not because I was a good candidate for the web & sysadmin work. (Which, I’m really not.)
Okay, I will just let the SC know that this topic exists, for when they start thinking about organizing the next election.
According to PEP 13, the “election process is managed by a returns officer nominated by the outgoing steering council.” Since the current SC will be the outgoing SC[1], I think it would be fine to open a ticket on the SC tracker now, so that this at least gets on the agenda early. I’d suggest including any open questions you’d want the SC to address.
barring recalls or resignations ↩︎
Darn, not the next federal election?