Any GT:NH dev must be respectful to anyone on the GitHub, and in Discord, or any other place where they might represent the GT:NH project (no insulting, no maliciously trolling, no looking down on the others etc). Basically, don't be a jerk. In particular, no insulting other developers if they do not agree with your ideas, and vice versa. This can be a reason to be demoted, no matter your contributions to the pack.
To improve review quality, in PR about new feature/feature change/balance changes, you should always explain what you are doing in the PR, and why you did it. The more precise your description, the better, as it helps to decide if the change is ok or not. Screenshots and videos are a bonus, as they can directly be copy/pasted in #upcoming-features. Titles should be written as if they are to be read from a changelog, given that is how it is autogenerated (context is important!), About the commits, prefer multiple short ones over one big commit, and name them in such way that they are reflective of your changes.
- You should avoid touching areas of the pack you have never reached personally as a player, unless you have feedback from other devs/players who are experienced in those areas.
- You should avoid adding new content below IV tier, the game is already dense enough as it is (especially the chemlines!). However, bug fixes and QoL changes are always appreciated. If you have a good reason to add it, discuss with the team in #meta-dev, and if general consensus is reached, then you can start working on it. This is important! We don’t want anyone to waste dev time on PRs that will get rejected.
- Don't make PRs with new stuff if it hasn't been discussed with the team before. We had enough occurrences of that in the pack, where it is merged without anyone but the one who coded the PR knowing precisely what the changes are about, resulting in awful discoveries once it's shipped to the players.
- Respect the vision. If something you want to add is not in the vision document then discuss it in #meta-dev and if there is agreement the document can be updated.
- Be open to criticism. Sometimes the stuff you made and that you are proud of might not be popular in its current form. That's ok and it's a part of the process.
- Include a flowchart if it involves adding a new recipe chain. Any new PR without it will be rejected no matter how good it can be. If you don’t know how, try draw.io.
- Regarding textures within GTNH
- Regarding magic textures: within the vision of the modpack, magic is meant to feel, look, and be different from GregTech, any form of GUI update for the sake of (or that would inadvertently bring) consistency with GT GUIs should be rejected.
- Regarding new textures: try to keep textures consistent with the mod/mod group they're being added to.
- Regarding tooltips: reduction is fine when needed, but if there is a specific consistency, try to stay within that.
- Regarding inventory changing: GUIs that shift the colour of the player's internal inventory are allowed as long as its usage is consistent. Examples being: GT's Steam Machines, Magic Bee's Magic Apiary, Railcraft's Coke Oven, etc.
- The design focus of Magic
- As mentioned above, magic within GregTech: New Horizons is meant to have a strong, distinct look, feel, and execution to the typical tech mod in the pack. Thusly, it is of upmost importance that both the artistic and mechanical designs of each mod be treated with the upmost respect and taken into consideration in the creation of new magic content.
- Thaumcraft
- Thaumcraft is a lore mod, while yes, it is a magic mod, above all else it is trying to tell a distinct story, with both limitations and specific paths. As such, when designing and balancing for Thaumcraft, one must take the lore into consideration, one example being: "Essentia types cannot mix otherwise an explosion would occur." Meaning in no circumstance are essentias allowed to touch to maintain canon. (i.e. a single jar can't store multiple essentia but a reservoir can.) However, a designer could take advantage of this and create an essentia explosive, for example writing lore of a mechanism that works similar to a bombardier beetle.
- Thaumcraft lives and dies on the quality of the lore, while there are some allowances for data here and there, hard numbers are meant for the questbook, not the thaumonomicon.
- Create lore entries with the upmost seriousness, joke entries are allowed, however, this is meant for singular isolated items and chains, please do not create an entire research tab for trivial things or jokes.
- Intentionally misleading data is explicitly forbidden, for example, please do not add in a mention of "one low low price of [2000 warp]" within the text of a research entry that actually does contain warp, users will absolutely panic.
- Please refrain from adding any content directly to the vanilla Thaumcraft tabs, not only is this a direct request by Azanor in the terms of Thaumcraft addon creation, but likewise, it just causes issues with unlocking Kami. (SuperTiC + Kami bug)
- Please don't swear within research or tooltips, there are some allowances, such as certain usages of "damn/damned" but in general it comes off crass and childish.
- Blood Magic 1)
- Botania 1)
- Witchery
- Don't, if you want to add Witchery content, please add it to Forbidden Magic instead. Witchery exists as a singular ARR island compared to the archipelagos that make up the other magic mods, no vast fields of addons like Thaumcraft, no open sourced code like Botania and Blood Magic, if you'd like to see new Witchery content, please help us recreate the vital portions in new, untethered, code.
They must follow the vision we have, and follow 4. of the Content Section. A PR affecting balancing should always be labeled as such, and not be mixed in with other unrelated changes in the same PR. For IV and below, follow 2. of the Content creation section. For LuV and above, it must at least have 2 approvals, and one of them must be a member of the github's admin team (list of them here).
When a PR is tagged as a balance affecting PR (currently "Affects Balance"), devs are required to answer the following questions to clarify their viewpoint and make discussion easier, as well as document discussions that may have happened in Discord (hard to search). Similar to recipe chains, any new balance PR made without answering the questions will be rejected no matter how good it is. Devs are not required to have perfect answers for all questions (eg some meta changes are difficult to know), but an attempt should be made at answering each:
- What goal is this change trying to achieve? What tier is it targeting?
- What side effects does this have on other lines/systems? How does it change the game meta?
- If relevant, do you have any metrics or a spreadsheet/visualization explaining your change? If it is a new multiblock, could you provide a picture of it and/or a practical setup? This may help us understand it better.
- Is this change made in expectation or in tandem with another unwritten or unmerged change coming later?
The question requirement may be bypassed in reasonable scenarios, such as emergency reverts.
This will try to explain a few guidelines on how to review a PR. This it not to be followed 100%, but just a general guideline on how a review should go.
You should avoid reviewing a balancing PR if you aren't very familiar with what will be the implications of the changes proposed in the PR. Especially if it's about balancing PRs, as this can affect the whole community in a bad way.
Everyone has a limit to what they know, but there's no limit to what they can learn. Rather than trying to review a PR in an unfamiliar area, examine it to identify any potential issues. As you familiarize yourself with various PRs, gradually increase the complexity of what you review. Even new developers can identify potential problems or inconsistencies, often referred to as "code smells". Although one shouldn't approve a PR without thorough knowledge, it's beneficial to review it, ask questions, and prompt the author to reconsider their approach.
If a piece of code or logic is understood only by the author, it can lead to knowledge gaps. To prevent this, request the author to clarify it in a comment or documentation. This ensures that the knowledge persists over time. If a concept remains hard to explain even after commenting, the author should document it directly in the code.
A PR's description offers a quick overview of the changes. If it's empty, request the author to complete it. The description not only benefits those going through the changelog but also helps reviewers understand the scope and decide if they're the right person to review it.
It's essential to understand that behind every pull request, there's a person who has invested time and effort. Your comments reflect on the entire GTNH organization and can profoundly impact someone's motivation. A singular negative or rude comment might dissuade a developer from contributing in future, potentially leading to a loss of valuable input and innovation for the project. Remember, today's novice contributor can be tomorrow's project lead. We all started here.
Encourage growth by ensuring that feedback is constructive, actionable, and respectful. Highlight what's done well just as much as what needs improvement. You might be surprised how much some kind words mean to others. If something is unclear, frame your queries as genuine questions rather than implicit criticisms. A community thrives when its members feel valued and respected.
Understanding our active developer count helps redistribute tasks more efficiently. Life events might cause some to temporarily step back from the GT:NH project, which is completely understandable. If you foresee a break in your contributions, consider setting your status to inactive to avoid being approached about GTNH related activities. This isn't a demotion; you can always request to be reactivated after your break. Sometimes, unanticipated events may cause unplanned breaks. Therefore, after a month of inactivity (defined as no code contribution or PR reviewing), you'll be marked as on hiatus.