diff --git a/.gitattributes b/.gitattributes deleted file mode 100644 index 8a313292bb1..00000000000 --- a/.gitattributes +++ /dev/null @@ -1 +0,0 @@ -*.dmm merge=merge-dmm diff --git a/.gitconfig b/.gitconfig deleted file mode 100644 index de5ff6f2542..00000000000 --- a/.gitconfig +++ /dev/null @@ -1,5 +0,0 @@ -[merge "merge-dmm"] - name = mapmerge driver - driver = ./mapmerge.sh %O %A %B - recursive = text - diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md new file mode 100644 index 00000000000..3d10f14d8e5 --- /dev/null +++ b/.github/CONTRIBUTING.md @@ -0,0 +1,166 @@ +# CONTRIBUTING + +## Introduction +This is the contribution guide for Paradise Station. These guidelines apply to +both new issues and new pull requests. If you are making a pull request, please refer to +the [Pull request](#pull-requests) section, and if you are making an issue report, please +refer to the [Issue Report](#issues) section, as well as the +[Issue Report Template](ISSUE_TEMPLATE.md). + +## Commenting +If you comment on an active pull request, or issue report, make sure your comment is +concise and to the point. Comments on issue reports or pull requests should be relevant +and friendly, not attacks on the author or adages about something minimally relevant. +If you believe an issue report is not a "bug", please report it to the Maintainers, or +point out specifically and concisely your reasoning in a comment on the issue report. + +## Issues +The Issues section is not a place to request features, or ask for things to be changed +because you think they should be that way; The Issues section is specifically for +reporting bugs in the code. Refer to ISSUE_TEMPLATE for the exact format that your Issue +should be in. + +#### Guidelines: + - Issue reports should be as detailed as possible, and if applicable, should include + instructions on how to reproduce the bug. + +## Pull requests +Players are welcome to participate in the development of this fork and submit their own +pull requests. If the work you are submitting is a new feature, or affects balance, it is +strongly recommended you get approval/traction for it from our forums before starting the +actual development. + +#### Guidelines: + - Pull requests should be atomic; Make one commit for each distinct change, so if a part + of a pull request needs to be removed/changed, you may simply modify that single commit. + Due to limitations of the engine, this may not always be possible; but do try your best. + - Document and explain your pull requests thoroughly. Detail what each commit changes, + and why it changes it. We do not want to have to read all of you commit names to figure + out what your pull request is about. + - Any pull request that is not solely composed of fixes or non gameplay-affecting + refactors must have a changelog. See [here](../html/changelogs/__CHANGELOG_README.txt) + for more details, and [here](../html/changelogs/example.yml) for an example changelog. + Alternatively, inline changelogs are supported through the format described + [here](https://github.com/ParadiseSS13/Paradise/pull/3291#issuecomment-172950466). + - Pull requests should not have any merge commits except in the case of fixing merge + conflicts for an existing pull request. New pull requests should not have any merge + commits. Use `git rebase` or `git reset` to update your branches, not `git pull`. + +#### BYOND Specific Guidelines: + - Any `type` or `proc` paths **must** use absolute pathing unless the file you are + working in primarily utilizes relative pathing. + - Paths must begin with `/`. It should be `/obj/machinery/fancy_robot`, + not `obj/machinery/fancy_robot`. + - New bases of datum must begin with `/datum/`. `/datum/arbitrary_datum`, + not `/arbitrary_datum`. + - Don't use strings in combination with `text2path()` unless the paths are being + dynamically created. Variables can contain normal paths just fine. + - Don't duplicate code. If you have identical code in two places, it should probably + be a new proc that they both can use. + - No magic numbers/strings. If you have a number or text that is important and used in + your code, make a `#DEFINE` statement with a name that clearly indicates it's use. + - Do not use one-line control statements (if, else, for, while, etc). The space saved + is not worth the decreased readability. + - Control statements comparing a variable to a constant should be formatted `variable`, + `operator`, `constant`. This means `if(count <= 10)` is preferred over + `if(10 >= count)`. + - **Never** use a colon `:` operator to bypass type safety checks, unless you are doing + something where the tiny performance increase is incredibly noticeable (eg, a loop for + a huge list). You should properly typecast everything and use the period `.` + operator. + - Use early returns, and avoid far-indented if blocks. This means that you should not + do this: + ``` + /datum/datum1/proc/proc1() + if (thing1) + if (!thing2) + if (thing3 == 30) + do stuff + ``` + Instead, you should do this: + ``` + /datum/datum1/proc/proc1() + if (!thing1) + return + if (thing2) + return + if (thing3 != 30) + return + do stuff + ``` + - Any pull requests that affect map files must use the map-merge tools. Pull requests + that do not follow this guideline will be automatically declined, unless explicit + permission was given. + - The following examples of code are present in the code, but are no longer acceptable: + - To display messages to all mobs that can view `src`, you should use + `visible_message()`. + - Bad: + ``` + for (var/mob/M in viewers(src)) + M.show_message("Arbitrary text") + ``` + - Good: + ``` + visible_message("Arbitrary text") + ``` + - You should not use color macros (`\red, \blue, \green, \black`) to color text, + instead, you should use span classes. `red text`, + `blue text`. + - Bad: + ``` + usr << "\red Red Text \black black text" + ``` + - Good: + ``` + usr << "Red Textblack text" + ``` + - To use variables in strings, you should **never** use the `text()` operator, use + embedded expressions directly in the string. + - Bad: + ``` + usr << text("\The [] is leaking []!", src.name, src.liquid_type) + ``` + - Good: + ``` + usr << "\The [src] is leaking [liquid_type]" + ``` + - To reference a variable/proc on the src object, you should **not** use + `src.var`/`src.proc()`. The `src.` in these cases is implied, so you should just use + `var`/`proc()`. + - Bad: + ``` + var/user = src.interactor + src.fillReserves(user) + ``` + - Good: + ``` + var/user = interactor + fillReserves(user) + ``` + + +## Maintainers +The only current official role for GitHub staff are the `Maintainers`. There are up to +three `Maintainers` at once, and they share equal power. The `Maintainers` are +responsible for properly tagging new pull requests and issues, moderating comments in +pull requests/issues, and merging/closing pull requests. + +### Maintainer List + - [MarkvA](https://github.com/Markolie) + - [Fox P McCloud](https://github.com/Fox-McCloud) + - [TheDZD](https://github.com/TheDZD) + +### Maintainer instructions + - Do not `self-merge`; this refers to the practice of opening a pull request, then + merging it yourself. A different maintainer must review and merge your pull request, no + matter how trivial. This is to ensure quality. + - A subset of this instruction: Do not push directly to the repository, always make a + pull request. + - Wait for the Travis CI build to complete. If it fails, the pull request may only be + merged if there is a very good reason (example: fixing the Travis configuration). + - Pull requests labeled as bugfixes and refactors may be merged as soon as they are + reviewed. + - The shortest waiting period for -any- feature or balancing altering pull request is 24 + hours, to allow other coders and the community time to discuss the proposed changes. + - If the discussion is active, or the change is controversial, the pull request is to be + put on hold until a consensus is reached. \ No newline at end of file diff --git a/.github/ISSUE_TEMPLATE.md b/.github/ISSUE_TEMPLATE.md new file mode 100644 index 00000000000..d7646ecb97b --- /dev/null +++ b/.github/ISSUE_TEMPLATE.md @@ -0,0 +1,17 @@ +**Problem Description**: +What is the problem? + +**What did you expect to happen**: +Why do you think this is a bug? + +**What happened instead**: +How is what happened different from what you expected? + +**Why is this bad/What are the consequences:** +Why do you think this is an important issue? + +**Steps to reproduce the problem**: +The most important section. Review everything you did leading up to causing the issue. + +**Possibly related stuff (which gamemode was it? What were you doing at the time? Was +anything else out of the ordinary happening?)**: Anything else you can tell us. \ No newline at end of file