Стиль речи

Мы не ждем от вас абсолютной формальности или даже грамматически правильного использования английского языка. Просто помните: не используйте бранную речь и относитесь к другим с уважением.

Не отвечайте со злостью или агрессией. Если вас что-то злит, мы это понимаем, но ругательства/мат или обзывания никого не побуждает помочь вам. Глубоко вдохните, досчитайте до 10, и попробуйте четко объяснить, с какими проблемами вы столкнулись.

Инклюзивный язык

В попытках быть инклюзивным по отношению к большой группе людей, рекомендовано использовать личные местоимения, не предполагающие конкретный гендер. Если человек не указал используемые местоимения, используйте "они" и "им" вместо "он", "она", "его", "ее", "его/ее", "он/она" и т.д.

Постарайтсь избегать слов, которые могут считаться исключающими, безосновательно относящимися к гендеру (например, слова, имеющие женское или мужское основание), радикально мотивирующими или выделяющими конкретную группу в обществе. Например, рекомендует использовать слова вроде "ребята", "команда", "все" вместо "пацаны", "девушки", "янки" и т.д.

Предоставление позитивного фидбека

При рецензировании проблем и запросов на включения, вы можете столкнуться с некоторыми предложениями (включая патчи), которые не отображают ваши идеи, не являются хорошими или просто откровенно неправильные.

Теперь, когда вы готовите свой комментарий, подумайте о количестве работы и времени, которые автор потратил на свою идею, и на то, какое влияние на него будет иметь ваш ответ.

Правильно ли вы поняли их намерение? Или вы делаете собственные предположения? Каким бы ни был ваш ответ, будьте ясными. Помните, что онлайн люди не всегда могут понять ваши намерения.

Избегайте использования терминов, которые могут быть рассмотрены, как относящиеся к личностным характеристикам ("тупой", "глупый"). Предположите, что все умны и имеют наилучшие намерения.

Даже если что-то действительно является неправильным или "плохой идеей", оставайтесь уважительны и не начинайте бесконечные дискуссии на тему "ты-не-прав" или горячие перепалки.

Не используйте гиперболы ("всегда", "никогда", "бесконечно", "ничего", "наихудший", "ужасный").

Так не надо: "Мне не нравится, как вы написали этот код" - нет четкого объяснения, почему вам не нравится то, как он написан.

Вариант получше: "Мне сложно прочитать этот код, так как в нем много встроенных утверждений, вы не могли бы сделать его более читаемым? Путем инкапсуляции некоторых деталей или добавления некоторых комментариев, чтобы разъяснить общую логику." - Вы объясняете, почему вам сложно прочесть код и предоставляете варианты для улучшения.

Если часть кода фактически неправильная, объясните почему:

• "Этот код не соответствует правилам Symfony CS. Пожалуйста, прочтите [...], чтобы узнать больше."
• "Symfony 3 все еще использует PHP 5 и не позволяет использование скалярных подсказок."
• "По моему мнению код теперь менее читаемый." - здесь будьте осторожнее, и не забудьте объяснить, почему вы думаете, что код менее читаемый, и, может, дайте рекоммендации?

Пример валидных причин отклонения:

• "Мы пробовали это раньше (ссылка на релевантный PR) но вынуждены были перестать по причине XXX."
• "Это изменение приведет к большому количеству конфликтов слияния при объединении с ветками Symfony. В прошлом, мы всегда отклоняли такие изменения."
• "Я профилировал(а) это изменение и оно значительно ухудшает производительность" - если вы не профилируете, это необязательно, мы можем это игнорировать
• "Код не соответствует правилам Symfony CS (например, использует [] вместо array())"
• "Мы предоставляем интеграцию только с очень популярными проектами (например, мы интегрируем Bootstrap, но не ваш собственный CSS-фреймворк)"
• "Это потребует добавления большого количества кода внесения множества изменений ради функции, которая выглядит не очень важной. Это может навредить управлению приложением в будущем."

Просьба об изменениях

Редко что-то бывает идеальным с самого начала, хотя сам по себе код хороший. Он может быть не оптимальным или не соответствовать стилю написания кода Symfony.

Опять же, понимайте, что автор уже потратил время на проблему, и что просьба о (маленьких) изменениях может быть воспринята неправильно или рассмотрена, как нападение.

Поблагодарите за работу (уже проделанную), оставайтесь дружелюбным, и действительно старайтесь помочь сделать их вклад отличным. Особенно если этот вклад они делают впервые.

Используйте слова вроде "пожалуйста", "спасибо" и "не могли бы вы", вместо требований;

• "Спасибо вам за проделанную работу. Я оставляю несколько предложений по улучшению читаемости кода."
• "Ваш код содержит некоторые проблемы стиля написания кода, не могли бы вы их исправить до слияния? Спасибо"
• "Пожалуйста, используйте 4 пробела вместо табулятора","Это должно быть на предыдущей строке";

Во время рецензирования запроса на включения вы обычно можете оставлять более одного комментария, вам не нужно использовать слово "пожалуйста" каждый раз. Но это не навредит.

И хотя это выглядит мелочью, но "спасибо" заставляет других чувствовать себя более принятыми.

Предотвращение конфликтов

Иногда при получении фидбека люди могут начать обороняться. В таком случае, лучше попробовать подойти к дискуссии другим образом, чтобы не накалять обстановку.

Если вы хотите, чтобы кто-то выступил медиатором, пожалуйста, присоединитесь к каналу #contribs на Symfony Slack, чтобы поддерживать безопасную среду и продолжать работать над общими целями вместе.

Использование юмора

Кратко: Экстремальное поведение не будет принято и может даже привести к бану; Будьте реальны и дружелюбны.

Не используйте сарказм в серьезной теме, это не то, что принято в сообществе Symfony. И не высмеивайте чужие проблемы; Ха, похоже, так не было задумано? 😆.

Даже если чье-то объяснение просто "приглашает" вас пошутить об этом, для автора это реальная проблема. И шутки о ней не помогают с решением, а только заставляет его чувствовать себя глупым. Вместо этого попробуйте понять, в чем действительно заключается проблема.

Заключение

Не расстраивайтесь, если вам не удастся следовать этим советам. В случае, если ваши намерения были хорошими и вы никого не обидели и не оскорбили; вы можете объяснить, что вы не так поняли, не хотели ни над кем смеяться, или просто допустили ошибку.

Но не говорите это просто, чтобы сказать, если ваше извинение ничего не значит, вы потеряете доверие и уважение других разработчиков.

Поступай с другим так, как хочешь, чтобы поступили с тобой.