First and foremost, thanks for taking your time to contribute! ❤️
Any type of contribution is welcome and valued. UnderscoreEnchants has got a list of guidelines to be followed whilst contributing for the sake of easier maintenance of the project. Take a look at the table o' contents for reference. The community looks forward to your contributions 😊
Please note that the baseline for all contributions is the Code of Conduct.
- How to contribute
- How to suggest a feature
- How to report a bug
- Code styling
- Join the development team
Once again, thanks for being with us! If you are here to contribute any code, extra documentation, or anything else, this paragraph is for you.
You should not be contributing if you have nothing to bring to the table. Here are the general guidelines:
Contributions that...
- only focus on fixing code style;
- only optimize something;
- only add unit tests;
- only add/remove easter eggs
are not welcome.
In addition, contributions that largely refactor a big part of the code just for the sake of structuring are frowned upon, but not forbidden. However, care to document the new code structure in the commit message for it to have a chance to be accepted.
Contributions that...
- fix bugs;
- add new API methods or fix its implementations;
- add features;
- refactor a minor but tedious part of the code (such as removing a clearly redundant variable in 100 places) are welcome.
- The added code must be tested in game.
- Having said that, if a new feature can have a unit test, it should have a unit test. This also applies to API implementations.
- The code should be as optimized as possible.
- If Kotlin can be used, it should be used. While Java code is still welcome, it's frowned upon, for the project is slowly moving to fully Kotlin.
Java 19
This project relies on the Git VCS for convenience. As such, you're expected to be familiar with it and how to create PRs.
Developer Certificate of Origin, version 1.1
Developer Certificate of Origin
Version 1.1
Copyright (C) 2004, 2006 The Linux Foundation and its contributors.
Everyone is permitted to copy and distribute verbatim copies of this
license document, but changing it is not allowed.
Developer's Certificate of Origin 1.1
By making a contribution to this project, I certify that:
(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or
(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or
(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.
(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.
A commit message must be fairly small, yet informative.
- The first line should be the general commit idea.
- The second line should be left empty.
- Everything else should be wrapped to not be longer than 90 characters - if it is, put it on a new line (except for URLs).
- If the commit message has any general links or such information (such as "References"), they should be put on the last lines.
Example of a good commit message:
sum: Adding a new trigger
A new trigger, "PLAYERLEAVEBED", has been added. This will allow for users detect
players leaving their beds. Can be useful for some armor enchantments.
Aliases:
- PLAYERLEAVEBED
- PLAYERBEDLEAVE
- WAKEUP
- PLAYERWAKEUP
- GETUP
- PLAYERGETUP
Reference: issue #52 (request: add player leave bed)
Suggesting features is also contribution in a way! That said, there are some guidelines for suggesting features.
You can suggest features in GitHub Issues. If you do not feel like it, you are always welcome to write at #suggestions in my Support Discord server.
What makes a good feature suggestion is the research behind it.
- Make sure that there's no (recent) issue already open on that topic.
- If you're going to use Discord, take a look at the last couple messages in #suggestions, because maybe such feature has been proposed recently.
- Really make sure that the feature isn't already there. For example, there's no reason for an "expect-all-fail" condition flag, because conditions can be negated.
If it's a minor bug, report it in GitHub Issues. However, if it's a major exploitable bug or a security exploit, refrain from using issues, and instead open a ticket in my Support Discord server. Before opening an issue, please also make sure that there's no (recent) issue already open on that bug.
Are you ready to make your first contribution to UnderscoreEnchants? Well then, have at it! While writing code, please make sure to follow some code styling code guidelines.
- UnderscoreEnchants code is K&R-styled. There are some minor adjustments:
// For short one-line expressions, this is acceptable, but not preferred
if (1 == 2)
return
// Instead, this is preferred
if (1 == 2) return
// However, for long one-line expressions, this is acceptable, but not preferred
if (1 == 2) bake().cook().doSomethingElse().extraLong().maybe().optional().veryLongMethod()
// Instead, this is preferred
if (1 == 2)
bake().cook().doSomethingElse().extraLong().maybe().optional().veryLongMethod()- Not every single method should be documented, but if the name isn't clear enough, it should be. Moreover, any method in a utility class (such as Utils, ActionUtils) should be documented.
- If a variable can be final, it should be.
- If a Lombok annotation can be used, it should be (exceptions: @SneakyThrows, reason - Kotlin doesn't like it).
- The code indentation is 2 spaces for Kotlin/Java and 4 spaces for XML!
As of update 2.1, the plugin is developed solely by RoughlyUnderscore. As such, if you're ready to dedicate time and patience to this project, contact me via a ticket in my support Discord server and we'll figure something out!