Try   HackMD

The Bevy Bug Hunt

This document is a proposal for a Bug Hunting Week within the Bevy contributor community.

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.

Incentives

In order to encourage contributors to participate, this event will be a competition with a public leaderboard. Competitors will earn points and can view their ranking online[1]. The top 3 developers with the most points will win bragging rights and Bevy merch[2]!

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.[3]
  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.

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!

  1. Likely through a website hosted by TheBevyFlock or the bevyengine organization. ↩︎

  2. 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. ↩︎

  3. 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. ↩︎

Last changed by 
 
Bevy Developer Network
An unoffical community effort to document and explain bevy's design choices
0
80

Read more

Hot-patching Bevy code

can hot reload systems

May 22, 2025
Entity Allocation and Reservation

If you've worked with ecs for a while now, this might seem like something to skip over, but it's important to have precise definitions. Here's my definition: An entity is a group of component values associated with a generally unique id, generally unique refereing to the fact that aliasing is posible but rare.

May 21, 2025
What is this?

Hi! This is HackMD, a collaborative Markdown editor (similar to Google Docs).

May 20, 2025
The Abyss

Rendering is a very large subject that's also not very discoverable. If you come across well-written reference material at any level (introductory blog posts, industry presentations, research papers) that you think others will benefit from, please link it here!

May 19, 2025
Read more from Bevy Developer Network
Published on HackMD