If you're making a relatively small change - like fixing a typo or rewording
something - the easiest way to contribute is directly on GitHub! You can do this
while you're reading the Symfony documentation.

Step 1. Click on the edit this page button on the upper right corner
and you'll be redirected to GitHub:

Step 3. GitHub will now create a branch and a commit for your changes
(forking the repository first if this is your first contribution) and it will
also display a preview of your changes:

If everything is correct, click on the Create pull request button.

Step 4. GitHub will display a new page where you can do some last-minute
changes to your pull request before creating it. For simple contributions, you
can safely ignore these options and just click on the Create pull request
button again.

Congratulations! You just created a pull request to the official Symfony
documentation! The community will now review your pull request and (possibly)
suggest tweaks.

If your contribution is large or if you prefer to work on your own computer,
keep reading this guide to learn an alternative way to send pull requests to the
Symfony Documentation.

In this section, you'll learn how to contribute to the Symfony documentation for
the first time. The next section will explain the shorter process you'll follow
in the future for every contribution after your first one.

Let's imagine that you want to improve the Setup guide. In order to make your
changes, follow these steps:

Fetch all the commits of the upstream branches by executing this command:

1

$ git fetch upstream

The purpose of this step is to allow you work simultaneously on the official
Symfony repository and on your own fork. You'll see this in action in a moment.

Step 4. Create a dedicated new branch for your changes. Use a short and
memorable name for the new branch (if you are fixing a reported issue, use
fix_XXX as the branch name, where XXX is the number of the issue):

1

$ git checkout -b improve_install_article upstream/2.7

In this example, the name of the branch is improve_install_article and the
upstream/2.7 value tells Git to create this branch based on the 2.7
branch of the upstream remote, which is the original Symfony Docs repository.

Fixes should always be based on the oldest maintained branch which contains
the error. Nowadays this is the 2.7 branch. If you are instead documenting a
new feature, switch to the first Symfony version that included it, e.g.
upstream/3.1. Not sure? That's ok! Just use the upstream/master branch.

Step 5. Now make your changes in the documentation. Add, tweak, reword and
even remove any content and do your best to comply with the
Documentation Standards. Then commit your changes!

The origin value is the name of the Git remote that corresponds to your
forked repository and improve_install_article is the name of the branch you
created previously.

Step 7. Everything is now ready to initiate a pull request. Go to your
forked repository at https//github.com/YOUR-GITHUB-USERNAME/symfony-docs
and click on the Pull Requests link located in the sidebar.

Then, click on the big New pull request button. As GitHub cannot guess the
exact changes that you want to propose, select the appropriate branches where
changes should be applied:

In this example, the base fork should be symfony/symfony-docs and
the base branch should be the 2.7, which is the branch that you selected
to base your changes on. The head fork should be your forked copy
of symfony-docs and the compare branch should be improve_install_article,
which is the name of the branch you created and where you made your changes.

Step 8. The last step is to prepare the description of the pull request.
A short phrase or paragraph describing the proposed changes is enough to ensure
that your contribution can be reviewed.

Step 9. Now that you've successfully submitted your first contribution to
the Symfony documentation, go and celebrate! The documentation managers
will carefully review your work in short time and they will let you know about
any required change.

In case you are asked to add or modify something, don't create a new pull
request. Instead, make sure that you are on the correct branch, make your
changes and push the new changes:

Check you out! You've made your first contribution to the Symfony documentation!
Somebody throw a party! Your first contribution took a little extra time because
you needed to learn a few standards and setup your computer. But from now on,
your contributions will be much easier to complete.

Here is a checklist of steps that will guide you through your next
contribution to the Symfony docs:

Please be patient. It can take up to several days before your pull request can
be fully reviewed. After merging the changes, it could take again several hours
before your changes appear on the symfony.com website.

Why Should I Use the Oldest Maintained Branch Instead of the Master Branch?¶

Consistent with Symfony's source code, the documentation repository is split
into multiple branches, corresponding to the different versions of Symfony itself.
The master branch holds the documentation for the development branch of
the code.

Unless you're documenting a feature that was introduced after Symfony 2.7,
your changes should always be based on the 2.7 branch. Documentation managers
will use the necessary Git-magic to also apply your changes to all the active
branches of the documentation.

You can do it. But please use one of these two prefixes to let reviewers know
about the state of your work:

[WIP] (Work in Progress) is used when you are not yet finished with your
pull request, but you would like it to be reviewed. The pull request won't
be merged until you say it is ready.

[WCM] (Waiting Code Merge) is used when you're documenting a new feature
or change that hasn't been accepted yet into the core code. The pull request
will not be merged until it is merged in the core code (or closed if the
change is rejected).

First, make sure that the changes are somewhat related. Otherwise, please create
separate pull requests. Anyway, before submitting a huge change, it's probably a
good idea to open an issue in the Symfony Documentation repository to ask the
managers if they agree with your proposed changes. Otherwise, they could refuse
your proposal after you put all that hard work into making the changes. We
definitely don't want you to waste your time!