cyberpresidentvanellope/VOREStation
1
0
Fork 0
mirror of https://github.com/VOREStation/VOREStation.git synced 2026-07-13 16:13:49 +01:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #15089 from VOREStation/Heroman3003-patch-1

Browse Source 
Update some .md to match current state of things
This commit is contained in:
Heroman3003
2023-06-28 21:53:48 +10:00
committed by GitHub
parent cf569a125d 75a24d4661
commit c19098e19d
1 changed files with 2 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/CONTRIBUTING.md
+2 -3
View File
@@ -36,14 +36,13 @@ Unsure where to begin contributing to VOREStation? You can start by looking thro
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.
* If it is something like a bugfix that Polaris would want (the codebase we use), you may want to consider coding it there as well. They may 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.
* Change whitespace as little as possible. Do not randomly add/remove whitespace.
* Map changes must be in tgm format. See the [Mapmerge2 Readme] for details, or use [StrongDMM] which can automatically save maps as tgm.
### Pull Requests
* Your submission must pass 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 CI, open an issue. (One known CI 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 CI 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.
* Your PR should not have an excessive number of commits unless it is a large project or includes many separate remote commits. If you need to keep tweaking your PR to pass CI 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 **and make it a draft pr** 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.
@@ -61,4 +60,4 @@ Commits with a git authorship date prior to `1420675200 +0000` (2015/01/08 00:00
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.
[Mapmerge2 Readme]: ../tools/mapmerge2/mapmerge tool readme.md
[StrongDMM]: ../tools/StrongDMM/README.md
[StrongDMM]: ../tools/StrongDMM/README.md