livie
/
phoenix-firestorm
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix layout issues in PR guidelines

master
Ansariel Hiller 2025-06-16 11:30:26 +02:00 committed by GitHub
parent 5d1657cc6d
commit 5840aabc1a
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
doc/FS_PR_GUIDELINES.md
View File

@ -4,16 +4,16 @@ Thank you for submitting code to Firestorm; we will review it and merge or provi
We have written this guide to help you contribute code that meets our needs. It will hopefully reduce the number of iterations required before we can merge the code.
1. **Descriptive Title**:
   - Use a clear and descriptive title for the PR.
Use a clear and descriptive title for the PR.
1. **Related Issues**:
   - Reference any related issues or pull requests by including the JIRA number and description in the commit message header (e.g., `[FIRE-12345] When I click, my head falls off` or `[FIRE-12345] prevent click detaching head`).
Reference any related issues or pull requests by including the JIRA number and description in the commit message header (e.g., `[FIRE-12345] When I click, my head falls off` or `[FIRE-12345] prevent click detaching head`).
1. **Description**:
   - Provide a detailed description of the changes. Explain why the changes are necessary and what problem they solve. If a JIRA is associated with the change, there is no need to duplicate that, but we would appreciate a summary and explanation of the fix.
Provide a detailed description of the changes. Explain why the changes are necessary and what problem they solve. If a JIRA is associated with the change, there is no need to duplicate that, but we would appreciate a summary and explanation of the fix.
1. **Comment tags (important)**:
   - We use comments to preserve the original upstream (LL) code when making modifications; this allows the person merging future code updates to see both the original code from LL and any new updates and then use those to determine whether the FS-specific changes need to be updated and reviewed.
We use comments to preserve the original upstream (LL) code when making modifications; this allows the person merging future code updates to see both the original code from LL and any new updates and then use those to determine whether the FS-specific changes need to be updated and reviewed.
If you are modifying LL code, we need the LL code preserved in a comment.
For example:
@ -55,9 +55,9 @@ Could be fixed as follows:
If the code you are changing is already inside an `//<FS>` comment block, then there is no need to add a new block, but do try to make sure that any comments align with the updates you make.
5. **Testing**:
   - Include details on how the changes should be tested. Describe the testing environment and any steps needed to verify the changes.
Include details on how the changes should be tested. Describe the testing environment and any steps needed to verify the changes.
1. **Documentation**:
   - If the change includes a new feature, it would be beneficial to suggest how we should update the FS Wiki pages to help users understand the feature
If the change includes a new feature, it would be beneficial to suggest how we should update the FS Wiki pages to help users understand the feature
Thank you for your contribution!