|
| 1 | +<!-- TITLE: include the issue number, and start with "Fix" for a bug fix or "Close" for |
| 2 | + anything else: |
| 3 | +
|
| 4 | + Fix #1234: Cheese has the wrong colour gradient |
| 5 | + Close #1234: Added 6 new cheese gradients |
| 6 | +
|
| 7 | + More than one issue is fine: "Close #111, #5329: Added unit history tracking". |
| 8 | + Release notes are generated automatically from pull request titles, so the title is |
| 9 | + what players end up reading. --> |
| 10 | + |
| 11 | +## What this changes |
| 12 | + |
| 13 | +<!-- The effect someone actually sees, in plain language. One or two sentences is fine. --> |
| 14 | + |
| 15 | +<!-- Keep this line as well as the number in the title. GitHub only closes an issue from a |
| 16 | + keyword in the description - a number in the title alone does not close anything. |
| 17 | +
|
| 18 | + Any of these close an issue when this merges: |
| 19 | + Close / Closes / Closed |
| 20 | + Fix / Fixes / Fixed |
| 21 | + Resolve / Resolves / Resolved |
| 22 | +
|
| 23 | + Closing more than one needs the keyword repeated in front of each number: |
| 24 | + Fixes #1234, fixes #5678 closes both |
| 25 | + Fixes #1234, #5678 closes only #1234 |
| 26 | +
|
| 27 | + For an issue in another repository, qualify it: Fixes MegaMek/mekhq#1234 --> |
| 28 | +Fixes # |
| 29 | + |
| 30 | +## Testing |
| 31 | + |
| 32 | +<!-- What you ran. Unit tests? Did you play a game and exercise this path? |
| 33 | + Once it has been tested in game, add the "AI ready for Review" label. --> |
| 34 | + |
| 35 | +## What is not proven yet |
| 36 | + |
| 37 | +<!-- What you did not test, or could not. "Nothing" is a valid answer - say so explicitly. --> |
| 38 | + |
| 39 | +--- |
| 40 | + |
| 41 | +- [ ] This PR is focused on one issue or RFE. Large refactoring or accessibility work is in its own PR |
| 42 | +- [ ] Every file in the diff has a deliberate change (no stray formatting, no unrelated files) |
| 43 | +- [ ] Tests added or updated, if this implements a rule or changes game state |
| 44 | +- [ ] Javadoc literals use `{@code true}` / `{@code null}` rather than bare or quoted text |
| 45 | +- [ ] Dev team only: if AI tools were used, the **AI Assisted Development** label is applied, and I can |
| 46 | + explain and have verified the result |
| 47 | + |
| 48 | +<!-- ABOUT THAT LAST BOX, IF YOU ARE NOT ON THE DEV TEAM: |
| 49 | +
|
| 50 | + Only active members of the dev team may use AI tools on contributions. That is not a judgement |
| 51 | + on your work. A developer carries the history of why the codebase is the way it is, and an AI |
| 52 | + tool starts without any of it every single session - the developer is what makes the difference. |
| 53 | +
|
| 54 | + Contributions you have written yourself are very welcome, and you do not need to be on the dev |
| 55 | + team to send one: |
| 56 | + https://github.com/MegaMek/megamek/wiki/Creating-a-Pull-Request-%28PR%29-as-an-Outside-Contributor |
| 57 | +
|
| 58 | + Generative AI art is never accepted, from anyone. A pull request containing it will be rejected. |
| 59 | +
|
| 60 | + Full policy: |
| 61 | + https://github.com/MegaMek/megamek/wiki/Guidelines-for-Developer%E2%80%90Led-AI-Tool-Usage-in-MegaMek --> |
| 62 | + |
0 commit comments