Design Guidelines

Prison exists to be the one-stop solution for any prison server to have a powerful plugin running its prison-related systems at no cost. We have strict goals and guidelines to uphold this mission. They are outlined here.

Goals

• No paywall. Prison and its essential modules should not cost money. We believe that everyone deserves a strong and well-supported ecosystem to run their server. Non-essential modules, however, may charge for download.
• Heavily tested. Prison should be usable by even the most player-intensive prison servers. Both Prison itself and its modules all must be heavily tested before each release to ensure nothing interrupts the experience for both players and users.
• Open source. Prison and its essential modules should be open source. Server administrators with the ability to edit the plugin to suit their needs may do so. Also, community involvement and contribution, either via documentation, code, or feedback, is heavily encouraged.

Guidelines

Google Java Style

We use the Google Java Styleguide to format our code. This is to ensure uniformity and readability across the platform.

Semantic coloring

By default, all messages should be in the grey (&7) color. For emphasizing certain text, modules may use one of three colors in any given message.

For errors, the emphasis color should be red (&c).

For warnings, the emphasis color should be gold (&6).

For informational messages (i.e. not errors or warnings), the emphasis color should be aqua (&3).

For de-emphasis, the text should be in dark grey (&8). De-emphasis is useful when giving extra information, such as directing the user to the tickets page after an error, or giving the user instructions before listing commands.

Language

By default, all modules and core APIs should be written in English. English is a very widely-understood language and can also be translated to many other languages. If English is not your native language and you wish to contribute, you are allowed to contribute but your work will be translated to English.

More coming soon.

Ready to submit? Perform the checklist below:

Contribution Checklist

If you're ready to submit some code for review, please ensure you've followed this checklist.

1. Have all tabs been replaced into four spaces? Are indentations 4-space wide?
2. Have I written proper Javadocs for my public methods? Are the @param and @return fields actually filled out?
3. Have I git rebased my pull request to the latest commit of the target branch?
4. Have I combined my commits into a reasonably small number (if not one) commit using git rebase?
5. Have I made my pull request too large? Pull requests should introduce small sets of changes at a time. Major changes should be discussed with the team prior to starting work.
6. Are my commit messages descriptive?

You should be aware of git rebase. It allows you to modify existing commit messages, and combine, break apart, or adjust past changes.