Symfony Core Team

Edit this page

The Symfony Core team is the group of developers that determine the direction and evolution of the Symfony project. Their votes rule if the features and patches proposed by the community are approved or rejected.

All the Symfony Core members are long-time contributors with solid technical expertise and they have demonstrated a strong commitment to drive the project forward.

This document states the rules that govern the Symfony core team. These rules are effective upon publication of this document and all Symfony Core members must adhere to said rules and protocol.

Core Team Member Role

In addition to being a regular contributor, core team members are expected to:

  • Review, approve, and merge pull requests;
  • Help enforce, improve, and implement Symfony processes and policies;
  • Participate in the Symfony Core Team discussions (on Slack and GitHub).

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

Symfony Core members are divided into groups. Each member can only belong to one group at a time. The privileges granted to a group are automatically granted to all higher priority groups.

The Symfony Core groups, in descending order of priority, are as follows:

  1. Project Leader

    • Elects members in any other group;
    • Merges pull requests in all Symfony repositories.

  2. Mergers Team

    • Merge pull requests on the main Symfony repository.

In addition, there are other groups created to manage specific topics:

  • Security Team: manages the whole security process (triaging reported vulnerabilities, fixing the reported issues, coordinating the release of security fixes, etc.);
  • Symfony UX Team: manages the UX repositories;
  • Documentation Team: manages the whole symfony-docs repository.

Active Core Members

Former Core Members

They are no longer part of the core team, but we are very grateful for all their Symfony contributions:

Core Membership Application

About once a year, the core team discusses the opportunity to invite new members.

Core Membership Revocation

A Symfony Core membership can be revoked for any of the following reasons:

  • Refusal to follow the rules and policies stated in this document;
  • Lack of activity for the past six months;
  • 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 conferences. Personal vouchers for Symfony conferences are handed out on request by the Project Leader.

Code Development Rules

Symfony project development is based on pull requests proposed by any member of the Symfony community. Pull request acceptance or rejection is decided based on the votes cast by the Symfony Core members.

Pull Request Voting Policy

  • -1 votes must always be justified by technical and objective reasons;
  • +1 votes do not require justification, unless there is at least one -1 vote;
  • Core members can change their votes as many times as they desire during the course of a pull request discussion;
  • Core members are not allowed to vote on their own pull requests.

Pull Request Merging Policy

A pull request can be merged if:

  • It is a unsubstantial change;
  • Enough time was given for peer reviews;
  • It is a bug fix and at least two Mergers Team members voted +1 (only one if the submitter is part of the Mergers team) and no Core member voted -1 (via GitHub reviews or as comments).
  • It is a new feature and at least two Mergers Team members voted +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).

Note

Unsubstantial changes comprise typos, DocBlock fixes, code standards fixes, comment, exception message tweaks, and minor CSS, JavaScript and HTML modifications.

Pull Request Merging Process

All code must be committed to the repository through pull requests, except for unsubstantial change which can be committed directly to the repository.

Mergers must always use the command-line gh tool provided by the Project Leader to merge pull requests.

When merging a pull request, the tool asks for a category that should be chosen following these rules:

  • Feature: For new features and deprecations; Pull requests must be merged in the development branch.
  • Bug: Only for bug fixes; We are very conservative when it comes to merging older, but still maintained, branches. Read the Maintenance document for more information.
  • Minor: For everything that does not change the code or when they don't need to be listed in the CHANGELOG files: typos, Markdown files, test files, new or missing translations, etc.
  • Security: It's the category used for security fixes and should never be used except by the security team.

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 part of the mergers group on the symfony Github organization. This gives them write-access to many repositories, including the main symfony/symfony mono-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:

  1. A clone for their own contributions, which they use to push to their fork on GitHub. Clear out the push URL for the Symfony repository using git remote set-url --push origin dev://null (change origin to the Git remote poiting to the Symfony repository);
  2. A clone for merging, which they use in combination with gh and allows them to push to the main repository.

Upmerging Version Branches

To synchronize 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:

1
2
# Run command in the "symfony" repository
$ git config merge.stat 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).

The process follows these steps:

  1. Start on the oldest version and make sure it's up to date with the upstream repository;
  2. Check-out the second oldest version, update from upstream and merge the previous version from the local branch;
  3. Continue this process until you reached the latest version;
  4. Push the branches to the repository and monitor the test suite. Failure might indicate hidden/missed merge conflicts.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# '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

The Project Leader is also the release manager for every Symfony version.

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.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.
TOC
    Version