@@ -12,7 +12,7 @@ is world-wide and is composed of a wide variety of people with differing
12
12
ideas and opinions.
13
13
14
14
Not everyone speaks English or is able to use a keyboard. Some might
15
- have Dyslexia or similar conditions that affect their writing.
15
+ have dyslexia or similar conditions that affect their writing.
16
16
17
17
Not to mention that some might have a bad experience from previous
18
18
contributions (to other projects).
@@ -32,39 +32,39 @@ First of, accept that many programming decisions are opinions.
32
32
Discuss trade offs, which you prefer, and reach a resolution quickly.
33
33
It's not about being right or wrong, but using what works.
34
34
35
- Tone of voice
35
+ Tone of Voice
36
36
-------------
37
37
38
38
We don't expect you to be completely formal, or to even write error-free
39
- English. Just remember one thing: Don 't swear, and be respectful to others.
39
+ English. Just remember this: don 't swear, and be respectful to others.
40
40
41
41
Don't reply in anger or with an aggressive tone. You're angry, we understand
42
42
that, but swearing/cursing and name calling doesn't really encourage anyone to
43
43
help you. Take a deep breath, count to 10 and try to *clearly * explain what problems
44
44
you encounter.
45
45
46
- Gender pronouns
47
- ---------------
46
+ Gender-neutral Pronouns
47
+ -----------------------
48
48
49
- While not "formally" required it's better to use gender-neutral pronouns.
49
+ While not "formally" required, it's better to use gender-neutral pronouns.
50
50
Unless someone "indicated" their pronouns, use "they", "them" instead of
51
51
"he", "she", "his", "hers", "his/hers", "he/she", etc.
52
52
53
53
Try to avoid using wording that may be considered excluding and needlessly gendered,
54
54
like for example words that have a male base. For example we recommend to use other
55
- words like “ folks”, “ team”, “ everyone” in place of “ guys” .
55
+ words like " folks", " team", " everyone" in place of " guys" .
56
56
57
- Giving positive feedback
57
+ Giving Positive Feedback
58
58
------------------------
59
59
60
60
While reviewing issues and pull requests you may run into some suggestions
61
61
(including patches) that don't reflect your ideas, are not good, or downright wrong.
62
62
63
63
Now, when you prepare your comment, consider the amount of work and time the author
64
- has spent on their idea and how your response would make them feel;
64
+ has spent on their idea and how your response would make them feel.
65
65
66
66
Did you correctly understand their intention? Or are you making assumptions?
67
- Which ever you respond , be explicit. Remember people don't always understand your
67
+ Whatever your response , be explicit. Remember people don't always understand your
68
68
intentions online.
69
69
70
70
Avoid using terms that could be seen as referring to personal traits ("dumb", "stupid").
@@ -86,21 +86,21 @@ don't get into endless you-are-wrong discussions or "flame wars".
86
86
87
87
Don't use hyperbole ("always", "never", "endlessly", "nothing", "worst", "horrible", "terrible").
88
88
89
- **Don't: ** `` I don't like how you wrote this code `` - there is no clear explanation why you
90
- don't like how it's written.
89
+ **Don't: ** * " I don't like how you wrote this code" * - there is no clear explanation why you
90
+ don't like how it's written.
91
91
92
- **Better: ** `` I find it hard to read this code as there many nested if statements, can you make it more
93
- readable? by encapsulating some of it's details or maybe adding some comments to explain the overall logic.`` -
94
- You explain why you find the code hard to read *and * give some suggestions for improvement.
92
+ **Better: ** * " I find it hard to read this code as there many nested if statements, can you make it more
93
+ readable? By encapsulating some of it's details or maybe adding some comments to explain the overall logic." * -
94
+ You explain why you find the code hard to read *and * give some suggestions for improvement.
95
95
96
96
If a piece of code is in fact wrong, explain why:
97
97
98
- * ``This code doesn't comply with Symfony's CS rules. Please see [...] for details ``.
98
+ * ``This code doesn't comply with Symfony's CS rules. Please see [...] for details ``.
99
99
100
- * ``Symfony 3 still uses PHP 5 and doesn't allow the usage scalar type-hints. ``.
100
+ * ``Symfony 3 still uses PHP 5 and doesn't allow the usage scalar type-hints. ``.
101
101
102
- * ``I think the code is less readable now `` - careful here, be sure explain why you think
103
- the code is less readable, and maybe give some suggestions?
102
+ * ``I think the code is less readable now `` - careful here, be sure explain why you think
103
+ the code is less readable, and maybe give some suggestions?
104
104
105
105
**Examples of valid reasons to reject: **
106
106
@@ -113,12 +113,12 @@ If a piece of code is in fact wrong, explain why:
113
113
114
114
* Code doesn't match Symfony's CS rules (e.g. ``use array() `` instead of ``[] ``)
115
115
116
- * We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework
116
+ * We only provide integration with very popular projects (e.g. we integrate Bootstrap but not your own CSS framework)
117
117
118
118
* This would require adding lots of code and making lots of changes for a feature that doesn't look so important.
119
119
That could hurt maintaining in the future.
120
120
121
- Asking for changes
121
+ Asking for Changes
122
122
------------------
123
123
124
124
Rarely something is perfect from the start, while the code itself is good.
@@ -141,17 +141,17 @@ Use words like "Please", "Thank you" and "Could you" instead of making demands;
141
141
142
142
* "Please use 4 spaces instead of tabs", "This needs be on the previous line";
143
143
144
- During a pull request review you can usually leave more then one comment,
145
- you don't have to use "Please" all the time. But it wouldn't hurt.
144
+ During a pull request review you can usually leave more then one comment,
145
+ you don't have to use "Please" all the time. But it wouldn't hurt.
146
146
147
147
It may not seem like much, but saying "Thank you" does make others feel
148
148
more welcome.
149
149
150
- Using humor
150
+ Using Humor
151
151
-----------
152
152
153
- In short: Don't be a troll; This violates the Code of Conduct and may
154
- even get you banned! Keep it real and friendly.
153
+ In short: Extreme misbehavior will not be tolerated and may even get you banned;
154
+ Keep it real and friendly.
155
155
156
156
**Don't use sarcasm for a serious topic, that's not something that belongs
157
157
to the Symfony community. ** And don't marginalize someone's problems;
@@ -162,7 +162,7 @@ problem to them. Making jokes about this doesn't help with solving their
162
162
problem and only makes them *feel stupid *. Instead try to discover what
163
163
the problem is really about.
164
164
165
- Final words
165
+ Final Words
166
166
-----------
167
167
168
168
Don't feel bad if you "failed" to follow these tips. As long as your
0 commit comments