Add more information about core team processes

Author: wouterj

contributing/core_team.rst

@@ -27,10 +27,24 @@ Core Team Member Responsibilities
 
 Core Team members are unpaid volunteers and as such, they are not expected to
 dedicate any specific amount of time on Symfony. They are expected to help the
-project in any way they can, from reviewing pull requests, writing documentation
-to participating in discussions and helping the community in general, but their
-involvement is completely voluntary and can be as much or as little as they
-want.
+project in any way they can. From reviewing pull requests and writing documentation,
+to participating in discussions and helping the community in general. However,
+their involvement is completely voluntary and can be as much or as little as
+they want.
+
+Core Team Communication
+~~~~~~~~~~~~~~~~~~~~~~~
+
+As an open source project, public discussions and documentation is favored
+over private ones. All communication in the Symfony community conforms to
+the :doc:`/contributing/code_of_conduct/code_of_conduct`. Request
+assistance from other Core and CARE team members when getting in situations
+not following the Code of Conduct.
+
+Core Team members are invited in a private Slack channel, for quick
+interactions and private processes (e.g. security issues). Each member
+should feel free to ask for assistance for anything they may encounter.
+Expect no judgement from other team members.
 
 Core Organization
 -----------------
@@ -145,6 +159,14 @@ A Symfony Core membership can be revoked for any of the following reasons:
 * Willful negligence or intent to harm the Symfony project;
 * Upon decision of the **Project Leader**.
 
+Core Membership Compensation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Core Team members work on Symfony on a purely voluntary basis. In return
+for their work for the Symfony project, members can get free access to
+Symfony conference. Personal vouchers for Symfony conference are handed out
+on request by the **Project Leader**.
+
 Code Development Rules
 ----------------------
 
@@ -178,6 +200,13 @@ A pull request **can be merged** if:
   ``+1`` (if the submitter is part of the Mergers team, two *other* members)
   and no Core member voted ``-1`` (via GitHub reviews or as comments).
 
+.. _core-team_minor-changes:
+
+.. note::
+
+    Minor changes comprise typos, DocBlock fixes, code standards
+    violations, and minor CSS, JavaScript and HTML modifications.
+
 Pull Request Merging Process
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -205,6 +234,79 @@ following these rules:
 Getting the right category is important as it is used by automated tools to
 generate the CHANGELOG files when releasing new versions.
 
+.. tip::
+
+    Core team members are granted write-access to the main repository. To
+    avoid unintentional pushes to the main project (which in turn creates
+    new versions on Packagist), core team members are encouraged to have
+    two clones of the project locally:
+
+    #. A clone for your own contributions, which you use to push to your
+       fork on GitHub. Clear out the push URL for the main repository using
+       ``git remote set-url --push origin dev://null``;
+    #. A clone for merging, which you use in combination with ``gh`` and
+       allows you to push to the main repository.
+
+Upmerging Version Branches
+~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+To synchronise changes in all versions, version branches are regularly
+merged from oldest to latest, called 'upmerging'. This is a manual process.
+There is no strict policy on when this occurs, but usually not more than
+once a day and at least once before monthly releases.
+
+Before starting the upmerge, Git must be configured to provide a merge
+summary by running:
+
+.. code-block:: terminal
+
+    $ git config --global merge.summary true
+
+The upmerge should always be done on all maintained versions at the same
+time. Refer to `the releases page`_ to find all actively maintained
+versions (indicated by a green color).
+
+Start on the oldest version and make sure it's up to date with the upstream
+repository. Then, check-out the second oldest version, update from upstream
+and merge the previous version from the local branch:
+
+.. code-block:: terminal
+
+    # 'origin' is refered to as the main upstream project
+    $ git fetch origin
+
+    # update the local branches
+    $ git checkout 6.4
+    $ git reset --hard origin/6.4
+    $ git checkout 7.2
+    $ git reset --hard origin/7.2
+    $ git checkout 7.3
+    $ git reset --hard origin/7.3
+
+    # upmerge 6.4 into 7.2
+    $ git checkout 7.2
+    $ git merge --no-ff 6.4
+    # ... resolve conflicts
+    $ git commit
+
+    # upmerge 7.2 into 7.3
+    $ git checkout 7.3
+    $ git merge --no-ff 7.2
+    # ... resolve conflicts
+    $ git commit
+
+    $ git push origin 7.3 7.2 6.4
+
+.. warning::
+
+    Upmerges must be explicit, i.e. no fast-forward merges.
+
+.. tip::
+
+    Solving merge conflicts can be challenging. You can always ping other
+    core team members to help you in the process (e.g. members that merged
+    a specific conflicting change).
+
 Release Policy
 ~~~~~~~~~~~~~~
 
@@ -216,13 +318,6 @@ Symfony Core Rules and Protocol Amendments
 The rules described in this document may be amended at any time at the
 discretion of the **Project Leader**.
 
-.. _core-team_minor-changes:
-
-.. note::
-
-    Minor changes comprise typos, DocBlock fixes, code standards
-    violations, and minor CSS, JavaScript and HTML modifications.
-
 .. _`symfony-docs repository`: https://github.com/symfony/symfony-docs
 .. _`UX repositories`: https://github.com/symfony/ux
 .. _`fabpot`: https://github.com/fabpot/
@@ -263,3 +358,4 @@ discretion of the **Project Leader**.
 .. _`mtarld`: https://github.com/mtarld/
 .. _`spomky`: https://github.com/spomky/
 .. _`alexandre-daubois`: https://github.com/alexandre-daubois/
+.. _`the releases page`: https://symfony.com/releases