General repository maintenance. (#94)

* Fixes #93

Add pull request and issue templates.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Add CODEOWNERS file

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Fix yaml issues

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

fix yaml??

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

Fix name of issue template.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Testing if I can do this with prs too

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

Can I do this with pr templates too??

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

Can I do this with pr templates too??

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

Can I do this with pr templates too??

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Move PULL_REQUEST_TEMPLATE/PULL_REQUEST.md to PULL_REQUEST_TEMPLATE.md, because github :poob:

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* I don't think I can... oof.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Oops, forgot to add this link.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Perform requested changes

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Forgot one

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Server software -> Platform & Merge platform + platform version

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Inclusion of "addon" in language

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* compat with other terrain gen mods

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* inclusion of "addon" in FEATURE_REQUEST.md

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Update CODEOWNERS

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* add discord link to config.yml

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* update PULL_REQUEST_TEMPLATE.md to no longer use "plugin"

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Reintroduce stacktrace section

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* be more specific about compat issues

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* modify CODEOWNERS

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Add CODE_OF_CONDUCT.md

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Repo: add CONTRIBUTING.md file

Add CONTRIBUTING.md file with some basic guidelines on how to get started contributing.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Repo: Update git commit types

Update git commit types in CONTRIBUTING.md and sort them.

Add new entries under "types of changes" for PULL_REQUEST_TEMPLATE.md.

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>

* Repo: Performed requested changes

forgot some stuff lol

Signed-off-by: solonovamax <solonovamax@12oclockpoint.com>
This commit is contained in:
solo 2021-05-31 20:57:55 -04:00 committed by GitHub
parent fa164e5281
commit c1c2ab6df8
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
9 changed files with 997 additions and 14 deletions

19
.github/CODEOWNERS vendored Normal file
View File

@ -0,0 +1,19 @@
# Global owners, automatically request review when pull request is submitted
* @dfsek @solonovamax
# Platforms
## dfsek wrote the majority of the platform impls
/platforms/bukkit/ @dfsek
/platforms/fabric/ @dfsek
/platforms/forge/ @dfsek
/platforms/sponge/ @dfsek
## solonovamax is working on the region generator (unless duplexsystem takes it over)
/platforms/region/ @solonovamax
# Common
/common/ @dfsek @solonovamax
# Gradle Stuff
## Most gradle stuff was written by solonovamax
/buildSrc/ @solonovamax
*.gradle.kts @solonovamax

105
.github/ISSUE_TEMPLATE/BUG_REPORT.md vendored Normal file
View File

@ -0,0 +1,105 @@
---
name: "Bug Report"
about: "Open a bug report to help us identify issues with Terra."
title: "[Bug] <Put your title here>"
labels: "Type: Bug, Status: Pending"
assignees: ""
---
<!--
##############################################################################
## WARNING! ##
## IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN YOUR ISSUE BEING CLOSED ##
##############################################################################
-->
## Pre-Issue Checklist
<!--
Please go through this checklist item by item and make sure you have successfully completed each of these steps.
- You must be on the LATEST version of Terra to receive any support. There is no support for older versions of Terra.
- Make sure that this is not a *specific* compatibility issue with another terrain generation mod.
Do not request *specific* compatibility with mods or plugins (e.g. "Compatibility with TechCraft v7").
That should be implemented in an addon, **not** in the main project.
*General* compatibility (e.g. "Ability to pull Vanilla/Modded features from parent biomes") will be considered in the main project.
- Make sure that there are no already existing issues open with your problem. If you open a duplicate, it will be closed as such.
- Make sure that it is actually Terra causing the issue, and not another mod/plugin.
You can do this by testing to see if you can recreate the issue without Terra installed.
- Make sure that this is not an issue with a specific Terra *pack* or Terra *addon*, and instead applies to all of Terra.
- Make sure that you attach a copy of the latest.log file.
Putting *just* the exception IS NOT ENOUGH. We need to be able to check that there wasn't anything else before that caused it.
- Make sure that you have filled out all the required information and given descriptions of everything.
You must put an x in all the boxes you have completed. (Like this: [x])
To make sure that your issue is rendered properly, you may check the "Preview" tab (below the title) to see a rendered version of it before you submit it.
-->
- [ ] I have checked that I am on the latest version of Terra.
- [ ] I have searched the github issue tracker for similar issues, including closed ones.
- [ ] I have made sure that this is not a bug with another mod or plugin, and it is Terra that is causing the issue.
- [ ] I have checked that this is an issue with Terra and not an issue with the pack I am using.
<!-- If this is an issue with the default Terra pack, please open an issue on the pack repo: https://github.com/PolyhedralDev/TerraDefaultConfig/issues/new -->
- [ ] I have attached a copy of the `latest.log` file
- [ ] I have filled out and provided all the appropriate information.
## Environment
<!-- You can fill out the different items by putting the correct value beside each cell. -->
| Name | Value |
|------------------------------|-------|
| Terra Version | <!-- Put your Terra version here. (remove the comment) -->
| Platform / Platform Version | <!-- Put your platform and platform version here. (remove the comment) (eg. Spigot, Fabric, Paper, etc.) (If you are using the Region generator, put that here instead) -->
| Any External Plugins or Mods | <!-- Put a list of all the plugins or mods you have installed here. (remove the comment) (Make sure to NOT include any new lines) -->
| Terra Packs In Use | <!-- Put a list of all the Terra packs you have installed here. (remove the comment) (Make sure to NOT include any new lines) (/te packs may be used to get a list) -->
| Terra Addons In Use | <!-- Put a list of all the Terra addons you have installed here. (remove the comment) (Make sure to NOT include any new lines) (/te addons may be used to get a list) -->
## Issue Description
<!--
Put a quick description of the issue here.
Example: 'When generating terrain, something causes the chunks to not load properly', etc.
-->
### Steps to reproduce
<!--
Describe what you were doing when this happened.
Make sure to include ALL information. Including anything you were doing before that may have caused it.
-->
1. <!-- Put step #1 here. -->
2. <!-- Put step #2 here. -->
3. <!-- etc. -->
### Expected behavior
<!-- Describe what you think *should* happen here: -->
### Actual behavior
<!-- Describe what *actually* happens here: -->
<!-- example: When I do _______, it actually does _______ -->
### Full stacktrace
<details>
<summary>Exception Stacktrace</summary>
<!--
If Terra logs an exception, please put it in the following section: (You will find any error logs in your console, or your latest.log)
Note: this *must* be included, in ADDITION to the latest.log file.
-->
```
```
</details>
### Additional details
<!-- Any other information you think should be added -->

View File

@ -0,0 +1,70 @@
---
name: "Feature Request"
about: "Give us suggestions of features we could add to Terra."
title: "[Feature] <Put your title here>"
labels: "Type: Enhancement, Status: Pending"
assignees: ""
---
<!--
########################################################################################
## WARNING! ##
## IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN YOUR FEATURE REQUEST BEING CLOSED ##
########################################################################################
-->
### Pre-Request Checklist
<!--
Please go through this checklist item by item and make sure you have successfully completed each of these steps.
- You must be on the LATEST version of Terra to make sure your feature hasn't been added yet.
- Make sure that there are no already existing feature requests similar to yours. (Including closed!) If you open a duplicate, it will be closed as such.
- Make sure that this is actually in the scope of Terra.
- Make sure that this is not a feature request that should be made for a specific Terra *pack*, and instead applies to all of Terra.
- Make sure that you attach a copy of the latest.log file, if there are any exceptions thrown in the console.
Putting *just* the exception IS NOT ENOUGH. We need to be able to check that there wasn't anything else before that caused it.
You must put an x in all the boxes you have completed. (Like this: [x])
To make sure that your issue is rendered properly, you may check the "Preview" tab (below the title) to see a rendered version of it before you submit it.
-->
- [ ] I have checked that I am on the latest version of Terra.
- [ ] I have searched github for similar features requests, including closed ones, and found none.
- [ ] I believe this is within the scope of Terra.
- [ ] This feature request is for *all* of Terra, and isn't something that should be implemented by a pack or addon.
## Feature Description
<!--
Quickly describe the basics of your feature request.
Example: 'More noise presets should be added to Terra.'
-->
### What Problem Does This Solve?
<!--
Describe here what the issue is that you have.
Examples: 'When I do _______, it annoys me that _______ does _______.' or 'There is not enough customization in _______ to do _______.'
NOTE: This should NOT be used for a bug report. If this is unintentional, then please submit a bug report instead.
-->
### A Solution You'd Like
<!-- Provide a clear and accurate description of how you would like this to be solved. -->
### Alternative Solutions
<!-- Provide a description of alternatives you have considered to this. -->
1. <!-- Alternative #1. -->
2. <!-- Alternative #2. -->
3. <!-- Alternative #3. -->
### Additonal Context
<!--
Is there any additional context you would like to add?
If not, you may remove this section.
-->

11
.github/ISSUE_TEMPLATE/OTHER_ISSUES.md vendored Normal file
View File

@ -0,0 +1,11 @@
---
name: "Other Issue"
about: "Use this template if your issue doesn't accurately fit into any of the other categories."
title: ""
labels: "Type: Question, Status: Pending"
assignees: ""
---
## Describe the issue
<!-- Please describe the issue as clearly and as concisely as possible, without missing any details. -->

11
.github/ISSUE_TEMPLATE/config.yml vendored Normal file
View File

@ -0,0 +1,11 @@
blank_issues_enabled: false
contact_links:
- name: Which Issue Template do I Choose?
url: https://github.com/PolyhedralDev/Terra/wiki/How-To-Choose-An-Issue-Template
about: Click this if you don't know which issue template to select. This will help you make sure you choose the right one and provide enough information for us to help you.
- name: Terra Wiki
url: https://github.com/PolyhedralDev/Terra/wiki
about: Documentation for all things Terra.
- name: Join the Support Discord
url: https://discord.dfsek.com
about: If you have a basic support question, join the Discord instead.

114
.github/PULL_REQUEST_TEMPLATE.md vendored Normal file
View File

@ -0,0 +1,114 @@
# Pull Request
## Brief description.
<!-- Please provide a brief description of the goals of your PR -->
<!--
###########################################################################
## WARNING! ##
## IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN YOUR PR BEING CLOSED ##
###########################################################################
-->
<!--
Please go through this checklist item by item and make sure you have successfully completed each of these steps.
- Your pull request MUST be either on the latest version of Terra, or on a branch for a future release.
- Make sure that there are no already existing PRs that fix this. If so, it will be closed as a duplicate.
- Make sure that this change is actually within the scope of Terra and is something a terrain generator should be doing.
- Make sure that this is not an issue with a specific Terra *pack*, and instead applies to all of Terra.
- Make sure that you have filled out all the required information and given descriptions of everything.
-->
<!-- You can erase any parts of this template not applicable to your Pull Request. -->
### What Issues Does This Fix?
<!--
Put Fix #XXXX or Closes #XXXX here if there are any open issues that this PR fixes.
This is to automatically close the relevant issues.
You may remove this if there is no issue for this PR.
But unless this is a very small change, you should make an issue for it.
-->
## Licensing
<!-- In order to be accepted, your changes must be under the GPLv3 license. Please check one of the following: -->
- [ ] I am the original author of this code, and I am willing to release it under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html).
- [ ] I am not the original author of this code, but it is in public domain or released
under [GPLv3](https://www.gnu.org/licenses/gpl-3.0.en.html) or a compatible license.
<!--
Please provide reliable evidence of this.
NOTE: for compatible licenses, you must make sure to add the included license somewhere in the program, if so required.
(And even if it's not required, it's still nice to do it. Also add attribution somewhere.)
-->
## Goal of the PR
<!--
What is the goal of the PR?
Put a checklist here of what has been done
(and what *hasn't*, but you plan to do),
so we can easily know what was changed.
Note: this is only required for PRs that add new features.
If your PR is not adding new features, only fixing bugs or adding translations, then you may delete this section.
-->
- [ ] <!-- First thing -->
- [ ] <!-- A requirement of the first thing. -->
- [ ] <!-- A second requirement of the first thing. -->
- [ ] <!-- Second thing -->
- [ ] <!-- etc. -->
## Affects of the PR
<!---
What types of changes does your code introduce? (Select any that apply. You may select multiple.)
You must put an x in all the boxes that it applies to. (Like this: [x])
-->
#### Types of changes
- [ ] Bug Fix <!-- Anything which fixes an issue in Terra. -->
- [ ] Build system <!-- Anything which pretain to the build system. -->
- [ ] Documentation <!-- Anything which adds or improves documentation for existing features. -->
- [ ] New Feature <!-- Anything which adds new functionality to Terra. -->
- [ ] Performance <!-- Anything which is imrpoves the performance of Terra. -->
- [ ] Refactoring <!-- Anything which does not add any new code, only moves code around. -->
- [ ] Repository <!-- Anything which affects the repository. Eg. changes to the `README.md` file. -->
- [ ] Revert <!-- Anything which reverts previous commits. -->
- [ ] Style <!-- Anything which updates style. -->
- [ ] Tests <!-- Anything which adds or updates tests. -->
- [ ] Translation <!-- Anything which is internationalizing the Terra program to other languages. -->
#### Compatiblity
- [ ] Breaking change <!-- A fix, or a feature, that breaks some previous functionality to Terra. -->
- [ ] Non-Breaking change.
<!--
A change which does not break *any* previous functionality of Terra.
(ie. is backwards compatible and will work with *any* previously existing supported features.
Note: if a feature is annotated with @Incubating, @Preview, @Experimental,
or is in a package called something similar to the previous annotations,
then you may push breaking changes to only THOSE parts of Terra.)
-->
#### Contribution Guidelines.
- [ ] I have read the [`CONTRIBUTING.md`](https://github.com/PolyhedralDev/Terra/blob/master/CONTRIBUTING.md) document in the root of the
git repository.
- [ ] My code follows the code style for this
project. <!-- There is an included `.editorconfig` file in the base of the repo. Please use a plugin for your IDE of choice that follows those settings. -->
#### Documentation
- [ ] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
#### Testing
- [ ] I have added tests to cover my changes.
- [ ] All new and existing tests passed.
<!--
If it only introduces small changes, you don't need to add tests.
But if you add big changes, you should probably at least write *some* testing, where applicable.
-->

25
.gitignore vendored
View File

@ -85,14 +85,14 @@ hs_err_pid*
# When using Gradle or Maven with auto-import, you should exclude module files, # When using Gradle or Maven with auto-import, you should exclude module files,
# since they will be recreated, and may cause churn. Uncomment if using # since they will be recreated, and may cause churn. Uncomment if using
# auto-import. # auto-import.
.idea/artifacts .idea/artifacts
.idea/compiler.xml .idea/compiler.xml
.idea/jarRepositories.xml .idea/jarRepositories.xml
.idea/modules.xml .idea/modules.xml
.idea/*.iml .idea/**.iml
.idea/modules .idea/modules
*.iml *.iml
*.ipr *.ipr
# CMake # CMake
cmake-build-*/ cmake-build-*/
@ -137,10 +137,7 @@ build
.idea/modules/**.iml .idea/modules/**.iml
!lib/*.jar !lib/*.jar
.idea/Terra.iml
/run/ /run/
.idea/**.iml idea/**
/lang/
/packs/ testDir/
/config.yml
/region/

337
CODE_OF_CONDUCT.md Normal file
View File

@ -0,0 +1,337 @@
# Terra Community Code of Conduct
# TL;DR
Polyhedral Development is dedicated to providing a harassment-free experience for everyone, regardless of gender, gender identity and
expression, preferred pronouns, sexual orientation, disability, physical appearance, age, race, religion, etc. We do not tolerate harassment
of participants in any form.
This code of conduct applies to all Terra community spaces, including the github discussions tab, our
[community discord server](https://discord.gg/PXUEbbF), the [community subreddit](https://reddit.com/r/TerraGenerator), or any other Terra
space, both online and off. Anyone in violation of this code, as determined by the applicable moderators, may be subject to verbal warning,
expulsion from these spaces, or future events and activities for an undetermined amount of time.
Some Terra community spaces may have additional rules in place, which will be made clearly available to all participants. Participants are
responsible for knowing and abiding by these rules.
# Longer version
Polyhedral Development is dedicated to providing a harassment-free experience for everyone. We do not tolerate harassment of participants in
any form.
## When and How to Use These Guidelines
This code of conduct applies to all Terra community spaces, both online and off. This applies to the github discussion tab,
the [Polyhedral Development community discord server](https://discord.gg/PXUEbbF), and any other Terra community. In addition, we may choose
to invoke them in instances of harassment outside the Terra communities, and we will punish the responsible individuals appropriately. We
will not tolerate harassment in any form, even outside of Terra.
Some Terra spaces may have additional rules in place, which will be made clearly available to participants. Participants are responsible for
knowing and abiding by these rules, in addition to this code of conduct.
## Expected Behavior
The following behaviors are expected of all members of the Terra community:
### Be Respectful
Value each other's ideas, styles and viewpoints. We may not always agree, but disagreement is no excuse for poor manners. Be open to
different possibilities and to being wrong. Be respectful in all interactions and communications, especially when debating the merits of
different options. Be aware of your impact and how intense interactions may be affecting people. Be direct, constructive and positive. Take
responsibility for your impact, and your mistakes if someone says they have been harmed through your words or actions, listen carefully,
apologize sincerely, and correct the behavior going forward.
#### Be Prepared to Admit When You are Wrong
Any member of the Terra community should always be open to new ideas and must always be open to the possibility of being wrong. Nobody can
always be right, and we are only human; we are [fallible](https://www.merriam-webster.com/dictionary/fallible) by nature. It is okay to make
mistakes, but we must be willing to admit when we make one.
### Be Direct but Professional
We are likely to have some discussions about if and when criticism is respectful and when it's not. We must be able to speak directly when
we disagree and when we think we need to improve. We cannot withhold hard truths. Doing so respectfully is hard, doing so when others don't
seem to be listening is harder, and hearing such comments when one is the recipient can be even harder still. We need to be honest and
direct, as well as respectful.
### Be Inclusive
Seek diverse perspectives. Diversity of views and of people on teams powers innovation, even if it is not always comfortable. Encourage all
voices. Help new perspectives be heard and listen actively. If you find yourself dominating a discussion, it is especially important to step
back and encourage other voices to join in. Be aware of how much time is taken up by dominant members of the group. Provide alternative ways
to contribute or participate when possible.
Be inclusive of everyone in an interaction, respecting and facilitating people's participation whether they are:
- Not native language speakers
- Coming from a different culture
- Using pronouns other than "he", "she", or "they"
- Living in a different time zone
- Facing other challenges to participate
- Or anything else. Be respectful of *everyone* at *all times*.
Think about how you might facilitate alternative ways to contribute or participate. If you find yourself dominating a discussion, step back.
Make way for other voices and listen actively to them.
### Understand Different Perspectives
Our goal should not be to "win" every disagreement or argument. A more productive goal is to be open to ideas that make our own ideas
better. Strive to be an example for inclusive thinking. "Winning" is when different perspectives make our work richer and stronger. That
means, you must pay attention to all ideas proposed. Don't disregard one without giving it the attention it deserves.
### Appreciate and Accommodate Our Similarities and Differences
People come from many cultures and backgrounds. Cultural differences can encompass everything from official religious observances to
personal habits to clothing. Be respectful of anyone with different cultural practices, attitudes and beliefs. Work to eliminate your own
biases, prejudices and discriminatory practices. Think of others' needs from their point of view. Use preferred titles (including
pronouns<sup>[\[1\]](#1)</sup>) and the appropriate tone of voice. Respect people's right to privacy and confidentiality. Be open to
learning from and educating others as well as educating yourself; it is unrealistic to expect someone to know the cultural practices of
every ethnic and cultural group. Therefore we must be ready to correct someone if they make a mistake, and must be ready ourselves to change
and learn if we make a mistake.
### Lead by Example
By matching your actions with your words, you become a person others want to follow. Your actions influence others to behave and respond in
ways that are valuable and appropriate for our organizational outcomes. Design your community and your work for inclusion. Hold yourself and
others accountable for inclusive behaviors.
## Behavior That Will Not Be Tolerated
The following behaviors are considered to be unacceptable and will not be tolerated:
### Violence and Threats of Violence
Violence and threats of violence are not acceptable - online or offline. This includes incitement of violence toward any individual,
including encouraging a person to commit self-harm, engage in self-harm, or put themselves in a negative position (e.g. one which can lead
to an increase of depression, etc.).
### Personal Attacks
Conflicts will inevitably arise, but frustration should never turn into a personal attack. It is not okay to insult, demean or belittle
others. Attacking someone for their opinions, beliefs and ideas is not acceptable. It is important to speak directly when we disagree and
when we think we need to improve, but such discussions must be conducted respectfully and professionally, remaining focused on the issue at
hand.
### Derogatory Language
Offensive, unwelcome, or hurtful comments related to:
- Gender
- Gender identity or expression
- Preferred pronouns<sup>[\[1\]](#1)</sup>
- Marital status
- Sex
- Sexual orientation or identity
- Native language
- Age
- (Dis)ability
- Mental illness
- Neuro(a)typicality
- Race and/or ethnicity
- Physical appearance
- A person's lifestyle choices or practices,
- A person's physical condition
- A person's mental condition
- Socioeconomic status
- Religion
- Employment
- Or anything really. Just don't be offensive towards people, insult them, or make unwanted comments.
is not acceptable. This includes deliberately referring to someone by a gender that they do not identify with, and/or questioning the
legitimacy of an individual's gender identity. If you're unsure if a word is derogatory, don't use it. This also includes repeated subtle
and/or indirect discrimination; when asked to stop, stop the behavior in question.
### Unwelcome Sexual Attention or Physical Contact
Unwelcome sexual attention or unwelcome physical contact is not acceptable. This includes sexualized comments, jokes or imagery in
interactions, communications or presentation materials, as well as inappropriate touching, groping, or sexual advances. Additionally,
touching a person without permission, including sensitive areas such as their hair, pregnant stomach, mobility device (wheelchair, scooter,
etc) or tattoos is unacceptable. This includes physically blocking or intimidating another person. Physical contact or simulated physical
contact (e.g. emojis like ":&#8203;kiss:", ":hug:", or ":kiss_mark:", textual descriptions like "\*hug\*", "\*backrub\*", or "\*kisses
you\*", etc.) without affirmative consent or after a request to stop will not be accepted.
### Sexual Behaviour Where it is Not Appropriate
Uninvited or off-topic sexual images, text, or behaviour in spaces where they're not appropriate will not be accepted whatsoever. We are an
open community, which means spaces must be appropriate for all ages, and everybody must feel comfortable. Discussion of sexual things, will
be prohibited unless otherwise noted.
### Discussion of Sensitive Topics
Discussion of sensitive topics when asked to stop, or when not appropriate. Including, but not limited to:
- Anything sexual
- Gore
- Suicide
- Self harm
- Anything related to death
- Or really anything that someone may be sensitive about.
shall not be tolerated. As a community for all ages and all kinds of people, we must cater to everyone, and must make sure everyone feels
comfortable here. Repeatedly breaking someone else's boundaries will not be tolerated.
### Disruptive Behavior
Sustained disruption of events, forums, or meetings, online or otherwise, including talks and presentations, will not be tolerated. This
includes:
- 'Talking over', 'heckling', or otherwise disrupting speakers.
- Making derogatory comments about someone else's choices, pushing people to do something they do not wish to do, talking about their
choices or personal preferences to others, or pressuring them to do something they don't wish to - physically or through jeering.
- Behaviour that intentionally disrupts an event.
- Otherwise influencing actions that may cause hostility in the session.
### Influencing Unacceptable Behavior
We will treat influencing or leading such activities the same way we treat the activities themselves, and thus the same consequences apply.
To make someone do something bad is the same thing as if you were to do it yourself, and we will not tolerate it.
### Stalking or Following
Stalking or following in any form (offline or online) is unnacceptable. In addition, you may not take pictures or record video of others
without their express permission or when asked to stop. Any individual may also request for you to delete all footage you have of them, even
if you took it with their prior consent.
### Publication of Personal Information
The publication of personally identifying information (commonly known as "[doxxing](https://en.wikipedia.org/wiki/Doxing)") is directly
prohibited. You may not publish information that someone wants to keep private, unless it is necessary to protect vulnerable people from
intentional abuse. Addditionally, you may not deliberately "out" any aspect of a person's identity without their consent, this includes
gender, pronouns, sexual identity, etc.
Unless it pretains to a case of harassment, as outlined here, in which case some personally identifying information may need to be brought
up in private with the appropriate moderation team to help aid our efforts in keeping the community safe.
### Deliberate Misuse of Pronouns<sup>[\[1\]](#1)</sup> or Names
As an inclusive community, we must respect everyone. That means respecting the pronouns or names they wish for us to use. Deliberate
misgendering, misuse of preferred pronouns<sup>[\[1\]](#1)</sup>, or use of 'dead' or rejected names is not to be tolerated. (If someone
*accidentally* uses the incorrect pronouns, gender, or name, politely ask them to use the correct pronouns/gender/name. But if they are to
continue using the incorrect pronouns, gender, or name, then you should escalate and report them to us.)
### Not Stopping After Multiple Requests
If someone asks you to stop doing something, then you should stop. Continuing to do it may be considered harassment, and can lead you to be
removed from our community.
## Complains We May Ignore
Additionally, Terra prioritizes marginalized people's safety over privileged people's comfort. We reserve the right to ignore complaints
regarding:
- Claims of discrimination against non-marginalized or oppressed groups (eg. being 'superphobic', meaning to not support people who are
'superstraight', which is a dog whistle for transphobic groups, or being 'cisphobic' without large amounts of evidence, etc.), or claims
of discrimination with no evidence. (Basically, don't report 'cisphobia' to us, because it doesn't exist. But if someone is mocking you or
making fun of you for being cis, and it is *really* getting out of hand, then do tell us.)
- Reasonable communication of boundaries, such as "leave me alone," "go away," or "I'm not discussing this with you." (If someone is asking
you to stop, that is not reason for you to report them as harassing you.)
- Communicating in a 'tone' you don't find [congenial](https://www.thefreedictionary.com/congenial). (You may not report someone for
harassment for being 'annoyed with you' or 'talking sternly to you')
- Criticizing or calling out racist, sexist, discriminatory, or otherwise oppressive behavior or assumptions. (You may not say that someone
is harassing you if they are telling you to stop discriminating against someone.)
- Disagreements that do not qualify as harassment. If you have a simple disagreement with someone, and they have not been discriminating to
anyone, in any form, then we will not take action against them. Two people are allowed to disagree on things without it getting toxic.
We may also additionally choose to enact punishment for submitting a complaint in bad-faith or without adequate justification, if we deem
necessary; if you're submitting a complaint just to troll or to annoy people, we may choose to have you banned or removed from the community
spaces. Don't waste our time.
In order to protect volunteers from abuse and burnout, we reserve the right to reject any report we believe to have been made in bad faith
or with misintent. Reports intended to silence legitimate criticism may be deleted without response.
## Reporting
Terra has a global moderation team which is currently comprised of the following members:
- solonovamax
- discord: [@solonovamax#6983](https://discord.com/channels/@me/566146322273402881)*
- github: [@solonovamax](https://github.com/solonovamax)
- email: [solonovamax@12oclockpoint.com](mailto:solonovamax@12oclockpoint.com)
- dfsek
- discord: [@dfsek#4208](https://discord.com/channels/@me/378350362236682240)*
- github: [@dfsek](https://github.com/dfsek)
- email: [dfsek@protonmail.com](mailto:dfsek@protonmail.com)
- duplex (duplexsystem)
- discord: [@Duplex#0797](https://discord.com/channels/@me/356822848641171456)*
- github: [@duplexsystem](https://github.com/duplexsystem)
- email: [duplexsys@protonmail.com](mailto:duplexsys@protonmail.com)
\* The preferred method of communication is through discord. Although we will still be responsive on the other platforms, we will be more
responsive on discord.
These are people you can contact for anything regarding this code of conduct.
If you are being harassed by a member of the Terra community, or by someone in a Terra community space, notice that someone else is being
harassed, or have any other concerns, please contact a moderator of the platform it occurred on, or someone on the global moderation team.
If the person who is harassing you is on the global moderation team, they will [recuse](https://www.thefreedictionary.com/recuse) themselves
from handling your incident. (Meaning: if you are reporting someone on the team, they will not be involved in the discussion.) We will
respond within a reasonable time frame, but generally within about 1 day.
This code of conduct applies to Terra community spaces, but if you are being harassed by a member of Terra *outside* our spaces, we still
want to know about it as we may choose to take action within our community. We will take all good-faith reports seriously and will always
attempt to handle them appropriately. This includes harassment outside our spaces and harassment that took place at any point in time. The
moderation team reserves the right to exclude people from Terra communities based on their past behavior, including behavior outside Terra
spaces and behavior towards people who are not in Terra.
Note: although we only have the ability to moderate official community spaces, if you are being harassed by someone in a non-official
community space, and the moderation team of that platform refuses to do anything to help you (or even if they *do* help you), then you
should notify us so that we may take appropriate action.
We will respect confidentiality requests for the purpose of protecting victims of abuse. At our discretion, we may publicly name a person
which we have received harassment complaints about, or privately warn third parties about them, but only if we believe that doing so will
increase the safety of Terra community members or the general public. We will not name harassment victims or reporters of harassment
(assuming the report was made in good-faith) without their explicit consent; all reports will remain anonymous by default.
## Consequences of Unacceptable Behavior
Participants asked to stop any harassing behavior are expected to comply immediately. Whether or not you comply immediately, you may still
face consequences for you actions, but if the harasser doesn't comply immediately then we may choose to take additional actions to protect
the Terra community members or the individual being harassed.
Violation of this code can result in being asked to leave an event or online space, either temporarily or for the duration of the event, or
being banned from participation in spaces, or future events and activities in perpetuity. If a participant engages in harassing behavior,
the global moderation team may take any action they deem appropriate, up to and including expulsion from all Terra community spaces and
identification of the participant as a harasser to other Terra community members or the general public. Bad behavior from any community
member, including those with decision-making authority, will not be tolerated.
In addition, any participants who abuse the reporting process will be considered to be in violation of these guidelines and subject to
consequences. False reporting, especially to retaliate or exclude, will not be accepted or tolerated.
## Questions
if you have further questions for anything not addressed here, you may open an issue on this github repo, or contact a member of the global
moderation team.
## License and Attribution
This set of guidelines is distributed under a
[Creative Commons Attribution-ShareAlike license](https://creativecommons.org/licenses/by-sa/3.0/).
These guidelines have been adapted from
[Mozilla's Community Participation Guidelines](https://www.mozilla.org/en-US/about/governance/policies/participation/), which were adapted
from:
- Mozilla's original Community Participation Guidelines
- The [Ubuntu Code of Conduct](https://ubuntu.com/community/code-of-conduct)
- Mozilla's [View Source Conference Code of Conduct](https://viewsourceconf.org/berlin-2016/code-of-conduct/)
- And the [Rust Language Code of Conduct](https://www.rust-lang.org/policies/code-of-conduct)
which in turn were based on [Stumptown Syndicate's Citizen Code of Conduct](http://citizencodeofconduct.org/), along with some adapted text
from the [LGBTQ in Technology Code of Conduct](https://lgbtq.technology/coc.html) and
the [WisCon code of conduct](http://wiscon.net/policies/anti-harassment/code-of-conduct/).
It was then modified by solonovamax with various inclusions from
the [LGBTQ in Technology Code of Conduct](https://lgbtq.technology/coc.html) and a few other sources.
## Notes
#### \[1\]
You provide a set of pronouns that everyone is comfortable addressing you with. Although some people are comfortable
using [neopronouns](https://www.mypronouns.org/neopronouns), not everyone is. Therefore, if you use neopronouns, you should have at *least*
one set of more common pronouns (One of he/him, she/her, or they/them; it doesn't matter which one. Anyone who doesn't respect your basic
pronouns will be removed from the community.) that people may use, should they so choose, as some people are not comfortable
using [neopronouns](https://www.mypronouns.org/neopronouns). But if someone refuses to use your more common pronouns, you should report them
to us. Additionally, you may not ask people to use unreasonable pronouns, such as 'acab/acabself', 'that/bitch', 'ur/mom', or
'dream/dreamself' (pronouns related to real people, eg. the minecraft youtuber 'dreamwastaken'). Doing so will be considered mockery of
individuals who use non-standard pronouns and is very disrespectful.

319
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,319 @@
# Contributing to Terra
First off, thank you for considering contributing to Terra. It's people like you that make Terra such a great tool.
Following these guidelines helps to effectively use the time of the developers managing and developing this open source project, making it
more enjoyable for all of us.
Terra is an open source project and we love to receive contributions from our community, you! There are many ways to contribute, from
writing tutorials or blog posts, improving the documentation, submitting bug reports and feature requests or writing code which can be
incorporated into Terra.
The following is a set of guidelines for contributing to Terra and its packages, which are hosted in
the [PolyhedralDev Organization](https://github.com/PolyhedralDev) on GitHub. These are mostly guidelines, not rules. Use your best
judgment, and feel free to propose changes to this document in a pull request.
#### Table Of Contents
[Code of Conduct](#code-of-conduct)
[I don't want to read this whole thing, I just have a question!!!](#i-dont-want-to-read-this-whole-thing-i-just-have-a-question)
[Getting Started](#getting-started)
- [Your First Contribution](#your-first-contribution)
- [Reporting Bugs](#reporting-bugs)
- [Before Submitting A Bug Report](#before-submitting-a-bug-report)
- [How Do I Submit A (Good) Bug Report?](#how-do-i-submit-a-good-bug-report)
- [Suggesting Enhancements](#suggesting-enhancements)
- [Before Submitting An Enhancement Suggestion](#before-submitting-an-enhancement-suggestion)
- [How Do I Submit A (Good) Enhancement Suggestion?](#how-do-i-submit-a-good-enhancement-suggestion)
- [Pull Requests](#pull-requests)
- [Before Submitting A Pull Request](#before-submitting-a-pull-request)
- [How Do I Submit A (Good) Pull Request?](#how-do-i-submit-a-good-pull-request)
[Styleguides](#styleguides)
- [Git Commits](#git-commits)
- [Committing](#committing)
- [Git Commit Messages](#git-commit-messages)
- [Code Styleguide](#code-styleguide)
- [Documentation Styleguide](#documentation-styleguide)
- TODO
[Coding Pratices](#coding-practices)
- [Compatibility](#compatibility)
- [General Compatibility](#general-compatibility)
- [Specific Compatibility](#specific-compatibility)
- [Platform-Agnostic Design](#platform-agnostic-design)
- [Data-Driven](#data-driven)
## Code of Conduct
This project and everyone participating in it is governed by the [Terra of Conduct](CODE_OF_CONDUCT.md). By participating, you are expected
to uphold this code. Please report unacceptable behavior to [Terra global moderation team](CODE_OF_CONDUCT.md#Reporting).
## I don't want to read this whole thing I just have a question!!!
> **Note:** Please don't file an issue to ask a question. You'll get faster results by using the resources below.
We have an official discord server where you can request help from various users
- [The official PolyhedralDev discord server](https://discord.dfsek.com)
## Getting Started
### Your First Contribution
Unsure where to begin contributing to Terra? You can start by looking through "beginner" and "help wanted" issues:
- [Beginner issues](https://github.com/PolyhedralDev/Terra/labels/Note%3A%20Good%20First%20Issue) - issues which should be friendly to
anyone new to terra.
- [Help wanted issues](https://github.com/PolyhedralDev/Terra/labels/Note%3A%20Help%20Wanted) - issues which should be a bit more involved
than "beginner" issues.
New to github? Working on your first Pull Request? Check
out [How to Contribute to an Open Source Project on GitHub](https://app.egghead.io/playlists/how-to-contribute-to-an-open-source-project-on-github)
to get you up on your feet.
At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first!
If a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed, and that you need to update your branch so it's
easier to merge.
### Reporting Bugs
This section guides you through submitting a bug report for Terra. Following these guidelines helps maintainers and the community understand
your report, and spend their time fixing the issue instead of understanding what you mean.
Before creating bug reports, please check [this list](#before-submitting-a-bug-report) as you might find out that you don't need to create
one. When you are creating a bug report, please [include as many details as possible](#how-do-i-submit-a-good-bug-report).
> **Note:** If you find a **Closed** issue that seems like it is the same thing that you're experiencing, open a new issue and include a link to the original issue in the body of your new one.
#### Before Submitting A Bug Report
- Join the [discord server](https://discord.dfsek.com) to help resolve simple issues.
- You must be on the LATEST version of Terra to receive any support. There is no support for older versions of Terra.
- Make sure that this is not a *specific* compatibility issue with another terrain generation mod. Do not request *specific* compatibility
with mods or plugins (e.g. "Compatibility with TechCraft v7"). That should be implemented in an addon, **not** in the main project.
*General* compatibility (e.g. "Ability to pull Vanilla/Modded features from parent biomes") will be considered in the main project.
- Search for any [already existing issues](https://github.com/PolyhedralDev/Terra/issues?q=is%3Aissue+) open with your problem. If you open
a duplicate, it will be closed as such.
- Make sure that it is actually Terra causing the issue, and not another mod/plugin. You can do this by testing to see if you can recreate
the issue without Terra installed.
- Double check that this is not an issue with a specific Terra *pack* or Terra *addon*, and instead applies to all of Terra.
- Include a copy of the latest.log file. Putting *just* the exception is not enough. We need to be able to check that there wasn't anything
else before that caused it.
- Be sure to fill out all the required information and give descriptions of everything.
#### How Do I Submit A (Good) Bug Report?
Bugs are tracked as [GitHub issues](https://guides.github.com/features/issues/)
. [Create an issue](https://github.com/PolyhedralDev/Terra/issues/new) and provide the prerequisite information by filling in the Bug Report
template.
Explain the problem and include additional details to help maintainers reproduce the problem:
- **Use a clear and descriptive title** for the issue to identify the problem.
- **Describe the exact steps which reproduce the problem** in as many details as possible. When listing steps, **don't just say what you
did, but explain how you did it**.
- **Provide specific examples to demonstrate the steps**.
- **Describe the behavior you observed after following the steps** and point out what exactly is the problem with that behavior.
- **Explain which behavior you expected to see instead and why.**
- **If the problem wasn't triggered by a specific action**, describe what you were doing before the problem happened and share more
information using the guidelines below.
Include details about your configuration and environment:
- **Which version of Terra are you using?** You can get the exact version by running `/te version`.
- **What's the name and version of the platform you're using**? (eg. Spigot, Fabric, Paper, etc.)
- **Which external plugins or mods do you have installed?**
- **Which Terra packs do you have installed?** You can get that list by running `/te packs`.
- **Which Terra addons do you have installed?** You can get that list by running `/te addons`.
### Suggesting Enhancements
This section guides you through submitting an enhancement suggestion for Terra, including completely new features and minor improvements to
existing functionality. Following these guidelines helps maintainers and the community understand your suggestion and find related
suggestions.
Before creating enhancement suggestions, please check [this list](#before-submitting-an-enhancement-suggestion) as you might find out that
you don't need to create one. When you are creating an enhancement suggestion,
please [include as many details as possible](#how-do-i-submit-a-good-enhancement-suggestion).
#### Before Submitting An Enhancement Suggestion
- You must be on the **LATEST** version of Terra to make sure your feature hasn't been added yet.
- Search for any [already existing issues](https://github.com/PolyhedralDev/Terra/issues?q=is%3Aissue+) (Including closed!) with your
problem. If you open a duplicate, it will be closed as such.
- Verify that this is actually within the scope of Terra.
- Be sure that this is not a feature request that should be made for a specific Terra *pack*, and instead applies to all of Terra.
- Be sure that this is not something that should be implemented as a Terra addon, and instead applies to all of Terra.
- Make sure that you attach a copy of the latest.log file, if there are any exceptions thrown in the console. Putting *just* the exception
**is not enough**. We need to be able to check that there wasn't anything else before that caused it.
#### How Do I Submit A (Good) Enhancement Suggestion?
Enhancement suggestions are tracked as [GitHub issues](https://guides.github.com/features/issues/). Create an issue on our main repository
and provide the following information:
- **Use a clear and descriptive title** for the issue to identify the suggestion.
- **Provide a step-by-step description of the suggested enhancement** in as many details as possible.
- **Provide specific examples to demonstrate the steps**.
- **Describe the current behavior** and **explain which behavior you expected to see instead** and why.
- **Explain why this enhancement would be useful** to most Terra users and isn't something that can or should be implemented as an addon.
### Pull Requests
This section guides you through submitting a pull request for Terra.
While the prerequisites above must be satisfied prior to having your pull request reviewed, the reviewer(s) may ask you to complete
additional design work, tests, or other changes before your pull request can be ultimately accepted.
#### Before Submitting A Pull Request
- You must be on the **LATEST** version of Terra to make sure your feature hasn't been added yet.
- Search for any [already existing issues](https://github.com/PolyhedralDev/Terra/issues?q=is%3Aissue+) (Including closed!) with your
problem. If you open a duplicate, it will be closed as such.
- Verify that this is actually within the scope of Terra.
- Be sure that this is not a feature request that should be made for a specific Terra *pack*, and instead applies to all of Terra.
- Be sure that this is not something that should be implemented as a Terra addon, and instead applies to all of Terra.
- Make sure that you attach a copy of the latest.log file, if there are any exceptions thrown in the console. Putting *just* the
exception **is not enough**. We need to be able to check that there wasn't anything else before that caused it.
#### How Do I Submit A (Good) Pull Request?
Pull Requests are tracked as [GitHub Pull Requests](https://guides.github.com/activities/forking/#making-a-pull-request). Create a pr on our
main repository and provide the following information:
- **Use a clear and descriptive title** to identify the pull request.
- **State what this pull request adds/fixes**.
- **Be sure that you are the owner of the code you contributed** or that it can be licensed under the GPLv3.
- **Provide a description goals and non-goals of the pull request** in as many details as possible.
- **Describe the current behavior** and **explain which behavior you expected to see instead** and why.
- **Explain why this enhancement would be useful** to most Terra users and isn't something that can or should be implemented as an addon.
## Styleguides
### Git Commits
Following this is not mandatory, but rather a set of guidelines. As long as your commit messages aren't absolutely awful, it's probably
fine. But it would be nice if you followed them.
#### Committing
When you commit code, try to avoid committing large amounts of code in a single go. Splitting up code into smaller commits is much nicer and
makes it easier to trace a feature to a single commit.
Try to stick to one feature/fix/etc. per commit. A good rule of thumb is if you need to use the word "and" in the subject line, then it
should probably™ be two commits.
#### Git Commit Messages
- Subject line must fit the following format: `<type>: <short summary>`. Type must be one of the following:
- Build: Changes that affect the build system or external dependencies.
- Docs: Documentation only changes.
- Feat: A new feature.
- Fix: A bug fix.
- Perf: Performance improvements.
- Refactor: Refactoring sections of the codebase.
- Repo: Changes to the repository structure that do not affect code. (Eg. modification of the `README.md` file, etc.)
- Revert: Revert a previous commit.
- Style: Code style updates.
- Test: Anything related to testing.
- Trans: Translation and localization of Terra to other languages.
- WIP: Work in progress.
- Separate the subject line from the body with a single blank line.
- Do not end subject line with a period.
- Limit the subject line to 50 or less.
- The subject line and all body lines should be in sentence case.
- Use the present tense. ("Add feature" not "Added feature")
- Use the imperative mood. ("Move cursor to..." not "Moves cursor to...")
- Reference relevant issues and pull requests in the body.
>
> Here is a template you can follow:
> ```
> Capitalized, short (50 chars or less) summary
>
> More detailed explanatory text, if necessary. Wrap it to about 72
> characters or so. In some contexts, the first line is treated as
> the subject of the commit and the rest of the text as the body. The
> blank line separating the summary from the body is critical (unless
> you omit the body entirely); various tools like `log`, `shortlog` and
> `rebase` can get confused if you run the two together.
>
> Explain the problem that this commit is solving. Focus on why you are
> making this change as opposed to how (the code explains that). Are
> there side effects or other unintuitive consequences of this
> change? Here's the place to explain them.
>
>
> Further paragraphs come after blank lines.
> - Bullet points are okay, too
> - Typically a hyphen or asterisk is used for the bullet, followed
> by a single space, with blank lines in between, but conventions vary
> here
> - Use a hanging indent
>
> Reference any relevant issues at the bottom, like so:
>
> Resolves: #123
> See also: #456, #789
> ```
### Code Styleguide
Use an IDE with support for `.editorconfig` files. There is an included editorconfig file in the base of the project so that your IDE should
automatically use the correct code style settings.
### Documentation Styleguide
TODO
## Coding Practices
### Compatibility
#### General Compatibility
General compatibility (example: injection of Vanilla structures/features/carvers into packs) is acceptable in the main project.
- General compatibility features should be *disabled by default*. Having things auto-injected causes unpredictable behaviour that is
annoying to diagnose. General-compatibility options should have config values attached which are disabled by default.
- These config options should also be *simple to use*. Think of the people who will be using these compatibility options. They want to flick
a switch and have things be compatible. That means that a majority of compatibility options should stay in `pack.yml`, to make it simple
to go into a pack and turn on specific compatibilities. This does *not* mean that more advanced compatibility options are off the table,
for example, look at Feature compatibility, where features can either be automatically injected, *or* configured individually per Terra
biome, depending on how much control the user wants.
#### Specific Compatibility
Specific compatibility should *not* be put in the main project. (Example: Adding the ability to generate TechCraft v7's doo-dads with a
TerraScript function)
Having specific compatibilities leads to tons of extra dependencies to keep track of, as well as adding lots of additional stuff to
maintain. It quickly becomes a mess. Especially when most users will never need to use this feature.
We have designed an addon API for exactly this purpose. **Specific compatibilities are welcome and encouraged, in the form of addons.**
### Platform-Agnostic Design
Terra must, at all times, remain platform agnostic. This means it must be able to run on theoretically any voxel based platform. Including
non-minecraft games like Terasology.
When adding a new feature to `common`, make no assumptions about what platform it'll be running on.
Examples:
- Don't assume the world height is 256.
- Don't assume that a specific block, item, or entity exists. (Eg. don't assume there exists a block called `minecraft:grass_block`)
### Data-Driven
When adding a new feature, make it abstract. Don't make assumptions about "specific use cases." If you can only think of a few use cases,
your idea should probably be generalized.
You must use configs effectively. Make configs that are *powerful* but also *make sense* and are \[easy\] to use.