Огляди спільноти

Дата оновлення перекладу 2024-05-13

Огляди спільноти

Symfony - це проект з відкритим вихідним кодом, яким керує велика спільнота. Якщо ви не відчуваєте себе готовими внести свій код або патчі, то перегляд проблем і запитів на додавання (PR) може стати чудовим початком для залучення та віддачі. Насправді, люди, які "сортують" проблеми - це основа успіху Symfony!

Note

Спілкуватися так, щоб ваші слова сприймалися так, як ви їх задумували, може бути важко. Будь ласка, ознайомтеся зі статтею правил Поважних коментарів до оглядів.

Чому огляди важливі

Огляди спільноти є важливими для розвитку фреймворку Symfony, оскільки існує набагато більше запитів на додавання та звітів про помилки, ніж є учасників в основній команді Symfony, щоб розглянути, виправити і об'єднати їх.

У трекері проблем Symfony ви можете знайти багато пунктів зі статусом Потребує огляду:

  • Звіти про помилки: Звіти про помилки потрібно перевіряти на повноту. Чи відсутня якась важлива інформація? Чи можна відтворити помилку?
  • Запити на додавання: Запити на додавання містять код, який виправляє помилку або реалізує нову функціональність. Перевірка запитів на додавання гарантує, що вони реалізовані належним чином, покриті тестовими кейсами, не створюють нових помилок і підтримують зворотну сумісність.

Зауважте, що будь-хто, хто має базові знання з Symfony та PHP, може переглядати звіти про помилки та запити на додавання. Вам не потрібно бути експертом, щоб допомогти.

Будьте конструктивними

Перш ніж почати, пам'ятайте, що ви дивитеся на результат чужої важкої праці. Хороший коментар завдячить автору за його роботу, вкаже на те, що було зроблено добре, визначить, що слід покращити, і запропонує наступний крок.

Створіть акаунт на GitHub

Symfony використовує GitHub для управління повідомленнями про проблеми та запитами на додавання. Якщо ви хочете робити огляди, вам потрібно створити обліковий запис GitHub і увійти в систему.

Процесс огляду звітів про проблеми

Хороший спосіб розпочати розгляд - це вибрати звіт про проблему зі списку звітів про проблеми, що потребують перевірки.

Кроки для перевірки такі:

  1. Чи є звіт повним?

    Хороші звіти про проблеми містять посилання на проект ("проект відтворення") створений за допомогою Symfony skeleton, який відтворює проблему. Якщо він її не відтворює, звіт повинен принаймні містити достатню кількість інформації та зразків коду для відтворення проблеми.

  2. Відтворіть проблему

    Завантажте проект відтворення і перевірте, чи можна відтворити проблему у вашій системі.Якщо автор повідомлення не надав проект відтворення, створіть його на основі одного Symfony skeleton.

  3. Оновіть статус проблеми

    Нарешті, додайте коментар до повідомлення про проблему. Дякуємо автору за повідомлення про проблему. Додайте рядок Status: <status> у вашому коментарі, щоб запустити нашого Carson Bot, який оновить мітку статусу проблеми. Ви можете встановити статус в одне з наступних значень:

    Потребує доопрацювання Якщо проблема не містить достатньо інформації для відтворення для відтворення, поясніть, якої інформації не вистачає, і перемістіть звіт у цей статус.

    Працює у мене Якщо проблема містить достатньо інформації для її відтворення, але вона працює у вашій системі, або якщо повідомлена помилка є особливістю, а не проблемою, надайте коротке пояснення і перемістіть звіт до цього статусу.

    Розглянуто Якщо ви можете відтворити проблему, перемістіть звіт до цього статусу. Якщо ви створили проект відтворення, додайте посилання на нього до вашого коментаря.

Example

Ось приклад коментаря до звіту про проблему, яку можна відтворити:

1
2
3
4
5
Дякую, @weaverryan, за створення цього звіту про проблему! Це дійсно
виглядає як помилка. Я відтворив проблему в гілці "kernel-bug"
https://github.com/webmozart/some-project.

Status: Розглянуто

Процесс огляду запитів на додавання

Процес розгляду запитів на додавання (PR) схожий на процес розгляду повідомлень про помилки. Огляд запитів на додавання зазвичай займає трохи більше часу, оскільки вам потрібно зрозуміти функціональність, яка була виправлена або додана, і з'ясувати чи є реалізація повною.

Це нормально - робити часткові огляди! Якщо ви робите частковий огляд, прокоментуйте, як далеко ви просунулися і залиште PR у стані "Потребує огляду".

Виберіть запит на додавання зі списку PR, що потребують огляду і виконайте наступні кроки:

  1. Чи є PR повним?

    Кожен запит на додавання повинен містити заголовок, який містить деяку основну інформацію
    про PR. Ви можете знайти шаблон для цього заголовка у розділі Правила внесення коду.

  2. Чи є базова гілка правильною?

    GitHub відображає гілку, на якій базується PR, під заголовком запиту на додавання. Чи правильна ця гілка?

    • Помилки слід виправляти в найстарішій версії, що підтримується, в якій міститься помилка. Перевірте Розклад релізів Symfony, щоб знайти найстарішу версію, що підтримується в даний час.
    • Нові функції завжди слід додавати до поточної версії розробки. Перевірте Symfony Roadmap, щоб знайти поточну версію розробки.
  3. Відтворіть проблему

    Прочитайте проблему, яку повинен виправити запит на додавання. Відтворіть проблему проблему у новому проекті, створеному за допомогою Symfony skeleton, і спробуйте зрозуміти, чому вона існує. Якщо пов'язана проблема вже містить такий проект, встановіть його і запустіть у вашій системі.

  4. Зробіть огляд на код

    Прочитайте код запиту на додавання та перевірте його на відповідність деяким загальним критеріям:

    • Чи стосується код проблеми, яку PR має на меті виправити/впровадити?
    • Чи не виходить PR за рамки, щоб вирішити лише цю проблему?
    • Чи містить PR автоматизовані тести? Чи охоплюють ці тести всі відповідні межеві випадки?
    • Чи містить PR достатню кількість коментарів для розуміння коду?
    • Чи порушує код зворотну сумісність? Якщо так, то чи зазначено про це в заголовку PR?
    • Чи містить PR застарівання? Якщо так, то чи вказано це у заголовку PR? Чи містить код оператори trigger_deprecation() для всіх застарілих функцій?
    • Чи всі застарівання та порушення зворотної сумісності задокументовано в останньому файлі UPGRADE-X.X.md? Чи містять ці пояснення приклади "До"/"Після" з чіткими інструкціями щодо оновлення?

    Note

    Зрештою, деякі з цих аспектів будуть перевірятися автоматично.

  5. Протестуйте код

    Візьміть ваш проект з кроку 3 і протестуйте, чи працює PR належним чином. Замініть проект Symfony в каталозі vendor на код в PR, виконавши наступні команди Git. Вставте ідентифікатор PR (це число після # у назві PR) для заповнювачів <ID>:

    1
    2
    3
    $ cd vendor/symfony/symfony
    $ git fetch origin pull/<ID>/head:pr<ID>
    $ git checkout pr<ID>

    Наприклад:

    1
    2
    $ git fetch origin pull/15723/head:pr15723
    $ git checkout pr15723

    Тепер ви можете тестувати проект у порівнянні з кодом в PR.

  6. Оновіть статус PR

    Наостанок, додайте коментар до PR. Дякуємо автору за роботу над PR. Включіть рядок Status: <status> у вашому коментарі, щоб запустити нашого Carson Bot, який оновить мітку статусу проблеми. Ви можете встановити значення статусу в одне з наступних значень:

    Потребує доопрацювання Якщо PR ще не готовий до об'єднання, поясніть проблеми які ви знайшли, і перемістіть його в цей статус.

    Розглянуто Якщо PR задовольняє всім перевіркам вище, перемістіть його в цей статус. Основний учасник незабаром перегляне PR і вирішить, чи можна його об'єднати, чи він потребує подальшої роботи.

Example

Ось приклад коментаря для PR, який ще не готовий до обʼєднання:

1
2
3
4
5
Дякуємо @weaverryan за роботу над цим! Здається, що ваші тести
не охоплюють випадки, коли лічильник дорівнює нулю або менше.
Чи не могли б ви додати кілька тестів для цього?

Status: Потребує доопрацювання