Contributor Guide: Difference between revisions
From Sojourn
| (3 intermediate revisions by 2 users not shown) | |||
| Line 8: | Line 8: | ||
#All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns. | #All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns. | ||
# Content should be made with respect to the setting, atmosphere, balance and performance impact. | # Content should be made with respect to the setting, atmosphere, balance and performance impact. | ||
# Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most | # Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinent details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition. | ||
# In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue. | # In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue. | ||
# PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature. | # PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature. | ||
# While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is. | # While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is. | ||
# PRs with lore implications will at times be subject to A. review by creative lead or headmins, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place. | |||
# PR titles should be descriptive, no shit posts please. | |||
# Non-minor/non-bugfix PRs will generally be testmerges for anywhere from five days onward before being marked ready for full inclusion. Take this time to receive feedback and make any necessary changes. Any changes to and already test merged PR need to be communicated to the person who testmerged it. | |||
#concerns about a PR should generally be directed towards head admins for relaying to head devs/maintainers. This is per k5s preference. | |||
Latest revision as of 13:00, 23 May 2024
Contribution guidelines
- PRs may be put forth are not necessarily supported by their creator. They may be made on behalf of others or even just on a notion. All are free to make Pull Requests for consideration and ultimate responsibility for the inclusion(or exclusion) on content falls squarely on the head of the Lead-Dev. No coder should be shouted at solely for a change they've requested.
- Players and admins shall not dictate to devs or contributors how they 'must' spend their time coding. While changes will invariably become necessary for any number of reasons(story arcs, balance, etc) these changes should either be requested, or directly given to the lead-dev to determine implementation. At the end of the day, all developers who work on this project do so of their own volition and in their free time.
Guidelines
- All are free to work on content as they please, but in the interest of not wasting ones time it is often in the best interest to discuss possible PRs before the work is done so as to gauge concerns.
- Content should be made with respect to the setting, atmosphere, balance and performance impact.
- Changelogs MUST be detailed. While this is down to your discretion as to how much or little is 'relevant' , the most pertinent details should be laid out in clear and easy to read. E.G a new gun should have its damage, penetration and accuracy detailed. By following this guideline we hope to ease the process of balancing new content without stimying its addition.
- In the same way as the above, anything more than minor content should be thoroughly Q.A tested to ensure no bugs, erroneous behaviors, runtime, et cetera are going to cause immediate issue.
- PRs should contain, if any - generalized performance impact. I.e how much performance this will take amount of loops running or active cost to maintain this feature.
- While there are bound to be PRs that are so minor as to not necessarily require testing, it is considered good practice to do so anyway. PRs should be tested to at least a basic level of completion and in the PR should have the following info; What this PR does, How I tested it, What the test result is.
- PRs with lore implications will at times be subject to A. review by creative lead or headmins, and B. Reasonable explanation as to why/how this change took place. E.G; PR A intends to balance FBPs by restricting departmental types to their respective departments, PR creator may be expected to work with lore team to provide a plausible reason for why this change has taken place.
- PR titles should be descriptive, no shit posts please.
- Non-minor/non-bugfix PRs will generally be testmerges for anywhere from five days onward before being marked ready for full inclusion. Take this time to receive feedback and make any necessary changes. Any changes to and already test merged PR need to be communicated to the person who testmerged it.
- concerns about a PR should generally be directed towards head admins for relaying to head devs/maintainers. This is per k5s preference.
