diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index 20b2ba8d..488cd3e8 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -7,10 +7,9 @@ "features": { "ghcr.io/devcontainers/features/java:1": { - "version": "17", - "installMaven": "false", - "installGradle": "true", - "postCreateCommand": "java -version && chmod +x gradlew" + "version": "21", + "installMaven": "true", + "installGradle": "false" } } diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md index f897c595..426093ed 100644 --- a/.github/CODE_OF_CONDUCT.md +++ b/.github/CODE_OF_CONDUCT.md @@ -54,11 +54,7 @@ further defined and clarified by project maintainers. ## Enforcement -Instances of abusive, harassing, or otherwise unacceptable behavior may be -reported by contacting the project team at [kontakt@buzcraft.de](https://crazycloudcraft.de). All -complaints will be reviewed and investigated and will result in a response that -is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. +The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately. Project maintainers who do not follow or enforce the Code of Conduct in good diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md deleted file mode 100644 index 29dfaab2..00000000 --- a/.github/CONTRIBUTING.md +++ /dev/null @@ -1,168 +0,0 @@ -# Contributing Guidelines - -First off, thank you for considering contributing to this project. It's people like you that make this such a great plugin. - -Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project. In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests. - -This 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 the plugin itself. - -Please, don't use the issue tracker for [requesting new plugins](https://www.spigotmc.org/threads/open-small-to-medium-plugin-development-pay-what-you-want-8-years-experience-high-quality.435578/). Read the post on the Spigot board or send me a [email](mailto://me@silthus.net). - -# Ground Rules - -By contributing to this project you submit to following our [code of conduct](.github/CODE_OF_CONDUCT.md). -Please read this next section carefully and check if your contribution meets all requirements in this checklist. This will save you and us a lot of time. - -## Issues: Feature Requests & Bug Reports - -Please make sure you checked all of the following before submitting a new issue. - -* Before submitting a new issue, search the existing (including closed) issues for any duplicates. -* If you found an existing issue - use the react feature to show you have the same problem or need the same feature. Don't post comments like +1. -* Use the Bug & Feature Issue templates and provide all the required information. -* Be as detailed as possible and include screenshots wherever possible. This will help reproducing your bug or understanding your feature request. -* Use the WorldGuard `/wg report -p` command to provide detailed debug information and post the pastebin link in the issue. - -## Contributing Code - -Pull requests are the best way to propose changes to the codebase (we use [Github Flow](https://guides.github.com/introduction/flow/index.html)). We actively welcome your pull requests: - -* **Commit using the [conventional-commit](https://www.conventionalcommits.org/en/v1.0.0/) format!** -* Create issues for any major changes and enhancements that you wish to make. Discuss things transparently and get community feedback. -* Keep feature versions as small as possible, preferably one new feature per version. -* Be welcoming to newcomers and encourage diverse new contributors from all backgrounds. - -# Your First Contribution - -Unsure where to begin contributing to this project? You can start by looking through these beginner and help-wanted issues: -Good first issues - issues which should only require a few lines of code, and a test or two. -Help wanted issues - issues which should be a bit more involved than beginner issues. - -Working on your first Pull Request? You can learn how from this *free* series, [How to Contribute to an Open Source Project on GitHub](https://egghead.io/series/how-to-contribute-to-an-open-source-project-on-github). - -At this point, you're ready to make your changes! Feel free to ask for help; everyone is a beginner at first :smile_cat: - -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. - -# Getting started - -1. Fork the repo and create your branch from `master`. -2. If you've added code that should be tested, add tests. -3. If you've changed APIs or added new features, update the documentation. -4. Ensure the test suite passes. -5. Test your changes on a server running the latest supported Minecraft version. -6. Issue that pull request! - -> You can use the `Setup Server` gradle task to quickly get your test server setup. Then use the `deploy` task to compile and copy your plugin.jar to the server. - -# Code review process - -The core team will look at your change as soon as possible and review it. However since this a project that is done in free time, reviewing might sometimes take some time. - -# Code, commit message and labeling conventions - -We have very precise rules over how our git commit messages can be formatted. This leads to **more -readable messages** that are easy to follow when looking through the **project history**. - -It is important to note that we use the git commit messages to **generate** the [CHANGELOG](CHANGELOG.md) document. Improperly formatted commit messages may result in your -change not appearing in the CHANGELOG of the next release. - -### Commit Message Format -Each commit message consists of a **header**, a **body** and a **footer**. The header has a special -format that includes a **type**, a **scope** and a **subject**: - -```html -(): - - - -