# The Bevy Bug Hunt This document is a proposal for a Bug Hunting Week within the Bevy contributor community. :::info This proposal is currently put on hold. If you're interested in helping run this event, please reach out to BD103! ::: ## Motivation Bevy is largely volunteer-driven, meaning most changes are implemented because a developer _wants_ them as compared to the engine _needing_ them. While these views mostly overlap, certain categories of changes go underappreciated. (Mainly bug fixes, code quality, testing, and infrastructure.) This event aims to encourage more bug fixes, shrink the ever-growing [issue tracker], and increase engine stability. [issue tracker]: https://github.com/bevyengine/bevy/issues ## Incentives In order to encourage contributors to participate, this event will be a competition with a public leaderboard. Competitors will earn [points](#scoring) and can view their ranking online[^online-leaderboard]. The top 3 developers with the most points will win bragging rights and Bevy merch[^merch]! [^online-leaderboard]: Likely through a website hosted by `TheBevyFlock` or the `bevyengine` organization. [^merch]: Unfortunately I can't guarantee this, since I personally own no Bevy merch. (My Bevy socks :sob: :socks:) Instead, merch will only be a prize if `cart` generously relinquishes some from his private stores. As such, the larger prize is light-hearted fun and fame. ## Scoring ### Bug Fixes To score a points a contestant must open and successfully merge a pull request that closes an [issue labeled `C-Bug`]. For this PR to qualify, it must: 1. Link to the issue it closes with "Fixes #1234" or "Closes #1234" in the description so that Github links them together. 2. Close an open issue labeled `C-Bug` that does not also have `S-Needs-Triage`. 3. Not be created by the same person who authored the issue.[^different-authors] 4. Be created after the event has started and before it ends. 5. Be made for the `bevyengine/bevy` repository. 6. Be marked by the new `M-Bug-Hunt-Accepted` label by a member of the triage team to signal that it follows the above qualifications. 7. Be merged into the `main` branch. (There will be a window of time after the event officially ends where this can still be merged, before the final winner is announced, in order to give more time to the maintainers.) Each merged pull request is worth 3 points, which will be reflected on the leaderboard. [issue labeled `C-Bug`]: https://github.com/bevyengine/bevy/issues?q=is%3Aissue%20state%3Aopen%20label%3AC-Bug [^different-authors]: _So why must the issue author and PR author be different? Wouldn't the person who opened the issue be best equipped to fix it?_ While that is true, it could end up in competitors opening and immediately fixing their own bugs. Instead, contributors are encouraged to work together in sharing and fixing bugs. ### Reviews In addition to fixing bugs, contestants can also earn points by reviewing other pull requests. In order for the review to qualify, it must: 1. Be made on a pull request marked with `M-Bug-Hunt-Accepted`. 2. Be made _before_ the `S-Ready-For-Final-Review` label is applied or the PR receives two approvals. 3. Be made after the event has started and before it ends. 4. Not be on a PR authored by the reviewer. (PR authors can add review comments on their own PRs, but those don't count!) 5. Be made for the `bevyengine/bevy` repository. 6. Be made on a pull request that later gets merged into the `main` branch. (See comment above on the extended window of time.) Each review is worth 1 point, which will be reflected on the leaderboard. > [!Note] > > Because reviews only count if the pull request is merged, reviewers are encouraged to help the PR author work through suggestions and polish off their changes. Both will benefit from doing so! ## Tips - Try to find teammates to work with! You can trade reviews and suggest issues to work on. - Don't be dissuaded by `D-Complex` or related tags, especially if you specialize in a specific area of the engine. Those could be bugs that only you are qualified to fix, and will have far less competition than `D-Trivial` bugs. - Check if a bug has a linked pull request already before working on it. This will save you time, and may give you a great starting point if that linked PR is `S-Adopt-Me`. - If you accidentally _do_ do duplicate work, you can scavenge some of that time by reviewing the existing pull request. You won't get the full 3 points, but you'll at least be familiar enough with the issue to get 1. - Use [issue labels] to find bugs to work on. You can filter by area, difficulty, and platform thanks to the efforts of the triage team! [issue labels]: https://github.com/bevyengine/bevy/labels