Начало работы

Прочтите файл README проекта и следуйте процессам, указанным в руководстве CONTRIBUTIONS.

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

• Вклад в документацию — это очень эффективный способ познакомиться с проектом; обычно мы можем исправлять ошибки в орфографии, пунктуации, грамматике, неверные ссылки и т.д., прочитав документацию.
• good-first-issue — для проектов, желающих получить больше вкладов, часто используются эти метки на задачах, которые легко взяться за выполнение.

Issues

Частые ошибки:

• Только заголовок, но нет содержания.
• Только результаты/явление, без контекста.
  • Возможность возникновения проблемы может быть различной, никто не сможет угадать вашу среду или шаги.
• Только скриншоты, без ключевых слов, связанных с ошибками, аномалиями или контекстом.
  • Без текста будет сложно другим пользователям найти информацию.

Наилучшие практики:

• Подайте новый issue только тогда, когда он ещё не был упомянут в существующих issues.
• Придерживайтесь правил сообщества, соответствующего используемому языку.
• Заголовок должен быть кратким и чётким.
• Определите категорию, используя метки или префиксы заголовков.
  • Общие категории заголовков: Question: xxx, Proposal: xxx, Bug: xxx
• Для проблем, связанных с интерфейсом, предоставляйте скриншоты.## Pull Requests Частые ошибки:
• Отправка изменений в одной ветке (например, main).
• Отправка нескольких различных улучшений или исправлений ошибок одним pull request'ом.
• Отправка новых изменений одним pull request'ом.
• Самостоятельное слияние своего pull request'a.
• Использование мгновенного чата для того, чтобы спровоцировать конкретного человека проверить ваш pull request. Лучшие практики:
• Перед первым созданием запроса на вытягивание (PR), просмотрите список успешных комментариев к уже объединённым PR, а также форматирование и т. д.
• Если проблема, которую вы хотите исправить, уже имеет соответствующий issue, убедитесь, что никто ещё не создал соответствующий PR, затем оставьте комментарий с вашими планами по исправлению.
• Если вы ожидаете, что ваши изменения будут значительными, сначала создайте issue и подробно опишите свои мысли в зависимости от конкретной ситуации (сложность, спорность и т. д. ).
• Один PR может содержать только один тип правок.
• Для более сложных случаев добавления новых возможностей или исправления ошибок, учтите, как можно облегчить проверку для рецензентов.
  • В первую очередь, подумайте, можно ли разделить "большой" PR на несколько меньших. * Перед отправкой PR, убедитесь, что вы провели полное тестирование, и обязательно обратите внимание на свой журнал коммитов (как "внешний вид"), оставив только те записи, которые вы хотите объединить (остальные можно заранее свалить).
  • Лёгкий совет: вы можете создать PR в своей форке для повторной проверки, чтобы убедиться, что он достаточно "элегантен".
• Каждый раз при отправке PR используйте новую ветвь.
• Избегайте повторного закрытия и создания одного и того же PR.
  • Избегайте частых коммитов в одном PR, это будет серьёзным препятствием для рецензентов.
  • Если ваш PR ещё не готов к проверке, добавьте префикс WIP: в название до полного тестирования.
  • При выполнении рекомендаций рецензентов, избегайте использования принудительного обновления --force, это затрудняет понимание последних изменений рецензентами.
  • По возможности, сохраняйте элегантность вашего журнала коммитов; если после нескольких проверок записей много, владельцы проекта решат, стоит ли свалить ваши коммиты при слиянии.
• Предоставляйте максимально возможную информацию о текущем PR, включая связанные issues, проблемы, которые были решены, любую удобную контекстуальную информацию для проверки.
  • Для изменений UI предоставьте скриншоты до и после.
  • Предоставьте процесс вашего личного тестирования, когда это возможно.
  • Объясните потенциально спорные части.* Если ваш PR больше недели не получает проверку, попробуйте привлечь команду, ответственную за него.
  • Если нет доступной команды для привлечения, найдите человека, который недавно объединял аналогичный PR, и объясните, почему вы обращаетесь к нему, и извинитесь за беспокойство.```markdown Лучшие практики:

* Если проблема, которую вы хотите исправить, уже имеет соответствующий issue, убедитесь, что никто ещё не создал соответствующий PR, затем оставьте комментарий с вашими планами по исправлению.
* Если вы ожидаете, что ваши изменения будут значительными, сначала создайте issue и подробно опишите свои мысли в зависимости от конкретной ситуации (сложность, спорность и т. д. ).
* Один PR может содержать только один тип правок.
* Для более сложных случаев добавления новых возможностей или исправления ошибок, учтите, как можно облегчить проверку для рецензентов.
  * В первую очередь, подумайте, можно ли разделить "большой" PR на несколько меньших.
  * Перед отправкой PR, убедитесь, что вы провели полное тестирование, и обязательно обратите внимание на свой журнал коммитов (как "внешний вид"), оставив только те записи, которые вы хотите объединить (остальные можно заранее удалить).
  * Лёгкий совет: вы можете создать PR в своей форке для повторной проверки, чтобы убедиться, что он достаточно "элегантен".
* Каждый раз при отправке PR используйте новую ветвь.
* Избегайте повторного закрытия и создания одного и того же PR.
  * Избегайте частых коммитов в одном PR, это будет серьёзным препятствием для рецензентов.  * Если ваш PR ещё не готов к проверке, добавьте префикс `WIP:` в название до полного тестирования.
  * При выполнении рекомендаций рецензента, избегайте использования принудительного обновления `--force`, это затрудняет понимание последних изменений рецензентами.
  * По возможности, сохраняйте элегантность вашего журнала коммитов; если после нескольких проверок записей много, владельцы проекта решат, стоит ли свалить ваши коммиты при слиянии.
  
* Предоставляйте максимально возможную информацию о текущем PR, включая связанные issues, проблемы, которые были решены, любую удобную контекстуальную информацию для проверки.
  * Для изменений UI предоставьте скриншоты до и после.
  * Предоставьте процесс вашего личного тестирования, когда это возможно.
  * Объясните потенциально спорные части.
  
* Если ваш PR больше недели не получает проверку, попробуйте привлечь команду, ответственную за него.
  * Если нет доступной команды для привлечения, найдите человека, который недавно объединил аналогичный PR, и объясните, почему вы обращаетесь к нему и извинитесь за беспокойство.
```Следующие процессы являются распространенными:
![image](https://user-images.githubusercontent.com/1450685/206119968-07e3d729-70d5-4f0a-8e5e-8edf21d792e6.png)