cyberpresidentvanellope/Citadel-Station-13-RP
1
0
Fork 0
mirror of https://github.com/Citadel-Station-13/Citadel-Station-13-RP.git synced 2025-12-09 20:43:35 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update CONTRIBUTING.md

Browse Source 
Temporary Contributing Guidelines. Credit for most of the writing goes to BeeStation.
This commit is contained in:
Zandario
2020-09-20 21:45:06 -05:00
committed by GitHub
parent 428f1ae35e
commit 6a664ed66e
1 changed files with 71 additions and 53 deletions
Download Patch File Download Diff File Expand all files Collapse all files

124
.github/CONTRIBUTING.md vendored
View File

@@ -1,81 +1,99 @@
# Contributing to VOREStation
:+1::tada: First off, thanks for taking the time to contribute! :tada::+1:
# Contributing to Citadel Station 13 RP
The following is a set of guidelines for contributing to VOREStation, which is hosted in the [VOREStation Org](https://github.com/VOREStation) on GitHub.
These are just guidelines, not rules, use your best judgment and feel free to propose changes to this document in a pull request.
## Table of Contents
#### Table Of Contents
1. Introduction
2. Getting Started - Contributing for Dummies
3. Recommended Tools - Creating a Decent Dev Environment
4. Code Standards
5. Codebase-specific Policies
6. Asset Policy
7. Banned Content
[What should I know before I get started?](#what-should-i-know-before-i-get-started)
* [Code of Conduct](#code-of-conduct)
## 1. Introduction
Hello and welcome to Citadel Station's contributing page. You are presumably here because you are interested in contributing - thank you! Everyone is free to contribute to this project as long as they follow the simple guidelines and specifications below; at Citadel Station, we strive to maintain code stability and maintainability, and to do that, we need all pull requests to meet our standards. It's in everyone's best interests - including yours!
[How Can I Contribute?](#how-can-i-contribute)
* [Your First Code Contribution](#your-first-code-contribution)
* [VOREStation Coding Standards](#vorestation-coding-standards)
* [Pull Requests](#pull-requests)
* [Git Commit Messages](#git-commit-messages)
First things first, we want to make it clear how you can contribute (if you've never contributed before), as well as the kinds of powers the team has over your additions, to avoid any unpleasant surprises if your pull request is closed for a reason you didn't foresee.
[Licensing](#Licensing)
## 2. Getting Started - Contributing for Dummies
Citadel Station doesn't have any kind of design document outlining planned changes; we instead allow freedom for contributors to suggest and create their ideas for the game. That doesn't mean we aren't determined to squash bugs, which unfortunately pop up a lot due to the deep complexity of the game.
## What should I know before I get started?
If you want to contribute the first thing you'll need to do is set up a decent development environment. The default tools for working with BYOND simply aren't sufficient, and the next section explains what we use. We also have a few guides to help you get started with git and making a pull request:
### Code of Conduct
* [Here](https://forums.beestation13.com/t/github-building-the-hive/1334) is a guide for setting up Git and GitKraken.
This project adheres to the Contributor Covenant [code of conduct](CODE_OF_CONDUCT.md).
By participating, you are expected to uphold this code.
For beginners, it is strongly recommended you work on small projects like bugfixes or very minor features at first. While we are willing to assist you, we have no desire to write your code for you.
## How Can I Contribute?
**Please note that you need to credit anything that you port from other codebases.**
### Your First Code Contribution
There are a variety of ways to give credit, here is a list of our most strongly preferred method to least preferred:
1. Cherry-pick (Guide coming soon). May not always be feasible.
2. Provide a link to the specific pull request(s) in your pull request's description.
3. Mention the codebase it's from in your pull request description.
Unsure where to begin contributing to VOREStation? You can start by looking through the issues tab.
You can of course, as always, ask for help on our discord.
### VOREStation Coding Standards
## 3. Recommended Tools - Creating a Decent Dev Environment
Any code submissions that do not meet our coding standards are likely to be rejected, or at the very least, have a maintainer request changes on your PR. Save time and follow these standards from the start.
By default, the only thing BYOND provides people with is Dream Maker. It is hardly sufficient, and few (if any) contributors regularly use it. Instead, we have a variety of alternative tools for different purposes that make our lives a lot easier:
* If it is something like a bugfix that Polaris would want (the codebase we use), code it in their code and make the PR to them. We regularly update from them. They would want any general gameplay bugfixes, and things that are obviously intended to work one way, but do not. They do not have any of our fluff species (vulp, akula, fenn, etc) so do not make PRs related to that, or any vore content to them.
* Never edit stock Polaris .DMI files. If you are confused about which .DMI files we have added and which were there originally, refer to their repository and and see if they exist (https://github.com/PolarisSS13/Polaris). All PRs with edits to stock .DMI files will be rejected.
* When changing any code in any stock Polaris .DM file, you must mark your changes:
* For single-line changes: //VOREStation Edit - "Explanation" (Edit can also be Add for new lines or Removal if you are commenting the line out)
* For multi-line additions: //VOREStation Edit - "Explanation" and then at the bottom of your changes, //VOREStation Edit End
* For multi-line removals: Use a block comment (/\* xxx \*/) to comment out the existing code block (do not modify whitespace more than necessary) and at the start, it should contain /\* VOREStation Removal - "Reason"
* Change whitespace as little as possible. Do not randomly add/remove whitespace.
* Any new files should have "_vr" at the end. For example, "life_vr.dm". Just make them in the same location as the file they are related to.
* Map changes must be in tgm format. See the [Mapmerge2 Readme] for details.
* Git client - [GitKraken](https://www.gitkraken.com/)
* Code editing - [VSCode](https://code.visualstudio.com/) (NOT THE SAME AS VISUAL STUDIO)
* VSCode Extensions - [DM syntax highlighting](https://marketplace.visualstudio.com/items?itemName=gbasood.byond-dm-language-support), [DM language support](https://marketplace.visualstudio.com/items?itemName=platymuus.dm-langclient)
* Map editing - [FastDMM2](https://fastdmm2.ss13.io/) or [StrongDMM](https://github.com/SpaiR/StrongDMM)
The `attempt_vr()` proc has been added for your convienence. It allows a many-line change to become a single-line change in the existing Polaris files, preserving mergeability and allowing better code separation while preventing your new code from causing runtimes that stop the original code from running. If you are wanting to inject new procedures into an existing proc, called `update_atoms()` for example, you would create `update_atoms_vr()` in a nearby `_vr.dm` file, and then call to it from a single line in the original `update_atoms()` with `attempt_vr()`.
## 4. Code Standards
There are a variety of ways you can write valid DM code. However, maintaining good code standards is important for performance and readability reasons. Though as of this time, this has yet to be defined.
The syntax for `attempt_vr()` is: `attempt_vr(atom,"proc_name",list(arg1,arg2))`, where:
* `atom` should be replaced with what your extended proc is defined on (if you are in something like /obj/machine/scanner/proc/update_things() and you are calling your newly defined /obj/machine/scanner/proc/update_things_vr() you can just put `src` here)
* `proc_name` is a STRING that should be the name of your proc, such as "update_atoms_vr"
* `list(arg1,arg2)` should contain any args you wish to pass to the proc
## 5. Codebase-specific Policies
### HippieStation
HippieStation's code standards are much more lax than Citadel Station. Their code typically does not meet our standards. Therefore, you should not attempt to port code from HippieStation unless you have the experience and knowledge necessary to rewrite the code to our standards. Maintainers will not hold your hand for this, instead they will simply close the pull request.
As an example of something you can do with `attempt_vr()` in a single line, the grab and vore code is done with this in a single line. When a grab is clicked on someone, there is a line similar to:
`if(attempt_vr(src,"handle_grabs_vr",list(src,attacker))) return`
### Goonstation
**Attempting to use Goonstation code without using the steps outlined in this section is grounds for an immediate repoban.**
Then in our `handle_grabs_vr()` proc, if we want to avoid performing the stock game actions and have handled the vore stuff ourselves, we return true, and the original proc returns since attempt_vr returns true.
Goonstation's code license is not compatible with [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.en.html). Therefore, there are very specific steps that need to be taken in order to use Goonstation code:
1. Get approval from a Citadel Station Maintainer, explaining specifically what you want to port.
2. Get permission from **EVERY** code author that was involved with writing the code you wish to port.
3. Open the pull request. It must have "[GOON]" at the start of the pull request title. It must say "CONTAINS CODE FROM GOONSTATION" at the top of the pull request description. List **ALL** of the code authors somewhere in your pull request description.
4. Have **EVERY** code author from step two comment on your pull request giving you permission to use the code. The specifics of how they should word their comment can vary on a case-by-case basis.
5. Wait for final approval from a Citadel Station Maintainer. This will involve us reaching out to a Goonstation representative for their sign-off.
### Pull Requests
Failing to correctly follow any step will result in the pull request being closed. If done maliciously, it will also result in a repoban.
* Your submission must pass Travis CI checking. The checks are important, prevent many common mistakes, and even experienced coders get caught by it sometimes. If you think there is a bug in Travis, open an issue. (One known Travis issue is comments in the middle of multi-line lists, just don't do it)
* Your PR should not have an excessive number of commits unless it is a large project or includes many separate remote commits (such as a pull from Polaris). If you need to keep tweaking your PR to pass Travis or to satisfy a maintainer's requests and are making many commits, you should squash them in the end and update your PR accordingly so these commits don't clog up the history.
* You can create a WIP PR, and if so, please mark it with [WIP] in the title so it can be labeled appropriately. These can't sit forever, though.
* If your pull request has many no-conflict merge commits ('merge from master' into your PR branch), it cannot be merged. Squash and make a new PR/forcepush to your PR branch.
## 6. Asset Policy
Assets are things such as art, sprites, sounds, music, etc. Different policies apply depending on where the assets are from, so please look at the relevant subsection.
### Git Commit Messages
**If you are the sole creator of the assets and your work is not a derivative, you can ignore the remainder of this section.** Note that by contributing your assets, you are agreeing to license them under [CC-BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/).
* Limit the first line to 72 characters or less, otherwise it truncates the title with '...', wrapping the rest into the description.
* Reference issues and pull requests liberally.
* Use the GitHub magic words "Fixed/Fixes/Fix, Resolved/Resolves/Resolve, Closed/Closes/Close", as in, "Closes #1928", as this will automatically close that issue when the PR is merged if it is a fix for that issue.
**If you are not the sole creator, or if you created a derivative, then regardless of the source, you must give the creator credit in your pull request.**
## Licensing
VOREStation is licensed under the GNU Affero General Public License version 3, which can be found in full in LICENSE-AGPL3.txt.
### Assets from other SS13 servers (other than Goonstation)
Most Space Station 13 servers, with the notable exception of Goonstation, all use the same asset license: [CC-BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/). However, you always need to double-check. Most asset licenses are mentioned in the codebase's README. Therefore, as long as all assets you are adding are from another SS13 server with the [CC-BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/) asset license, you shouldn't have to worry as long as you give credit in your pull request.
Commits with a git authorship date prior to `1420675200 +0000` (2015/01/08 00:00) are licensed under the GNU General Public License version 3, which can be found in full in LICENSE-GPL3.txt.
### Assets from Goonstation
Goonstation uses a similar license, with the exception that their assets cannot be used commercially. All assets from Goonstation should be placed in the `goon` folder, which is licensed under [CC-BY-NC-SA 3.0](https://creativecommons.org/licenses/by-nc-sa/3.0/).
All commits whose authorship dates are not prior to `1420675200 +0000` are assumed to be licensed under AGPL v3, if you wish to license under GPL v3 please make this clear in the commit message and any added files.
### Assets from external (non-SS13) sources
All assets must comply with our asset license, [CC-BY-SA 3.0](https://creativecommons.org/licenses/by-sa/3.0/). You should always ask the author for permission to use their work.
[Mapmerge2 Readme]: ../tools/mapmerge2/readme.md
If you are adding new assets that are not already explicitly licensed under CC-BY-SA 3.0, you must get permission from the author using a very specific process. Them direct messaging you "Sure, you can use it" is not sufficient. You can speak to a Maintainer on Discord for more details.
**Attempting to add assets by falsely claiming it is CC-BY-SA 3.0 is grounds for an immediate repoban. If the offending pull request has been merged, it will immediately be reverted.**
If at any point you are confused or unsure of an asset's license or our policy, ask a Maintainer to help you.
## 7. Banned Content
Do not add any of the following in a Pull Request or risk getting the PR closed:
- Any content that violates GitHub Terms of Service.
- Racial or homophobic slurs of any kind.
- National Socialist Party of Germany content, National Socialist Party of Germany related content, or National Socialist Party of Germany references
- Code adding, removing, or updating the availability of alien races/species/human mutants without prior approval. Pull requests attempting to add or remove features from said races/species/mutants require prior approval as well.
Just because something isn't on this list doesn't mean that it's acceptable. Use common sense above all else.
Violations of the banned content policy can potentially result in a repoban.