myyk / git-democracy Goto Github PK

Good idea from @dominikwilkowski that I'd like to add in here to replace the complicated comment modifications: #763 (comment)

When I started this project, I didn't consider that I actually have both 👍🏽 and 👎🏽 in a review, so no need to add another vote tallying comment to get the votes from. I think the vote summary is still useful, so I will keep that.

This does require all voters to be PR reviewers for the plugin to work. That seems acceptable for a git-democracy using project though.

For private repositories, in some instances, voting only requires the majority of contributors, no matter which contributors is voting.

I would suggest making the .voters.yml optional, and automatically assume a weight of 1 for each individual voter.

Also polish up the usage if there's usability issues.

New votes are already triggered on

    types: [opened, synchronize, reopened] // these are defaults for pull_request_target if not specified explicitly

It would be better to make a few changes:

1. reopened perhaps should create a new vote since maybe it was closed for a while and old votes might not make sense anymore.
2. synchronize should somehow close other prior votes by marking them very explicitly as not an ongoing vote and create a new voting comment.
3. If not automatic in (2) we should make sure that the new vote comment is used throughout.

Hey there

I created a test repo over here: https://github.com/dominikwilkowski/test-voting-repo
that is failing on cannot find comment on issue = 2 as you can see here: https://github.com/dominikwilkowski/test-voting-repo/actions/runs/4825777737/jobs/8596966422

Any help here is appreciated

The badge dies, so replace the comment with one that shows voting is closed and lock it if possible.

We're evaluating using git-democracy to collaboratively make internal company decisions, but our problem is that we have different types of decisions that require different thresholds, and so we'll need many different voting.ymls and voters.ymls.

The way we're approaching organizing our documents, we could do it by directory - if a pull request has changes that modify the contents of a directory, the voting rules for that directory's voting.yml (or a parent directory, recursively) are used. For standard code applications, this may also work well for monorepos, etc.

If only one root voting.yml is present, that's what's used.

If the pull request has multiple changes in different folders which include different voting.ymls, we go up to the next highest and maybe root voting.yml.

A solution that would also work for us is to have multiple voting.ymls, like:

bylaws-change.voting.yml
new-project.voting.yml
...

and have some way of indicating which process was appropriate in a metadata convention on the PR.

If you're interested in having one of both of these as part of git-democracy, that'd be awesome!

If not, no worries - we'll fork and implement ourselves. Just wanted to check to see if you wanted :)

For v1, it was possible to pin to v1 and not to a specific minor/patch version. This is not available for v2.

This works:

jobs:
  democracy:
    name: Democracy
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Evaluate vote
        uses: myyk/[email protected]

This doesn't (but should):

jobs:
  democracy:
    name: Democracy
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Evaluate vote
        uses: myyk/git-democracy@v2

I'd recommend using Release Please to handle the versioning and auto-tagging of new releases. (I am willing to contribute with a PR if you're interested).