Contributing Guidelines (Draft)

Below are a set of rules for contributing to the codebase, these are intended to help us manage the content being produced and to help you avoid unexpected surprises such as a pull-request being closed after it has been completed.

⚠️ Rules marked with an exclamation mark are important, and may be grounds for a ban if done negligently or maliciously.

Pull-Request Rules

Atomisation

• Aim to keep pull-requests as small as possible, each pull-request should aim to achieve a core goal and should only have the changes necessary to achieve that goal.
• All pull-requests should be prepared to justify why any included changes cannot be split from the pull-request.
• Large pull-requests (Likely to exceed 50 files) require approval. To acquire approval, create a post inside the thinktank forum channel on discord and explain your plans for the pull-request. This allows us to request atomisation of the content prior to any work being done.

Design/Balance

• Pull-requests that significantly touch design/balance must have a design goal in mind. This goal should be discussed to confirm that the intended goal aligns with the vision for the codebase.
• Pull-requests may be testmerged prior to completion so that feedback can be gathered along the way.
• The goal of early testing is to find the parts of the idea that need further tweaks. Pull-requests may be closed if the author is unable to adapt to these issues throughout development.

Some general tips:

• Don't be afraid to ask for testmerges, even in a somewhat early state.
• Do not stick to your initial ideas, be prepared to change them at every test.
• Identify a goal which explains how you want players to behave, do not try to achieve a specific theme/style as your goal as that limits the room for change.
• Discussing your ideas allows you to access information about similar ideas in the past which worked/failed.
• Do not decide all implementation details upfront, if your design is good then the implementation will come naturally as you continue to develop and test the idea.
• When making specific changes, think about how this fits into the original goal.
• Avoid creating goals to fit specific implementations, derive implementation details from the goal.
• If it feels like a constant uphill battle, then take a step back and rethink the core idea.
• Search for elegant solutions which have the most impact with the least amount of assumptions/changes, and do not require special conditions to handle specific scenarios.

Ports

• ⚠️ You must link to all pull-requests that you have taken code from, including partial ports or ports used to see how another codebase achieved something.
• ⚠️ You must not port content from a codebase with a different license without permission from both a Beestation maintainer, and every single contributor who worked on the content for that codebase. This includes Goonstation.
• If a port requires a dependency unrelated to the core content of the port, the dependency must be ported as a seperate pull-request unless the scope of the dependency is very small (such as a function that isn't used elsewhere).
• All ports must respect Beestation content and changes, and be fully prepared for the potentially significant work that may be required to adapt unique Beestation changes to work with the ported content.
• Ported content may be subject to significant feature requests so that the content fits with the vision for existing Beestation content. Prior to porting new content, you should discuss the ported content in the thinktank channel on discord by creating a forum post explaining your plans.

Licensing Rules

• ⚠️ Any time you include a sound file, you must indicate where you sourced that file from and update sound/attributions.txt.
• ⚠️ Any time you use content from somewhere else, if you cannot find a license then you are not allowed to use it.

Bounties

• Pull-requests completed for a private bounty should not disclose this information on the pull-request, so that the PR is treated like normal.
• Pull-requests for bounties do not get special exemptions to design rules and still need to be properly discussed prior to development, or may be closed upon completion.
• Bounties should not be advertised on the Github, we do not facilitate bounties and all bounties are done privately outside of Beestation.