Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bot software to track votes and score #9

Open
3 tasks
mburns opened this issue Aug 16, 2015 · 9 comments
Open
3 tasks

bot software to track votes and score #9

mburns opened this issue Aug 16, 2015 · 9 comments

Comments

@mburns
Copy link
Owner

mburns commented Aug 16, 2015

Terms Definition
Player A Github user that has forked this repo
Vote a comment that contains `/(+
Abstain a comment that is not specifically a for/against vote (doesn't contain `/(+
Quorum >=N% of active Players having Voted. N is currently 100.

Pull Requests

When Quorum is reached,

  • tally the votes and post a comment with {total for, total against, % for, % against, winning side, etc}
    • Abstaining from a vote would be a comment from an active Player that doesn't include /(+|-)1/
  • close the PR to further comments
  • Determine points to reward Players & update SCOREBOARD.rb.
    • Users with 0 points don't need to be listed.
@mburns
Copy link
Owner Author

mburns commented Aug 16, 2015

https://github.com/jirwin/treslek-github seems like a good place to start.

@jirwin
Copy link
Collaborator

jirwin commented Feb 19, 2016

Should votes be reset when the PR gets a comment?

@mburns
Copy link
Owner Author

mburns commented Feb 19, 2016

The votes should only have an effect when the PR reaches quorum. Computing the vote's whole score from scratch on each new comment would work.

An active player should be allowed to comment on a PR multiple times, but only have one vote (their last one cast chronologically?)

Scores don't change until a vote is completed (and thus, commenting is locked and votes are tallied).

@jirwin
Copy link
Collaborator

jirwin commented Feb 19, 2016

Let me try and explain the situation I'm concerned with:

3 active players: 1, 2, 3

Player 1 submits a proposal.
Player 2 votes +1.
Player 3 leaves a comment suggesting an edit that would make it +1 for them.
Player 1 agrees and updates the rule.
Player 3 votes +1.

At this point every player has voted(assuming the author gets an automatic +1), but Player 2 has voted +1 for a different rule.

My thought is that after each time the sha1 changes(commit, force push), the quorum counter should be reset so that we know every user has voted on the most recent version of the proposal.

@mburns
Copy link
Owner Author

mburns commented Feb 19, 2016

Oh wow, you're absolutely right. Rebasing or committing over top the original file should nullify previous votes. So ya, we should recompute.

I can also imagine it getting tricky to read top-to-bottom if there are commit edit mid-way though voting. We should encourage meta discussion be separate comments from votes, so that they don't get intermixed too much.

@jirwin
Copy link
Collaborator

jirwin commented Feb 19, 2016

I can also imagine it getting tricky to read top-to-bottom if there are commit edit mid-way though voting. We should encourage meta discussion be separate comments from votes, so that they don't get intermixed too much.

To this point, I think we should make votes be only /(+|-)1/. Anything else makes it doesn't count as a vote.

@mburns
Copy link
Owner Author

mburns commented Feb 19, 2016

+1

@jirwin
Copy link
Collaborator

jirwin commented Feb 19, 2016

https://github.com/jirwin/treslek-nomic

Currently this will get the active players, and parse the scores.

TODO

  • Update scoreboard
  • Track votes within a PR
  • Lock a PR once a vote has completed

@mburns
Copy link
Owner Author

mburns commented Feb 21, 2016

possible inspiration:

@mburns mburns mentioned this issue Jun 29, 2017
6 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants