Add contribution process description

docs/Contributing.md

@@ -34,7 +34,7 @@ To distribute the workload and make the project more manageable, we have establi
   - 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.
+- 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)
@@ -53,6 +53,17 @@ What can make any PR more controversial and requiring a higher level maintainer'
 - Mixing contribution types
 - Current level of maintainers not being sure about whether they can judge this PR
 
+### Contribution process
+
+To ensure your contribution goes smoothly, please stick to the following process when contributing to the project:
+1. **Check whether there is already an open Pull Request** for whatever you want to contribute. If there is - comment on it and see if you can help with it instead of starting your own first. We hate to discard otherwise valid work just because it's a duplicate.
+2. If all is clear - you should **get in touch with maintainers** of level respective to the complexity of your PR (see [Types of contributions](Contributing.md#types-of-contributions)) to review/merge your upcoming PR and **talk with them about key design aspects before you even submit a contribution**.
+   - This is *especially* important for bigger and more fundamental improvements, when you're learning and when you're exploring "uncharted territories". Staying engaged in communication with the maintainers will help you to avoid unnecessary wasted effort and reworks later on and make sure that your contribution is aligned with how we do things. Not only that, but it also allows you to essentially get early reviews on important things and faster merges (which is especially important in light of our large amount of PRs) with higher level of confidence.
+   - Currently the Phobos channel on Discord is the best place to brainstorm things like that, as it's the most accessible place to reach out to maintainers and discuss your ideas (or if there's nobody around - try messaging experienced maintainers privately).
+     - GitHub issues, discussions and draft PRs (with not a lot of work done yet) are also OK to discuss things, but they are not as fast as Discord and are better used for persistent storage of info, and usually it's easier to grab someone's attention if you approach them personally in chat.
+   - It's also a good thing to get opinions of multiple maintainers and not always consult specific one or a separate part of them. We should try to stay interconnected with each other, even if initially divided by language or habitually.
+3. When we all have a clear idea of the plan you have in mind - all that is left to do is to finalize the design and implementation in the PR, and we'll review the minor things left and merge it.
+
 ### Project structure
 
 Assuming you've successfully cloned and built the project before getting here, you should end up with the following project structure: