Перевірка запиту на злиття

Ми завжди раді отримувати відгуки від авторів, незалежно від їхнього рівня досвіду.

Навіщо перевіряти матеріали?

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

Мета процесу рецензування — забезпечити, щоб весь контент, включаючи код і документацію, був максимально вільним від помилок і простим в обслуговуванні. Будь-який ваш внесок у досягнення цієї мети буде вітатися. Це може бути як щось просте, наприклад виправлення друкарської помилки, так і виявлення крайніх випадків використання API, які не виявляються автоматично. Ви можете запропонувати способи підвищення надійності процедури тестування або надати рекомендації щодо структуризації загальної архітектури змін, щоб їх було простіше підтримувати чи розширювати.

Чи можу я залишити відгук?

Так! Ви можете залишити відгук щодо будь-якого відкритого запиту на злиття, який бачите на BeeWare.

Як новачок-учасник, ви можете сміливо перевіряти будь-який pull-запит, який знайдете, навіть якщо його надіслав член основної команди. Якщо ви новачок, вам, можливо, бракує розуміння загального контексту проєкту; але ми прагнемо зробити кодову базу доступною незалежно від вашого рівня досвіду. Якщо у коді є щось, що вам не зрозуміло, це може свідчити про необхідність додаткової документації (або безпосередньо в коді, або у вигляді окремої документації щодо архітектури).

Участь у рецензуванні pull-запиту

Перевірка запиту на злиття

Перевірка запиту на злиття

Кожен бажаючий може перевірити будь-який внесок у проєкт BeeWare. Однак перед тим, як приступити до роботи, слід врахувати кілька важливих моментів.

ПОДУМАЙТЕ, перш ніж залишати відгук

Перш ніж приступити до написання відгуку, ПОДУМАЙТЕ. Як автори відгуків, ми повинні зважити, чи є відповідь, яку ми збираємося надіслати:

• Правильно. Завжди намагайтеся надавати точні рекомендації та інформацію.
• Корисно. Ми надаємо рекомендації щодо вдосконалення поданої пропозиції; ці рекомендації повинні чітко вказувати на джерело проблеми або неврахований варіант використання, а в ідеалі — пропонувати шляхи вирішення або усунення зауважень.
• Надихає. Саме від нас залежить, чи зможемо ми надихнути автора на те, щоб він захотів внести запропоновані нами зміни.
• Необхідно. Очікується, що автор прочитає все, що ми публікуємо; ми повинні поважати його час і зусилля, публікуючи матеріали лише за необхідності.
• Ввічливість. Існує безліч способів висловити один і той самий відгук; нам слід подбати про те, щоб наші слова були ввічливими, підтримуюючими та конструктивними.

Цілком можливо ДУМАТИ, одночасно надаючи ефективний відгук. Розглянуті вище принципи не заважають вказувати на будь-які проблеми, які ви виявили в PR. Учасники не матимуть можливості вдосконалити свій внесок, якщо не знатимуть, які саме аспекти потребують поліпшення. Головне — пам’ятати про те, як ви подаєте цей відгук. Намагайтеся не робити рецензію особистою. Замість «Ви припустилися помилки» можна сказати: «Цей код можна вдосконалити». Рецензуйте код, а не автора.

Важливо пам’ятати, що крім вказівки на аспекти, які потребують вдосконалення, слід також надавати позитивні відгуки. Якщо, наприклад, внесені зміни виявилися особливо корисними, хтось зробив щось особливо кмітливе або ви дізналися про API, про який раніше не знали, обов’язково повідомте про це автору! Ніколи не недооцінюйте ефект від того, що ви відзначаєте те, що хтось зробив правильно або добре, навіть у ситуації, коли все інше, на що ви вказали, — це проблеми, які потрібно вирішити.

Пропозиції щодо рецензування на GitHub

Інтерфейс рецензування на GitHub має механізм пропозицій змін, за допомогою якого ви можете вказати точне змінення, яке пропонуєте замість існуючого вмісту. Майте на увазі, що доки ці запропоновані зміни не будуть прийняті та зафіксовані, вони не проходитимуть перевірку перед фіксацією та лінтування. Тому цю функцію слід використовувати для невеликих змін, оскільки чим масштабніша запропонована зміна, тим більша ймовірність виникнення проблем.