Update CONTRIBUTING.md

.github/ISSUE_TEMPLATE/bug_report.md

@@ -16,9 +16,10 @@ assignees: ''
 ## Laptop
 *Are you running this on a laptop? Does it have a hybrid iGPU+ dGPU configuration?*
 
+## Describe the issue
+*what's the issue?*
+
 ## Attached log.txt file, if available
 > [!WARNING]
 > Please make sure you remove any personally identifiable information from the log file.
-
-## Describe the issue
-*what's the issue?*
+> Please set `-loglevel` to `all` before launching the game for more verbose logs.

CONTRIBUTING.md

@@ -27,5 +27,57 @@ Therefore, when making code changes, please be extremely careful about containin
 * Make sure you compile with the included Docker script and ensure you do not introduce **any** new compiler warnings or build breaks. The Docker script is the standard build environment, your custom Linux build environment or MSVC can be used during development, but you must validate the final build using Docker.
 * Do not submit snippets of code as a "patch". Exceptions can be made for trivial changes (correct a typo, fix a single line of code...), but otherwise, a successfully compiled & fully tested patch file is required when submitting for review.
 * Do not make code changes in unrelated areas; i.e., do not run code linters and auto-formatters for parts of the code that you didn't modify.
-  * Note: there are no strict rules for code formatting, but please attempt to emulate the style around the code you are modifying.
 * Try to submit smaller chunks of code, instead one gigantic patch. For example, don't submit a patch for "Improve feature XYZ"; instead, submit "Change how A works to prepare for feature XYZ" "Refactor B for feature XYZ" "Add feature B to enable feature XYZ".
+* Write to the log for anything useful - it helps immensely with debugging post-mortem. At the same time though, avoid spamming the log for something trivial.
+
+### UI text
+spice2x has a global audience; majority of the user base do not speak English as their first language.
+
+Use simple English, avoid colloquialism, and use concise language, even if it's slightly technical.
+
+### Using OS APIs
+
+Avoid making permanent changes to user's OS configuration. For example, spice should not make a call to set power profile to Maximum Performance, or switch default audio device. Making the reverse call to restore settings on game shutdown is **not** good enough; there is no guarantee that spice will gracefully shutdown, since games (or spice) can crash. This is to avoid inadvertently putting user's PC into a bad state, which can be seen as malware-like behavior.
+
+Watch out for legacy OS compatibility. Currently, the minimum support floor is Windows 7. If you use any Windows API, make sure it's supported in Windows 7. If you need to use API that is not present in Windows 7, you must not directly link against it, otherwise spice will fail to launch on older OSes. Take a look at Windows 8 touch code (win8.cpp) for examples on how to discover OS APIs via pointers.
+
+### Code style requirements
+* Indents are four spaces.
+* Always use \{ curly braces \} when appropriate; do not omit them even when it's optional; such as `for` `if` `else`, etc.
+
+OK:
+```c
+if (conditional) {
+    DoSomething();
+}
+```
+
+Not OK:
+```c
+if (conditional)
+    DoSomething();
+```
+
+Not OK:
+```c
+if (conditional) DoSomething();
+```
+
+* Opening curly braces should appear at the end, not in a line on its own.
+
+OK:
+```c
+if (conditional) {
+    DoSomething();
+}
+```
+
+Not OK:
+```c
+if (conditional)
+{
+    DoSomething();
+}
+```
+
+* Other than that, there are no strict rules for code formatting, but please attempt to emulate the style around the code you are modifying.