PR #78
31 votes · 18 up · 13 down
Comments(5)
Maybe you and https://github.com/skridlevsky/openchaos/pull/63 could collaborate and put all into his PR? I like the idea
I am deeply sorry @BetonZM, I have your PR open on a tab as I am thrilled to see this merged in the following round. And I wrongly tagged your PR in a rush, instead of the #63. (I have already edited the PR description to reflect what I really meant at that time)
🤖 OpenChaos Bot
Summary: This PR migrates the voting mechanism from GitHub reactions (thumbs up/down) to PR approvals on the latest commit. It updates the code to fetch approvals and the UI to reflect this change.
Files changed: 4 (README.md, src/app/page.tsx, src/components/PRCard.tsx, src/lib/github.ts)
Impact: Medium - Core functionality around voting is changed. Requires community understanding.
All Activity(39)
Maybe you and https://github.com/skridlevsky/openchaos/pull/63 could collaborate and put all into his PR? I like the idea
I am deeply sorry @BetonZM, I have your PR open on a tab as I am thrilled to see this merged in the following round. And I wrongly tagged your PR in a rush, instead of the #63. (I have already edited the PR description to reflect what I really meant at that time)
🤖 OpenChaos Bot
Summary: This PR migrates the voting mechanism from GitHub reactions (thumbs up/down) to PR approvals on the latest commit. It updates the code to fetch approvals and the UI to reflect this change.
Files changed: 4 (README.md, src/app/page.tsx, src/components/PRCard.tsx, src/lib/github.ts)
Impact: Medium - Core functionality around voting is changed. Requires community understanding.
Don't thumbs vague idea, vet code changes
Such a high standard open source project should not rely on people only voting on fancy PR names and vague ideas using thumbs reactions, but must approve code changes instead.
For the following two mains reasons :
Philosophy: Any high quality project have a strict code review process. Since this is a community project. A new pull request must have is code changes carrefully reviewed by a great number of peers before being set to be merged.
Security: Some concerns have been raised regarding sneaky changes once a PR is clearly enlisted to be merged. Using the GitHub approvals pipeline, every new change revoke the current approvals, and a sneaky new change at the end of the round will nuke the gained approvals.
So this change will both ensure high standard code changes, and no last minutes commits that are not approved by the peers.
This resolves : @Weetile:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3733522105 @haampie:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3733625930 @Headline:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3733637418 @yokeTH:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3733672322 @bigintersmind:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3733764787 @Victor4X:https://github.com/skridlevsky/openchaos/pull/6#issuecomment-3734075074
But obsolete : @yokeTH:https://github.com/skridlevsky/openchaos/pull/6 And require changes in : @Loeffeldude:https://github.com/skridlevsky/openchaos/pull/63
(Sorry for the @ mates, but it feels right to raise attention on your concerns ; won't do it again if it bother you)
(Maintainers must unsure read only users can approve changes ; should be on by default in the project settings)