mirror of
https://github.com/symfony/symfony-docs.git
synced 2026-03-24 00:32:14 +01:00
Correct spelling & grammar in 4.4. contributing/
This commit is contained in:
committed by
Javier Eguiluz
parent
62c0653fe3
commit
7019711029
@@ -10,7 +10,7 @@ may introduce new features, but must do so without breaking the existing API of
|
||||
that release branch (5.x in the previous example).
|
||||
|
||||
We also provide deprecation message triggered in the code base to help you with
|
||||
the migration process across major release.
|
||||
the migration process across major releases.
|
||||
|
||||
.. caution::
|
||||
|
||||
|
||||
@@ -109,7 +109,7 @@ Symfony contributions:
|
||||
Core Membership Application
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
About once a year, the core team discuss the opportunity to invite new members.
|
||||
About once a year, the core team discusses the opportunity to invite new members.
|
||||
|
||||
Core Membership Revocation
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
@@ -171,7 +171,7 @@ 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 anytime at the
|
||||
The rules described in this document may be amended at any time at the
|
||||
discretion of the **Project Leader**.
|
||||
|
||||
.. [1] Minor changes comprise typos, DocBlock fixes, code standards
|
||||
|
||||
@@ -74,7 +74,7 @@ are never accepted in a patch version:
|
||||
.. note::
|
||||
|
||||
This policy is designed to enable a continuous upgrade path that allows one
|
||||
to move forward with newest Symfony versions in the safest way. One should
|
||||
to move forward with the newest Symfony versions in the safest way. One should
|
||||
be able to move PHP versions, OS or Symfony versions almost independently.
|
||||
That's the reason why supporting the latest PHP versions or OS features is
|
||||
considered as bug fixes.
|
||||
|
||||
@@ -56,7 +56,7 @@ things for you beforehand, like routing or access control.
|
||||
Symfony being both a framework and library of components, it calls your
|
||||
code and then your code might call it. This means you will always have
|
||||
at least 2 parts, very often 3 in your stack traces when using Symfony:
|
||||
a part that starts in one of the entrypoints of the framework
|
||||
a part that starts in one of the entry points of the framework
|
||||
(``bin/console`` or ``public/index.php`` in most cases), and ends when
|
||||
reaching your code, most times in a command or in a controller found under
|
||||
``src``. Then, either the exception is thrown in your code or in
|
||||
@@ -75,7 +75,7 @@ Next, you can have a look at what packages are involved. Files under
|
||||
library and ``acme/router`` the Composer package. If you plan on
|
||||
reporting the bug, make sure to report it to the library throwing the
|
||||
exception. ``composer home acme/router`` should lead you to the right
|
||||
place for that. As Symfony is a monorepository, use ``composer home
|
||||
place for that. As Symfony is a mono-repository, use ``composer home
|
||||
symfony/symfony`` when reporting a bug for any component.
|
||||
|
||||
Getting Stack Traces with Symfony
|
||||
@@ -92,7 +92,7 @@ from your development environment through a web browser:
|
||||
|
||||
1. Are there several exceptions? If yes, the most interesting one is
|
||||
often exception 1/n which, is shown *last* in the example below (it
|
||||
is the one marked as exception [1/2]).
|
||||
is the one marked as an exception [1/2]).
|
||||
2. Under the "Stack Traces" tab, you will find exceptions in plain
|
||||
text, so that you can easily share them in e.g. bug reports. Make
|
||||
sure to **remove any sensitive information** before doing so.
|
||||
@@ -109,7 +109,7 @@ Since stack traces may contain sensitive data, they should not be
|
||||
exposed in production. Getting a stack trace from your production
|
||||
environment, although more involving, is still possible with solutions
|
||||
that include but are not limited to sending them to an email address
|
||||
with monolog.
|
||||
with Monolog.
|
||||
|
||||
Stack Traces in the CLI
|
||||
~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
@@ -78,7 +78,7 @@ short example containing most features described below::
|
||||
}
|
||||
|
||||
/**
|
||||
* Transforms the input given as first argument.
|
||||
* Transforms the input given as the first argument.
|
||||
*
|
||||
* @param bool|string $dummy Some argument description
|
||||
* @param array $options An options collection to be used within the transformation
|
||||
|
||||
@@ -53,7 +53,7 @@ Scope
|
||||
|
||||
This Code of Conduct applies both within project spaces and in public spaces
|
||||
when an individual is representing the project or its community. Examples of
|
||||
representing a project or community include using an official project e-mail
|
||||
representing a project or community include using an official project email
|
||||
address, posting via an official social media account, or acting as an appointed
|
||||
representative at an online or offline event. Representation of a project may be
|
||||
further defined and clarified by CARE team members.
|
||||
|
||||
@@ -76,7 +76,7 @@ members will not be included in any communication on the incidents as well as re
|
||||
created related to the incidents.
|
||||
|
||||
CARE team members are expected to inform the CARE team and the reporters
|
||||
in case of conflicts on interest and recuse themselves if this is deemed a problem.
|
||||
in case of a conflict of interest, and recuse themselves if this is deemed to be a problem.
|
||||
|
||||
Appealing the response
|
||||
----------------------
|
||||
|
||||
@@ -7,7 +7,7 @@ it might still seem overwhelming - contributing can be complex! For this
|
||||
purpose we created a dedicated `Symfony Slack`_ channel called `#mentoring`_
|
||||
to connect new contributors to long-time contributors. This is a great way
|
||||
to get one-on-one advice on the entire process. These long-time contributors
|
||||
do really want to help new contributors - so feel free to ask anything!
|
||||
truly want to help new contributors - so feel free to ask anything!
|
||||
|
||||
.. _`Symfony Slack`: https://symfony.com/slack-invite
|
||||
.. _`#mentoring`: https://symfony-devs.slack.com/messages/mentoring
|
||||
|
||||
@@ -80,7 +80,7 @@ of Symfony to the next one.
|
||||
|
||||
When a feature implementation cannot be replaced with a better one without
|
||||
breaking backward compatibility, Symfony deprecates the old implementation and
|
||||
adds a new preferred one along side. Read the
|
||||
adds a new preferred one alongside. Read the
|
||||
:ref:`conventions <contributing-code-conventions-deprecations>` document to
|
||||
learn more about how deprecations are handled in Symfony.
|
||||
|
||||
|
||||
@@ -28,8 +28,8 @@ constructive, respectful and helpful reviews and replies.
|
||||
welcoming place for everyone. **You are free to disagree with
|
||||
someone's opinions, but don't be disrespectful.**
|
||||
|
||||
First of, accept that many programming decisions are opinions.
|
||||
Discuss trade offs, which you prefer, and reach a resolution quickly.
|
||||
It’s important to accept that many programming decisions are opinions.
|
||||
Discuss trade-offs, which you prefer, and reach a resolution quickly.
|
||||
It's not about being right or wrong, but using what works.
|
||||
|
||||
Tone of Voice
|
||||
@@ -118,13 +118,13 @@ If a piece of code is in fact wrong, explain why:
|
||||
* "We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework)"
|
||||
|
||||
* "This would require adding lots of code and making lots of changes for a feature that doesn't look so important.
|
||||
That could hurt maintaining in the future."
|
||||
That could hurt maintenance in the future."
|
||||
|
||||
Asking for Changes
|
||||
------------------
|
||||
|
||||
Rarely something is perfect from the start, while the code itself is good.
|
||||
It may not be optimal or conform the Symfony coding style.
|
||||
It may not be optimal or conform to the Symfony coding style.
|
||||
|
||||
Again, understand the author already spent time on the issue and asking
|
||||
for (small) changes may be misinterpreted or seen as a personal attack.
|
||||
@@ -143,7 +143,7 @@ Use words like "Please", "Thank you" and "Could you" instead of making demands;
|
||||
|
||||
* "Please use 4 spaces instead of tabs", "This needs be on the previous line";
|
||||
|
||||
During a pull request review you can usually leave more then one comment,
|
||||
During a pull request review you can usually leave more than one comment,
|
||||
you don't have to use "Please" all the time. But it wouldn't hurt.
|
||||
|
||||
It may not seem like much, but saying "Thank you" does make others feel
|
||||
@@ -158,7 +158,7 @@ In that case, it is better to try to approach the discussion in
|
||||
a different way, to not escalate further.
|
||||
|
||||
If you want someone to mediate, please join the ``#contribs`` channel on `Symfony Slack`_,
|
||||
to have a safe environment and keep working together on the common goals.
|
||||
to have a safe environment and keep working together on common goals.
|
||||
|
||||
Using Humor
|
||||
-----------
|
||||
@@ -172,8 +172,8 @@ to the Symfony community.** And don't marginalize someone's problems;
|
||||
|
||||
Even if someone's explanation is "inviting to joke about it", it's a real
|
||||
problem to them. Making jokes about this doesn't help with solving their
|
||||
problem and only makes them *feel stupid*. Instead try to discover what
|
||||
the problem is really about.
|
||||
problem and only makes them *feel stupid*. Instead, try to discover the
|
||||
actual problem.
|
||||
|
||||
Final Words
|
||||
-----------
|
||||
|
||||
@@ -109,7 +109,7 @@ to understand the functionality that has been fixed or added and find out
|
||||
whether the implementation is complete.
|
||||
|
||||
It is okay to do partial reviews! If you do a partial review, comment how far
|
||||
you got and leave the PR in "Needs Review" state.
|
||||
you got and leave the PR in the "Needs Review" state.
|
||||
|
||||
Pick a pull request from the `PRs in need of review`_ and follow these steps:
|
||||
|
||||
|
||||
@@ -23,7 +23,7 @@ speakers with people who are just taking their first steps in this area:
|
||||
|
||||
A good first step might be to give a talk at a local user group to a
|
||||
smaller crowd that one knows more intimately. A next step could be to
|
||||
give a talk at conference in your first language.
|
||||
give a talk at a conference in your first language.
|
||||
|
||||
The best way to find people that can review your talk idea or slides is
|
||||
the `#speaker-mentoring`_ channel on `Symfony Slack`_. There are many
|
||||
|
||||
@@ -64,11 +64,11 @@ knowing that the responsibility they accept for said vote is justified.
|
||||
Voting
|
||||
~~~~~~
|
||||
|
||||
The guidance team have the right to vote on proposals for actionable items.
|
||||
The guidance team has the right to vote on proposals for actionable items.
|
||||
The quorum of "yes" or "no" votes required for a decision to be considered valid
|
||||
is at least 75% of active, appointed members of the guidance team - to abstain
|
||||
from voting means that vote will not be counted towards the quorum.
|
||||
For an actionable item to pass, approval from greater than 50% of the voting
|
||||
For an actionable item to pass, approval from more than 50% of the voting
|
||||
guidance team members is required. Use or management of finances/donations
|
||||
require at least a two-thirds majority to pass.
|
||||
|
||||
|
||||
@@ -194,7 +194,7 @@ Your Next Documentation Contributions
|
||||
|
||||
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,
|
||||
you had to learn a few standards and set up 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
|
||||
@@ -288,7 +288,7 @@ The generated documentation is available in the ``_build/html`` directory.
|
||||
Frequently Asked Questions
|
||||
--------------------------
|
||||
|
||||
Why Do my Changes Take so Long to Be Reviewed and/or Merged?
|
||||
Why Do My Changes Take So Long to Be Reviewed and/or Merged?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Please be patient. It can take up to several days before your pull request can
|
||||
|
||||
@@ -8,7 +8,7 @@ following error message by default: "This value is not a valid timezone."
|
||||
|
||||
These messages are translated into tens of languages thanks to the Symfony
|
||||
community. Symfony adds new messages on a regular basis, so this is an ongoing
|
||||
translation process and you can help us providing the missing translations.
|
||||
translation process and you can help us by providing the missing translations.
|
||||
|
||||
How to Contribute a Translation
|
||||
-------------------------------
|
||||
|
||||
Reference in New Issue
Block a user