English for Open Source Maintainers: Community Management Vocabulary (англійською)
Вивчайте англійську лексику для управління спільнотою з відкритим кодом: LGTM, сортування, застарілий випуск, CODEOWNERS, модель управління, частота випуску і драбина співробітників.
Мова відкритого коду
Підтримка проекту з відкритим кодом означає спілкування з учасниками з усього світу — у коментарях запитів на збирання, гілках проблем, повідомленнях про випуск і форумах спільноти. Тон, словниковий запас і конвенції відкритого коду мають свій власний характер: більш формальний, ніж повідомлення команди Slack, але більш розмовний, ніж внутрішня технічна документація.
Для людей, для яких англійська мова не є рідною, але які підтримують або хочуть робити внесок у проекти з відкритим кодом, знати цей словник так само важливо, як знати код. Ця стаття містить основні терміни і фрази, що використовуються у керуванні спільнотою з відкритим кодом.
Ключовий словник
LGTM Абревіатура від « Looks Good To Me ». Поширена абревіатура, яку використовують переглядачі для повідомлення про схвалення запиту на звантаження. Хоча це неформально, це розуміється універсально в контекстах відкритого коду.
“Супроводжувач залишив коментар, в якому сказав: ‘LGTM — гарна чиста реалізація. Об’єднання після того, як CI пройде.’ Це сигнал, що PR схвалено. ”
- Триаже Процес перегляду нових проблем і запитів на звантаження для їх категорізації, призначення пріоритетів і призначення. Триажування зазвичай є регулярною діяльністю для супроводжувачів, особливо в більших проектах.
«Ми проводимо сеанс сортування кожного понеділка — ми проходимо через нові проблеми, позначаємо їх і закриваємо дублікати або запити поза сферою застосування»
Зависший вопрос Випуск або запит на звантаження, що не було ініційовано нещодавно і вважається неактивним. Багато проектів використовують ботів, які автоматично позначають і закривають застарілі проблеми після встановленого періоду часу.
“Старий бот відзначив цю проблему після 60 днів бездіяльності. Якщо ви хочете продовжити працювати над ним, будь ласка, залиште коментар і ми відкриємо його знову»
СОВЛАДЦІ Файл у сховищі, який визначає, які особи або команди відповідальні за перегляд змін у певних файлах або каталогах. Запити на витягування, які стосуються цих файлів, автоматично вимагають перегляду власником коду.
«Ми оновили файл CODEOWNERS, щоб відобразити нову структуру команди — тепер команда безпеки автоматично запитується для перегляду на все під /auth.»
** Модель управління ** Набір правил і процесів, які визначають, як приймаються рішення у проекті з відкритим кодом — включаючи те, хто може об’ єднувати код, як розв’ язуються суперечки і як додаються нові супровідники.
«Перед тим, як запрошувати нових супроводжувачів, нам потрібно завершити нашу модель управління. Зараз рішення приймаються неформально, що не має масштабу»
Спущено на ходу Звичайний розклад або ритм, за яким випускаються нові версії проекту. Деякі проекти використовують часові ритм (наприклад, кожні шість тижнів); інші випускають, коли достатньо функцій готові.
«Ми перейшли на щомісячну частоту випуску минулого року — це дає співробітникам передбачувану ціль і допомагає нам ефективніше виправляти помилки»
Ступінь співробітника Структурований механізм, який визначає різні рівні участі і відповідальності у рамках проекту, наприклад, співробітник, виконавець, супроводжувач і основний член команди.
«Ми опублікували драбину співробітників в нашому CONTRIBUTING.md, щоб зрозуміти, як люди можуть зростати від випадкового співробітника до повного супроводжувача»
Ключові слова
Ці колокації є необхідними для написання коментарів щодо виникнення проблем, оглядів PR і документації спільноти:
- ** тріа нових проблем ** — « Чи може хтось допомогти з тріюванням нових проблем цього тижня? » У нас більше 30 неперевірених»
- ** позначити як застарілу ** — « Бот буде позначати як застарілу будь- яку проблему, що не мала жодної активності протягом 90 днів. »
- ** оновити файл CODEOWNERS ** — « Після реструктуризації команди нам слід оновити файл CODEOWNERS. »
- define the governance model — « Перед тим, як проект зростатиме далі, ми повинні визначити модель управління »
- follow the release cadence — « Ми намагаємося строго дотримуватися ритм випуску, щоб співробітники знали, коли слід використовувати їх PRs. »
- ** climb the contributor ladder ** — « Декілька членів спільноти готові піднятися по драбині співробітників — обговоримо підвищення їх до статусу комітерів »
Видання охоплює тематику ділової та громадської журналістики
Однією з найважливіших навичок для супроводжувачів відкритого коду є написання відповідей, які є чесними, ясними і доброзичливими — особливо при відмові від внесків або закритті проблем. Ось деякі приклади:
Закриття проблеми, що виходить за межі обсягу:
- “Дякую, що знайшли час, щоб відкрити це! На жаль, це виходить за рамки поточного обсягу проекту. Наразі ми зосереджуємось на стабільності, а не на нових функціях. Не соромтеся підтримувати розгалужений проект, якщо це важливо для вас».*
** Запит на зміни в PR: **
“Відмінна робота над цим — підхід є твердим. Перед тим, як ми зможемо об’ єднати, чи можете ви додати тести для кращих випадків у рядках 45- 60? Також, цю функцію можна було б трохи спростити — дивіться мій вбудований коментар.”
** Запрошення когось на ступінь співробітника: **
“Ми дуже вдячні за ваш внесок за останні шість місяців. Ми хотіли б запропонувати вам стати учасником проекту. Це дасть вам права на об’ єднання ваших власних PR. Чи зацікавлені ви?»
Зауважте, що ці повідомлення підтверджують зусилля співробітника, пояснюють причину будь- якого рішення і пропонують наступний крок. Цей шаблон — підтвердити, пояснити, запропонувати — є надійною структурою для спілкування супроводжувача.
Practice
Відвідайте сторінку проблем будь- якого популярного проекту з відкритим кодом на GitHub (наприклад, VS Code, React або FastAPI). Знайдіть три нещодавно закриті проблеми і прочитайте закінчення коментаря супроводжувача. Вказує, чи використовується у коментарі шаблон підтвердження- пояснення- пропозиція. Потім напишіть свою власну відповідь на вигадану проблему, у якій хтось запитує можливість, яка не входить до сфери дії проекту. Використовуйте принаймні три слова з цього повідомлення.
Наприклад, навігаційна система: навігаційна система з навігаційною системою
Для не-англомовних носіїв англійської мови, розуміння тонких нюансів професійного зворотнього зв’язку може бути значною перешкодою в спільнотах з відкритим кодом. Це не просто про отримавши критику; це про інтерпретацію її намірів і конструктивної відповіді. Часто те, що виглядає як тупий негатив, насправді є бажання поліпшити код або проект. Ключова фраза, з якою ви часто стикаєтеся, це «LGTM», що означає «Виглядає добре для мене». Однак, просто сказати «LGTM» без подальшого пояснення може бути сприйнято як відкидання, особливо якщо рецензент має певні проблеми, які вони не висловили явно.
Розглянемо такий сценарій: Alice надсилає запит на збирання, який містить декілька змін до компонента бібліотеки ядра. Боб, старший супроводжувач, залишає коментар на PR, в якому говорить: « LGTM ». Хоча це технічно правильно, але не вирішує потенційних проблем з продуктивністю або майбутньою масштабованістю, які розглядав Боб. Ефективнішою відповіддю було б щось на зразок: «LGTM – дякую за роботу! Просто хотів зафіксувати, що ця зміна вводить нову залежність; ми повинні обговорити її вплив на загальний розмір нашого проекту і, можливо, дослідити альтернативні підходи, коли ми масштабуємо. “Це демонструє залучення, визнає занепокоєння Боба і відкриває двері для подальшого обговорення. Аналогічно, якщо хтось залишає коментар на кшталт «Потрібен більше тестів», не приймайте це відразу як критику вашого коду. Замість цього, відповісти на щось на зразок «Зрозуміло - я ціную відгук на тестове покриття. Я зараз працюю над додаванням деяких тестів блоків, щоб покрити цю функціональність і інтегрувати їх незабаром. ”
Іншою областю, де нюанс є критичним, є Slack комунікація. Отримавши повідомлення на кшталт «Це потребує роботи» може відчувати себе досить неопределенным і залякуванням. Замість того, щоб реагувати оборонно, спробуйте розпакувати його. Ти можеш відповісти: “Дякую, що на це звернув увагу! Можеш роз’яснити, що саме потребує уваги? Чи є якісь конкретні області, на яких ви б порадили мені зосередитися?» Цей активний підхід переносить розмову з потенційно негативного твердження на спільну сесію вирішення проблем. Пам’ятайте, що більшість членів спільноти справді вкладають гроші в успіх проекту і цінують розробників, які активно шукають роз’ яснення. Сфокусування на * розумінні * основної потреби часто є більш цінним, ніж просто негайне захист вашої роботи.