Merge remote-tracking branch 'upstream/develop' into random-anims

# Conflicts:
#	CREDITS.md
#	docs/New-or-Enhanced-Logics.md
#	docs/Whats-New.md
#	src/Ext/Techno/Body.Update.cpp
#	src/Ext/Techno/Body.h
#	src/Ext/TechnoType/Body.cpp
#	src/New/Entity/ShieldClass.cpp

Author: Coronia

.github/pull_request_template.md

@@ -1 +1,2 @@
-<!-- Please add [Minor] to the title or the description if this change should not be mentioned in documentation, what's new and no credit needs to be given. -->
+<!-- Please add [Minor] to the title or the description if this change should not be mentioned in documentation, what's new and no credit needs to be given.
+If the changes are solely made to the documentation, please set the target branch to the pull request named "Weekly Regular Documentation Revisions", rather than the repository's existing branches. -->

CREDITS.md

@@ -19,6 +19,8 @@
   </ItemGroup>
   <ItemGroup>
     <ClCompile Include="src\Ext\TechnoType\Hooks.MatrixOp.cpp" />
+    <ClCompile Include="src\Ext\Unit\Hooks.Sinking.cpp" />
+    <ClCompile Include="src\Misc\Hooks.AlphaImage.cpp" />
     <ClCompile Include="src\New\Entity\AttachEffectClass.cpp" />
     <ClCompile Include="src\New\Type\AttachEffectTypeClass.cpp" />
     <ClCompile Include="src\Commands\Commands.cpp" />

Phobos.vcxproj

@@ -15,6 +15,8 @@
 
 While Phobos is independent of Ares and does NOT require Ares specifically to function, Phobos complements some of the features found in Ares and vice versa.
 
+EA has not endorsed and does not support this product.
+
 Community
 ---------
 
@@ -54,6 +56,8 @@ Documentation
 -------------
 
 - [Official docs](https://phobos.readthedocs.io) (also available in [Chinese](https://phobos.readthedocs.io/zh_CN/latest))
+- [Community Chinese docs](https://docs.qq.com/doc/p/dc3da1ce39a6e787b6e133f7d33d6aebef581cb4)
+  - Because the Chinese translation of the official docs is currently underdeveloped, at the time it is recommended to use the community docs for Chinese users.
 
 You can switch between versions (displays latest develop nightly version by default) in the bottom right corner, as well as download a PDF version.
 

README.md

@@ -2,7 +2,54 @@
 
 This page describes ways to help or contribute to Phobos and lists the contributing guidelines that are used in the project.
 
-## Guidelines for contributors
+## Project guidelines and policies
+
+### Phobos maintenance crew structure
+
+Due to the size of the project and varying complexity of the codebase, we have established a maintenance crew structure to help with the project's development and maintenance. The structure is as follows:
+
+- **Leads** (or `T3` maintainers) - primary decision makers, define where the project is headed and have the final say in case of disputes. They are responsible for the project's vision and direction, and are the main point of contact for the community.
+- **`T2` maintainers** - assigned to more complex PRs, can make releases.
+- **`T1` maintainers** - assigned to less complex PRs.
+- **Triages** - help triage/label/assign PRs, issues, discussions, help with communication with the community.
+
+Those roles are assigned based on the complexity of the PRs and the experience of the contributors. The roles are not fixed and can change based on the contributor's experience and the complexity of the PRs they are working on. Also only the commonly occured roles are established in the list, in case of need - individual permissions can be assigned to contributors by leads (for example, to help with documentation translations).
+
+### Types of contributions
+
+To distribute the workload and make the project more manageable, we have established several commonly occuring types of contributions that can be made to the project. These types are as follows:
+
+- Phobos bugfixes, including reconnection error (desync), crash (fatal error) fixes, and documentation fixes
+  - `T1` complexity by default
+- Vanilla bugfixes
+  - `T1` complexity by default
+- Unhardcodings/customizations - contributions that only make something customizable through the INI or other way (by the modder usually), without adding too much code to handle the customization
+  - `T1` complexity by default
+- New features
+  - Extensions of existing systems - add logic to existing systems, doesn't warrant it's own entity or type classes generally, but may introduce new hooks
+    - Examples: feedback weapon logic, superweapon launch warhead logic, a new type of trajectory that uses existing custom trajectory framework, etc.
+    - `T1` or `T2` complexity by default, depending on judgement of the one who assigns the PR
+  - New systems - generally with their own classes that don't extend game classes/logics (or have such amount of code that should be separated into separate classes)
+    - Examples: custom trajectories framework, interceptor logic, shield logic, etc.
+    - `T2` complexity by default
+- Contributions to project infrastructure - changes to the project's build system, CI, documentation, etc.
+  - `T2` complexity by default
+- Project policy changes - changes to the project's guidelines, contributing guidelines, etc.
+  - `T3` complexity by default (has to be reviewed by leads)
+
+```{hint}
+Modders are highly encouraged to submit feedback on reusability of added features (preferably most important takeaways should be tracked in pull requests, discussions and issues) in order to not bloat the project with one-off features.
+```
+
+The list is not exhaustive, you are welcome to propose/submit changes to it (or to any project policies in order to improve how the project is maintained).
+
+In absence of a fitting category - a lead should review it.
+
+What can make any PR more controversial and requiring a higher level maintainer's assignment:
+- Modifying/breaking previous (or vanilla) behavior
+- Requiring migration
+- Mixing contribution types
+- Current level of maintainers not being sure about whether they can judge this PR
 
 ### Project structure
 
@@ -194,7 +241,7 @@ When you clone Phobos recursively - you also clone YRpp as a submodule. Basicall
 
 The suggested workflow is as follows:
 1. In your IDE of choice rename fields and functions using symbol renaming feature (`Rename...` feature in Visual Studio (regular or Code), `[F2]` by default), then you will have two "levels" of changes displayed in your Git client:
-   - for Phobos repository - changes in the Phobos code (as regular changes) and changes to YRpp (as one submodule change)
+   - for Phobos repository - changes in the Phobos code (as regular changes) and changes to YRpp (as one submodule change).
    - for YRpp repository - changes to the field names and function names in YRpp as regular changes.
 2. Create a branch in YRpp repository (create a fork of it if you didn't yet), commit and push the changes and submit it as a pull request. After pushing it you have two options in Phobos repository:
    - wait until it's accepted, then checkout YRpp at the newest commit, then commit and push - this will save you having to commit and push multiple times, but you won't be able to get a nightly build for people to test;