Problem

Maintainers currently lack a clear, prioritized list of Pull Requests to review. Without a centralized queue, it is difficult to determine which PRs need immediate attention (e.g., critical bugs) versus those that can wait (e.g., low-priority features). This leads to delayed reviews for important fixes and an inefficient workflow.
Furthermore, GitHub's native /pulls tab does not support multi-level sorting, making it impossible to naturally view a perfectly ordered queue based on multiple factors like priority, type, and age.

Solution

Proposed Implementation:

1. Manual Labeling: Maintainers will manually apply standard labels for Priority (urgent, high, medium, low) and Type (bug, feature) to issues.
2. Project Board Configuration: We will create a new GitHub Project board equipped with custom "Single Select" fields for Priority and Type. We will configure the board's native UI to multi-sort the queue in this exact order:
   • Primary Sort: Priority (urgent > high > medium > low)
   • Secondary Sort: Type (bug > feature)
   • Tertiary Sort: PR Age (Oldest > Newest)
3. Automated Label Syncing: We will create a lightweight GitHub Action (or update our automation bot) that triggers when a PR is opened or updated. The bot will simply read the standard labels from the linked Issue and update the corresponding Single Select dropdown fields on the Project Board.
   Because modern GitHub Projects natively handles the multi-level sorting via its UI, the bot's job is restricted purely to field syncing. This ensures a highly maintainable architecture with zero "math" or custom scoring formulas.

Alternatives

1. Mathematical Heuristic Score: We considered building a bot that calculates a dynamic numerical score based on PR title prefixes (fix:, feat:), difficulty multipliers, and age. This was rejected because it introduces hard-to-maintain custom logic and "magic numbers."
2. Pinned Queue Issue: We considered having the bot auto-update a Markdown table inside a pinned GitHub Issue. While viable, it is less interactive and doesn't leverage GitHub's native V2 Project features.
3. Custom Bot Labels: We considered having the bot generate dynamic queue position labels (e.g., Queue: 1, Queue: 2), but this was rejected as it would cause massive API rate-limit spam every time a new PR caused the queue to shift.