The Bevy Development Process :bird:
===
[Github Repository](https://github.com/bevyengine/bevy)

# Table of Contents :bookmark_tabs:
[TOC]

# Story Board :ticket:
| Backlog | In Progress | Review In Progress | Reviewer Approved | Done |
| - | - | - | - | - | - |
| Issues | Issues/PRs | PRs | PRs | Issues/PRs | Issues/PRs
- Each of the columns represents the current state of a given story.
- Stories will live in in a single column at a given time, moving from one to the other once appropriate progress had been made.

## Lifecycles :recycle:
### PR Lifecycle

graph TD
    D(In Progress) --> |Request Changes| E(Review in Progress);
    E --> |2+ Approve| F(Reviewer Approved);
    F --> |Request Changes| E;
    F --> |Merged/Closed| G(Done);

### Issue Lifecycle

graph LR
    B(Backlog) --> |Triaged|B;
    B --> |PR Opened|C(In Progress);
    C --> |PR Closed|B;
    C --> |PR Merged|D(Done);

# Github Labels :label:
Each of the following label columns represent a different category.
There is a single color associated with each category.
Each **issue**/**PR** is required to have the below labels (except where _opt_ is specified).

The layout of labels will be as follows:
***<prefix>: <label>***
e.g.
***T: enhancement***

## Categories and Colors :art:
`<Category> <Color>`
Content :purple_heart:
Type :blue_heart:
Priority :green_heart:
Difficulty :yellow_heart:
Status :orange_heart:
Platform :heart:

## Generic Labels
For both **Issues** and **PRs**
| Type [T] (one or more) | Category [C] | Platform [X] (opt)| Priority [P] (opt)
| ------ | ------- | ------- | ------- |
| enhancement | window | Windows | critical |
| bug | ci/build-system | Linux | high |
| code-quality | animation | Mac
| accessability | assets | iOS
| docs | audio | Android
| hotifx | ecs | XR
| performance | editor | Web
| breaking change | physics |
| code-cleanup | scenes |
| crash | rendering |
| testing | tasks |
| dependencies | ecosystem |
| regression | ui |
| duplicate | input |
| examples | math |
| | reflection
| | transform |
| | app |
| | ai |
| | modding |

## PR Labels :arrow_heading_down:
| Status [S] (optional) |
| --- |
| needs triage |
| ready for final review |
| abandoned |

## Issue Labels :exclamation:
| Difficulty [D] (opt) | Status [S] |
| --- | ---- |
| good first issue | needs triage |
| complex | needs investigation |
| | needs design |
| | ready for implementation |
| | blocked upstream |
| | invalid |
| | wontfix |
| | needs-rfc |
| | help-wanted |
| | user-error |

### Status Label Descriptions
- **ready-for-final-review**: this PR is ready for @cart to officially review.
- **abandoned**: this PR was abandoned with seemingly no intent to continue progress
- **needs-triage**: this issue needs labels
- **needs-investigation**: this issue must be examined/reproduced
- **needs-design**: needs design work laying out how it might be implemented
- **ready-for-implementation**: needs to be implemented in a concerete form
- **blocked-upstream**: no progress can be made until an upstream depdedency changes/fixes something
- **invalid**: This is spam, a duplicate issue, or user error
- **wontfix**: this direction won't be taken in favor of another approach
- **needs-rfc**: this proposes a large change that is not sufficently covered in an issue. An RFC should be created for more in-depth discussions.

# Triage :clipboard:
- Triaging is conducted via [Github Labels](#Github-Labels).
- Each story has a set of associated labels.
- Issues and PRs have a different set of associated labels
- Triaging is complete when the appropriate `labels` have been assigned and the `Needs Traige` label is removed.
- The triage team will add the appropriate labels to issues/PRs.

## Example Triaged PR
- PR: Fixing an important rendering bug for Windows
- Labels:
- `T-Bug`
- `C-Rendering`
- `X-Windows`
- `P-High`

## Example Triaged Issue
- Issue: Entities do not implement `std::fmt::Debug`.
- Labels:
- `T-Enhancement`
- `C-ECS`
- `D-good-first-issue`
- `S-ready-for-implementation`

# Pull Requests :arrow_heading_down:

## PR Template :paperclip:
- This should be added into the main repository via `.github/.pull_request_template.md`

Brief Description

## Problem:
- Describe the problem this PR solves here. 
- If you're fixing an issue, say "Fixes #X".

## Solution:
- Describe the solution used to overcome the problem.

## Additional Information:
- Any additional information needed to better understand this PR.

- Why?
- There is currenlty no standard for the PR messages that get merged into `main`.
- This template encourage descriptive PRs that thoroughly explains what it accomplishes.

Example PR
---
---
Add example for using `Commands`

## Problem:
- There are insufficient examples showing how to use `Commands`

## Solution:
- Add additional examples making is clear how to correctly use `Commands` in various contexts.
---

## Reviews :eyes:
Pull requests can be reviewed by anyone who contributes to bevy!
A pull request requires **at least** _two_ approvals to move from the `Review in Progress` to the `Reviewer Approved` story board columns. At this point, a triage member should mark the PR as `ready-for-final-review` and once in the `Reviewer Approved` column, the PR will be officially reviewed by **Cart**, and either
- **Merge**: at which point the PR moves to the `Done` column.
- **Request Changes**: which then moves the story back to the `Review in Progress` column.
- This should be automated via cart by reviewing and click the `request changes` button on the review.