Compare commits

...

5 Commits

Author SHA1 Message Date
sp2xdev a7e7eb36be Update CONTRIBUTING.md 2024-07-15 19:04:13 -07:00
sp2xdev 962db5d4d4 Update CONTRIBUTING.md 2024-07-15 19:03:50 -07:00
sp2xdev b59db8dd14 Update CONTRIBUTING.md 2024-07-15 19:03:36 -07:00
sp2xdev 680e7a7bda Update issue templates 2024-07-15 19:02:45 -07:00
sp2xdev 5e67ce5067 Update CONTRIBUTING.md 2024-07-15 18:56:39 -07:00
2 changed files with 9 additions and 0 deletions
@@ -10,6 +10,7 @@ assignees: ''
> [!NOTE]
> Before submitting code changes...
> * Please do note that this is a GPL v3.0 open source project.
> * Please read the [CONTRIBUTING](https://github.com/spice2x/spice2x.github.io/blob/main/CONTRIBUTING.md) guide.
> * Maintainers reserve the right to reject or modify your submission without reason.
> * If accepted, your github user name will be credited on the main web page, and then archived in the [past versions wiki page](https://github.com/spice2x/spice2x.github.io/wiki/Past-versions-and-change-log)
>
+8
View File
@@ -9,6 +9,14 @@ Baseline rules for patch submissions are as follows. Any patches violating the r
* For a new game that was never supported (not a new version of a game, but rather a new series): please wait 1 year after official AC release in Japan.
* For new version of an already supported game: proceed with caution and use generally-accepted community guidelines.
### Avoiding regressions
The biggest risk in making code changes to spice is the risk of regressions. There is a **lot** of shared code used by many different games, reaching back game versions that are more than a decade old. It is practically impossible to test all supported games and versions.
Additionally, there's a lot of code that get exercised on specific hardware - including hardware that you probably don't have access to (e.g., ICCA reader, real cabinet I/O, specific model of a IIDX controller, particular brand of touch screens...)
Therefore, when making code changes, please be extremely careful about containing / scoping your changes. Make targeted bug fixes scoped to handful of game versions and hardware configuration. When adding new features, make it off by default, unless there is a really good reason to make it the default. If you make a new default, add an option that disables it so that users can opt out as needed.
### Code quality requirements
* Test for regressions, at least in and around the component you are modifying: