As more and more PRs are created, some gain votes while the auther gets inactive and does not rebase. This prevents the PR from acutally merging.

I suggest a new rule:

If any PR is at least 1 week old and has more 🚫-Reactions than counted likes (👍 - 👎), the PR gets closed

This way old, inactive PRs could get closed if the community decides so. This also prevents instant closing of PRs by only considering PRs that are open for at least a week.

What do you think? Should this kind of rule be added?

There is also another option:

1. The Anti-Sniper Rule: To prevent "bait-and-switch" attacks, any PR modified within the final X hours of the daily merge window will be automatically skipped and rolled over to the next day.

2. The Panic Button (🚩): If a PR reaches a Y% threshold of 🚩 reactions, it is flagged as suspicious and locked. To regain eligibility, the community must provide a "Trust Surge": the PR must stay active until it gains an additional Z% in positive votes to override the flag and prove its safety.

Summary

Injects a dose of chaos into the browser tab title. This PR adds a DynamicTitle component that periodically replaces the static page title with a scrolling marquee of retro-themed slogans, enhancing the project's IE6 aesthetic.

A random slogan is picked every 10s and displayed for 3s.

Some example Screenshots

To take this a step further, what do you think about adding a 'Featured' section with 5 random picks? It would be a great way to highlight 'hidden gems' that aren't necessarily the newest or the most voted yet, giving them some well-deserved visibility.

1. A PR to revert the bad change should gain upvotes

A PR to roll back a bad change should normally receive upvotes, but a "bait-and-switch" can prevent this. An attacker might introduce an unchangeable rule that restricts modifications of that code exclusively to the original creator.

📝 Description

This PR introduces a classic Windows-style Blue Screen of Death (BSOD) "Easter egg" to the application. It's designed to surprise users who are actively engaging with the site after a short delay.

✨ Features

• Delayed Activation: The trigger mechanism only becomes active 10 seconds after the page loads.
• Activity Detection: Users must continuously move their mouse or scroll for at least 3 second to trigger the screen. Small, quick movements won't set it off.
• Authentic Visuals: Styled to mimic the classic Windows BSOD (Blue #0000AA background, Courier New font).
• Dismissible:
  • Click "here" at the bottom of the error message.
  • Press the Space bar.
  • Once dismissed, it will not reappear until the page is reloaded.
• Mobile Friendly: Includes overflow scrolling for smaller screens to ensure the dismiss button is accessible.

🛠️ Technical Details

• Added src/components/BSOD.tsx component.
• Integrated into src/app/layout.tsx to ensure it works globally across the application.
• Uses useRef for high-performance event tracking (hiding the BSOD doesn't cause excessive re-renders during mouse movement).
• Implements zIndex: 2147483647 (Max Int) to ensure it covers all other UI elements.

📸 Screenshot

PS: This time no btoa as in #8

I'll remove the Code section later.

Just to add to the discussion: If rules are against manipulating the voting system, how does it ensure no last minute modifications? If some PR has the votes, and the person behind it pushes a change (Not necessary modifying the vote system itself), it also in some way goes against the Idea of a democratic voting. Then votes would not reflect the true opinion about the actual code changes.

This PR enhances the PR cards by adding visual indicators for the "health" of a Pull Request. Users can now instantly see if a PR is ready to be merged or if it has issues that need resolution.

Changes:

• Backend: now fetches additional metadata for each PR: Checks for merge conflicts via the GitHub API. Checks CI/Commit status (success/failure) for the latest commit.

• Frontend: Added a status icon (✅ / ❌) below the vote count. Added descriptive text (e.g., "Merge conflicts", "Checks failed") to explain why a PR might be unmergeable.

Why is this important? In a community-driven project where users vote on PRs, it is crucial to know if a contribution is technically valid. This prevents users from "wasting" votes on PRs that:

• Cannot be merged due to conflicts.
• Have failing tests or build errors