In-progress vote status via audit

[jeefy]

It would be AWESOME if we can do vote audits for in-progress votes. That way chairs/leads know who they may need to ping without having to crawl into individual issues.

[tegioz]

It can be tricky to do this "right", let me explain.

The audit page relies on the GitVote database. At the moment, votes results are stored in the database when the vote is closed. To add this feature, we could also store "intermediate" results (when the vote is checked, for example).

The problem is that the vote state (source of truth) while it is in-progress is in GitHub, not in our database, as reactions come and go anytime. We only know how it is going during votes checks (manual or automatic). If we store the vote results when the vote is checked, and display this information in the audit page, the report may be misleading as it's likely that it is based on stale results (i.e. some users may have voted after the last check). Trying to sync the vote state too often may lead to GitHub rate limit issues (there can be lots of votes in progress).

That's why we were only displaying the details of the closed votes.

Please note that GitVote already notifies users with binding votes who haven't voted yet on each vote check (via GitHub mentions, see screenshots below). This was meant to work as a reminder, to let them know they still can vote 🙂

[tegioz]

Another option would be to get the vote results from GitHub on demand, when requested from the audit UI (when the user tries to see the details of a vote in-progress).

It will be a bit slower (checking a vote requires a few GitHub API calls), but given that this won't be a common operation, it shouldn't create rate limits problems. We would need to cache the response for some time to prevent potential abuse anyway, so there is still the option that the data is stale, but it should be less likely than with the daily vote check.

[tegioz]

Closed by #681