You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, there's no documented consensus on how a vote among the LoopBack TSC members should occur (i.e. how to cast a vote). In the past, we have used GitHub Teams Discussions and GitHub Issues Reactions. However, non of these meet the following requirements:
Authenticity: The authorisation to vote is only restricted by GitHub authentication. Requiring a PGP-signed Git Commit may be more resilient against account takeovers.
Secrecy during voting process: The votes are visible to other TSC members, which may sway their own votes.
Immutability: The votes can be modified after the voting itself has concluded. This is in part because the TSC members are delegated the GitHub Organisation Admin role, which means that locking a GitHub Issue does not prevent votes changes.
Vote tabulation UX: For GitHub Issue-based voting, there's nothing preventing non-TSC members from "casting a vote". This mean that tabulation would require filtering through the noise (e.g. through the use of the GitHub API).
This issue is to aid in discussing and deciding on a more robust solution.
Currently, there's no documented consensus on how a vote among the LoopBack TSC members should occur (i.e. how to cast a vote). In the past, we have used GitHub Teams Discussions and GitHub Issues Reactions. However, non of these meet the following requirements:
This issue is to aid in discussing and deciding on a more robust solution.
Prior art
K8's problem statement: Create app for holding Steering elections using only github auth kubernetes/community#5096
All of the listed solutions utilise the Condorcet election method.
Except Caritat, all of the solutions do not provide any method to validate the authenticity of the results.
The text was updated successfully, but these errors were encountered: