Merge remote-tracking branch 'upstream/develop' into develop-trajecto…

…ry-engrave

CREDITS.md

@@ -330,6 +330,7 @@ This page lists all the individual contributions to the project by their author.
    - Turret/Barrel/NoSpawnAlt/Multi-section voxel shadow, dynamic voxel shadow
    - Skip units' turret rotation and jumpjets' wobbling under EMP
    - Droppod properties dehardcode
+   - `Deployer = yes->no` infantry conversion sequence fix
    - Waypoint entering building together with engineer/agent bug fix
    - Skippable game save on scenario start
    - `InfDeath=9` versus jumpjet infantry 0 damage fix
@@ -387,15 +388,17 @@ This page lists all the individual contributions to the project by their author.
   - Fix for sidebar not updating queued unit numbers when on hold
   - New Parabola trajectory
   - Enhanced Bombard trajectory
+  - No turret unit turn to the target
+  - Damage multiplier for different houses
+  - Extended gattling rate down logic
   - New Engrave trajectory
 - **Ollerus**
   - Build limit group enhancement
   - Customizable rocker amplitude
   - Allowed `AuxBuilding` and Ares' `SW.Aux/NegBuildings` to count building upgrades
   - Type select for buildings (doc)
   - Enhanced Bombard trajectory
-- **NaotoYuuki**
-  - Vertical & meteor trajectory projectile prototypes
+- **NaotoYuuki** - Vertical & meteor trajectory projectile prototypes
 - **handama** - AI script action to jump back to previous script
 - **TaranDahl (航味麻酱)**
   - Skirmish AI "sell all buildings and set all technos to hunt" behavior dehardcode
@@ -408,8 +411,12 @@ This page lists all the individual contributions to the project by their author.
   - Parasite returning bug fix
   - Bunkerable checks dehardcode
   - Prevent the units with locomotors that cause problems from entering the tank bunker
-- **tyuah8** - Drive/Jumpjet/Ship/Teleport locomotor did not power on when it is un-piggybacked bugfix
+  - No turret unit turn to the target
+- **tyuah8**
+  - Drive/Jumpjet/Ship/Teleport locomotor did not power on when it is un-piggybacked bugfix
+  - Destroyed unit leaves sensors bugfix
 - **Aephiex** - initial fix for Ares academy not working on the initial payloads of vehicles built from a war factory
+- **Multfinite** - Allow to toggle main exception handler via command line argument `-ExceptionHandler=boolean`
 - **Ares developers**
   - YRpp and Syringe which are used, save/load, project foundation and generally useful code from Ares
   - unfinished RadTypes code
@@ -435,7 +442,8 @@ This page lists all the individual contributions to the project by their author.
 - **thomassneddon** - general assistance, knowledge about voxel lighting model
 - **Xkein** - general assistance, YRpp edits
 - **mevitar** - honorary shield tester *triple* award
-- **Phobos CN Tester Group (Reedom, Mantis, Swim Wing, Takitoru, Examon, AKB, Pusheen, ZQ, Claptrap, BunkerGeneral, Big J, Skywalker, ChickEmperor, Shifty, Mikain, Tobiichi Origami, Feiron, W_S502, Ailink, AbrahamMikhail, Tide, Fnfalsc, Yumeri_Rei, Nacho, Zhuzi, Ika_Aru)** - extensive and thorough testing
+- **Mentalmeisters Team (Speeder, Ollerus, mevitar, Reedom, Takitoru, Terumasa, Zhelin)** - extensive and thorough testing
+- **Phobos CN Tester Group (Mantis, Swim Wing, Examon, AKB, Pusheen, ZQ, Claptrap, BunkerGeneral, Big J, Skywalker, ChickEmperor, Shifty, Mikain, Tobiichi Origami, Feiron, W_S502, Ailink, AbrahamMikhail, Tide, Fnfalsc, Yumeri_Rei, Nacho, Zhuzi, Ika_Aru, EUSiegfried, HanpiBaozi, Nxusbot, TientsinWind)** - extensive and thorough testing
 - **Damfoos** - extensive and thorough testing
 - **Dmitry Volkov** - extensive and thorough testing
 - **Rise of the East community** - extensive playtesting of in-dev features

README.md

@@ -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
 ---------
 

docs/Contributing.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