henryivesjones

For #1 for me an open question is whether #1 on the website === winner. I had thought that the winner was decided purely based on the github data. As long as the winner is decided on the github data, then you can do whatever you want on the website side. Manipulation of stats and display is simply affecting perception and exposure. Much like fake news and biased reporting do in democracies.

For #2 People are voting for a specific code change and I believe votes should be tied to the specific state of the PR. The votes should be tied to the specific commit sha. This does introduce a longevity problem as commits that dont win will eventually get conflicts and not be eligible.

Thus, I think that votes should be tied to commits and once it had conflicts it is closed. It acts like a automatic cleaner and allows for the easier introduction of new ideas.

@FelixLttks he agreed to let it be included.

A win for democracy!

@skridlevsky

You have set out a defined charter (laws) for how this system works, specified in the README. It appears to me that you have your own values and assumptions for how you think that this project should be run and you are applying them arbitrarily to the system instead of enforcing the rules defined in the charter.

That behavior was intentionally hidden (base64 + obfuscation), which breaks the transparency a democratic system depends on.

I would argue that your enforcement of an unwritten rule breaks the democratic system which you have set up, not an opaque and obfuscated change.

In your response you have outlined several of your own beliefs about democracy and how you believe the system should work. These are not enshrined in the rules set out for the project and your enforcement of them is unequivocally un-democratic.

OpenChaos only works if voters can see and understand what they're voting on.

This is your belief and not in the written rules of the project.

I do have veto power, and I'm using it to preserve the conditions that make voting meaningful, not to override votes. Letting undisclosed manipulation ship would signal that visibility can be shaped as long as it's hidden well enough.

You are interpreting your intent and not your actual action. While your intent is not to override votes, your action is to explicitly do this. I would argue that your intentions are irrelevant and your action is what matters.

You are directly undermining the democratic process in favor of what you think is right. I think that it is especially ironic that you are doing so and simultaneously claiming to be "upholding the democratic process".

If this PR meets the rules as they currently stand:

Vote: Add a 👍 reaction to support a change, or a 👎 reaction to oppose it Highest Score Wins: The winner is determined by (Total 👍) - (Total 👎) Ties favor the New: If scores are equal, the newest PR (created most recently) wins CI must pass: If the build fails, the PR is not eligible No merge conflicts: PRs with conflicts at merge time are skipped; the next highest PR wins No malware: Maintainer can reject obviously malicious content

And meets the "What can be changed" criteria:

Everything. Including these rules.

Then I see no reason that this PR not be merged if it has the highest score.

Not merging this PR.

@marcaddeo caught hidden code that manipulates the ranking - PRs by @FelixLttks sort to top regardless of votes, plus a featured visual style.

The health indicator feature is legit and welcome. The sorting/styling manipulation is not. This falls under "No malware: Maintainer can reject obviously malicious content."

Remove the btoa hacks and this ships. Until then, skipping to next eligible PR.

This feels like an overreach. Is altering business logic really malware?

All of these links pointing to irrelevant sites such as "github"... Clearly they would better serve the community when pointed at more relevant and important content.