Closing — reaction has been tepid to mixed, and supporting multiple layouts makes it tough to avoid breaking changes from newly merged PRs.
PR #184
11 votes · 8 up · 3 down
11
Total Votes
+8
Upvotes
-3
Downvotes
+8-3
Comments(7)
Yeah, that's fair. I don't think that would be a big deal, though. If votes were being reset more often, the totals would be lower, we wouldn't be getting as many super old PRs winning by default, and people would be more actively voting. At least, that's my theory, and a better state for the project, in my view.
That said, this PR may not quite get us there, but I think it's a preferred direction for the project and part of a wider solution, along with #158.
I think the tricky thing is that due to the nature of this project, any significant PR requires multiple rebases and tweaks between when its submitted and when it merges to stay up to date with main. For example my https://github.com/skridlevsky/openchaos/pull/130 has needed several fairly complex tweaks to keep the spirit of other PRs alive (e.g. when the Clippy PR landed, I made an ASCII clippy version). If the votes reset every time, I'd lose interest.
@Nickhoyer, sure, put it in the PR!
PR https://github.com/skridlevsky/openchaos/pull/109 demonstrated that a PR author can collect votes on a harmless diff, then force-push completely different code before the automated merge
um, i pinky-sweared that i would not do that.
🤖 OpenChaos Bot
Summary: This PR introduces a vote integrity mechanism that uses a hash of the diff to invalidate votes if the code has changed since the vote was cast. It also adds logic to the auto-merger to only merge PRs with positive votes that are mergeable and pass CI.
Files changed: 5 (.github/workflows/automerge.yml, .github/workflows/vote-integrity.yml, src/components/PRCard.tsx, src/lib/github.ts)
Vibe: This PR is a valiant attempt to herd cats in a democracy governed by internet whims.
⚠️ Large PR - partial review
All Activity(19)
Closing — reaction has been tepid to mixed, and supporting multiple layouts makes it tough to avoid breaking changes from newly merged PRs.
Yeah, that's fair. I don't think that would be a big deal, though. If votes were being reset more often, the totals would be lower, we wouldn't be getting as many super old PRs winning by default, and people would be more actively voting. At least, that's my theory, and a better state for the project, in my view.
That said, this PR may not quite get us there, but I think it's a preferred direction for the project and part of a wider solution, along with #158.
I think the tricky thing is that due to the nature of this project, any significant PR requires multiple rebases and tweaks between when its submitted and when it merges to stay up to date with main. For example my https://github.com/skridlevsky/openchaos/pull/130 has needed several fairly complex tweaks to keep the spirit of other PRs alive (e.g. when the Clippy PR landed, I made an ASCII clippy version). If the votes reset every time, I'd lose interest.
@Nickhoyer, sure, put it in the PR!
PR https://github.com/skridlevsky/openchaos/pull/109 demonstrated that a PR author can collect votes on a harmless diff, then force-push completely different code before the automated merge
um, i pinky-sweared that i would not do that.
🤖 OpenChaos Bot
Summary: This PR introduces a vote integrity mechanism that uses a hash of the diff to invalidate votes if the code has changed since the vote was cast. It also adds logic to the auto-merger to only merge PRs with positive votes that are mergeable and pass CI.
Files changed: 5 (.github/workflows/automerge.yml, .github/workflows/vote-integrity.yml, src/components/PRCard.tsx, src/lib/github.ts)
Vibe: This PR is a valiant attempt to herd cats in a democracy governed by internet whims.