Add CONTRIBUTE document

Author: xezon

CONTRIBUTE.md

@@ -0,0 +1,108 @@
+# How to contribute as developer
+
+To make contributions, aka Pull Requests, fork and clone this repository.
+
+## Code Guidelines
+
+### 1. Scope of code changes
+
+Code edits only touch the lines of code that serve the intended goal of the change. Big refactors should not be combined with logical changes, because these can become very difficult to review. If a change requires a refactor, create a commit for the refactor before (or after) creating a commit for the change. A Pull Request can contain multiple commits and must be merged with **Merge with Rebase** accordingly.
+
+### 2. Style of code changes
+
+Code edits should fit the nearby code in ways that the code style reads consistent, unless the original code style is bad. The original game code uses c++98, or a deviation thereof, and is simple to read. Prefer to not use new fancy language features where not absolutely necessary to get a particular change done.
+
+### 3. Language style guide
+
+*Work in progress. Needs a maintainer. Can be built upon existing Code guidelines, such as the "Google C++ Style Guide".*
+
+
+## Change Documentation
+
+User facing changes need to be documented in code, Pull Requests and change logs. All documentation ideally is written in the present tense, and not the past.
+
+Good:
+
+> Fixes particle effect of USA Missile Defender
+
+Bad:
+
+> Fixed particle effect of USA Missile Defender
+
+When a text refers to a faction unit, structure, upgrade or similar, then the unit should be worded without any abbrevations and should be prefixed with the faction name. Valid faction names are USA, China, GLA, Boss, Civilian. Subfaction names can be appended too, for example GLA Stealth.
+
+Good:
+
+> Fixes particle effect of USA Missile Defender
+
+Bad:
+
+> Fixes particle effect of MD
+
+
+### 3. Code Documentation
+
+User facing changes need to be accompanied by comment(s) where the change is made. Maintenance related changes, such as compilation fixes, typically do not need commenting, unless the next reader can benefit from a special explanation. The comment can be put at the begin of the changed class, function or block. It must be clear from the change description what has changed.
+
+The expected comment format is
+
+```
+// TheSuperHackers @keyword author DD/MM/YYYY A meaningful description for this change.
+```
+
+The `TheSuperHackers` word and `@keyword` are mandatory. `author` and date can be omitted when preferred.
+
+| Keyword          | Use-case                                                    |
+|------------------|-------------------------------------------------------------|
+| @bugfix          | Fixes a bug                                                 |
+| @fix             | Fixes something, but is not a user facing bug               |
+| @compile         | Addresses a compile warning or error                        |
+| @feature         | Adds something new                                          |
+| @performance     | Improves performance                                        |
+| @refactor        | Moves or rewrites code, but does not change the behaviour   |
+| @tweak           | Changes values or settings                                  |
+| @info            | Writes useful information for the next reader               |
+| @todo            | Adds a note for something left to do if really necessary    |
+
+Block comment sample
+
+```
+    // TheSuperHackers @bugfix JAJames 17/03/2025 Fix uninitialized memory access and add more Windows versions.
+    memset(&os_info,0,sizeof(os_info));
+```
+
+
+### 4. Pull Request Documentation
+
+The title of a new Pull Request, and/or commit(s) within, begin with a **[GEN]** and/or **[ZH]** tag, depending on the game(s) it targets. If a change does not target a game, then a tag is not necessary. Furthermore, the title consists of a concise and descriptive sentence about the change and/or commit, beginning with an uppercase letter and ending without a dot. The title ideally begins with a word that describes the action that the change takes, for example `Fix *this*`, `Change *that*`, `Add *those*`, `Refactor *thing*`.
+
+Good:
+```
+[GEN][ZH] Fix uninitialized memory access in Get_OS_Info
+```
+
+Bad:
+```
+Minimal changes for successful build.
+```
+
+If the Pull Request is meant to be merged with rebase, then a note for **Merge with Rebase** should be added to the top of the text body, to help identify the correct merge action when it is ready for merge. All commits of the Pull Request need to be properly named and need the number of the Pull Request added as a suffix in parantheses. Example: **(#333)**. All commits need to be able to compile on their own without dependencies in newer commits of the same Pull Request. Prefer to create changes for **Squash and Merge**, as this will simplify things.
+
+The text body begins with links to related issue report(s) and/or Pull Request(s) if applicable.
+
+To write a link, use the following format:
+
+```
+* Relates to #555
+* Follow up for #666
+* Fixes #222
+```
+
+Some keywords are interpreted by GitHub. Read about it [here](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue).
+
+The text body continues with a description of the change in appropriate detail. This serves to educate reviewers and visitors to get a good understanding of the change without the need to study and understand the associated changed files. If the change is controversial or affects gameplay in a considerable way, then a rationale text needs to be appended. The rationale explains why the given change makes sense.
+
+
+### 5. Change Log Documentation
+
+*Work in progress.*