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