Англійська мова для управління відкритим кодом

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

Ключовий словник

BDFL - Добродійний Диктатор на все життя. Одна людина, яка має остаточну владу прийняття рішень щодо проекту. Термін був введений для Guido van Rossum в Python спільноти. Приклад: “BDFL зробив останнє виклик на новий синтаксис анотації типу.”

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

Contributor Covenant (CoC) — Договор співробітників є найбільш широко прийнятим Кодексом поведінки для спільнот з відкритим кодом. Він визначає прийнятну поведінку і процес повідомлення про порушення. Приклад: «Всі учасники повинні дотримуватися Угоди учасників»

** DCO проти CLA ** — ** DCO ** (Developer Certificate of Origin) — це легкий підпис, що підтверджує, що ви написали код і маєте право робити внесок у нього, доданий з git commit -s. CLA (Contributor Licence Agreement) — це більш формальна юридична угода, яка часто вимагає підтримки проектів корпорацією. Приклад: «Цей проект використовує DCO замість CLA, щоб зменшити тертя для нових співробітників»

** RFC (Request for Comments) ** — Формальний документ, у якому пропонується значна зміна або нова функціональність. Процес RFC запрошує відгуки спільноти перед тим, як приймається рішення. Приклад: «Ми відкрили RFC для нового API плагіна три тижні тому і збирали відгуки»

** Легкий консенсус ** — модель прийняття рішень, за якої пропозиція приймається, якщо ніхто не виступає проти неї протягом встановленого періоду часу. Молчание рассматривается как согласие. Приклад: «Зміна була схвалена лінивим консенсусом після 72-годинного вікна перегляду»

** Технічне управління ** — Правила і процеси, які визначають, як приймаються технічні рішення у проекті. Приклад: «Файл GOVERNANCE.md пояснює нашу модель технічного управління»

GOVERNANCE.md — Файл у кореневому каталозі сховища, який документує структуру управління проектом, процеси прийняття рішень і ролі. Приклад: «Перед тим, як подати свою пропозицію, прочитайте GOVERNANCE.md, щоб зрозуміти процес RFC»

** SIG (Special Interest Group) ** — зосереджена робоча група у межах більшого проекту, яка володіє певним доменом. Поширений у таких проектах, як Kubernetes. Приклад: «SIG для мереж має право приймати рішення щодо додатків CNI»

** Трианглування проблем ** — процес перегляду нових проблем для присвоєння їм міток, пріоритету, відтворення помилок і вирішення, чи є вони дійсними. Приклад: «Ми сортуємо вхідні проблеми кожного понеділка вранці, щоб зберегти відставання під контролем»

Як це використовувати на практиці

Коли ви приєднуєтесь до проекту з відкритим кодом, першим кроком є читання файлів GOVERNANCE.md і CONTRIBUTING.md. Ці параметри описують, як приймаються рішення і що очікується від співробітників.

Якщо ви бажаєте запропонувати значну зміну, перевірте, чи використовується у проекті процес ** RFC **. Такі проекти як Rust, Ember і React мають сховища RFC. Ви відкриваєте запит на збирання зі структурованим документом, спільнота коментує його, і зрештою керівний комітет або BDFL приймають рішення.

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

Якщо проект вимагає ** DCO **, ви можете підписати звіти за допомогою git commit -s -m "Your message". Це додасть рядок Signed-off-by: до перенесення. ** CLA ** — це окремий юридичний документ, який ви зазвичай підписуєте за допомогою веб- форми.

Приклад розмови

** Priya: ** « Я хочу запропонувати новий синтаксис запиту для проекту. Чи варто мені просто відкрити PR?»

** Супроводжувач: ** “Для чогось настільки значущого, ми б віддали перевагу RFC. Перевірте GOVERNANCE.md для шаблону. Після того, як ви його надіслали, він проходить через 30-денний період коментарів до голосування керівного комітету. ”

Прия: “Я понял. Чи має моя компанія підписати CLA?»

** Супроводжувач: ** “Ми використовуємо DCO замість цього — просто переконайтеся, що ви підписуєте ваші звіти з git commit -s.”

Практичні поради

1. Прочитати справжній GOVERNANCE.md: Подивіться на файли управління для Kubernetes ( kubernetes/community ) або проекту Rust ( rust-lang/rfcs ). Напишіть список з п’ яти термінів управління, які ви знайдете у цій статті, і дайте одне визначення кожного з них вашими словами.

2. ** Перегляньте обговорення RFC: ** Знайти відкритий RFC у проекті, яким ви користуєтесь (React, Vue, Rust або Python PEP є хорошими варіантами). Прочитайте коментарі і визначте мову, якою люди використовують для того, щоб погодитися (« це LGTM »), висловити заперечення (« я хвилююся за…»), або запитати про зміни (« чи можемо ми розглянути альтернативу, де…»).

3. ** Вправляйтеся у словниковому запасі для сортування: ** Коли ви наступного разу прочитаєте повідомлення щодо проблеми, спробуйте вказати на кожну проблему у голові: « Цю проблему слід сортувати », « Цей запис є дублікатом », « Цей запис не входить до обсягу », « Цей запис готовий для співробітника ». Активное використання словарного запасу — навіть без слів — сприяє вільному спілкуванню.

На практиці: Навігація Nuance — перспектива розробника

Основні концепції, описані в «Англійській мові для управління відкритим кодом»—BDFLs, CLAs, RFCs—це фантастичні будівельні блоки. Але перетворення цього розуміння у справжнє спілкування як розробника може бути складним, особливо коли ви все ще вдосконалюєте свою професійну англійську. Це не просто про те, щоб знати визначення; це про те, щоб передати свої ідеї чітко і з повагою в рамках спільного середовища проекту з відкритим кодом. Давайте розглянемо деякі сценарії, де ці словникові терміни справді оживляють, і як нерідний мовець може підійти до них з впевненістю.

Розглянемо наступний випадок: ви надіслали запит на звантаження (PR), який містить значний перероблений код модуля. Під час перегляду коду, інший розробник залишає коментар, що говорить: «Це хороший початок, але логіка тут відчувається… * лінивий *. Чи можете ви розкрити ваші аргументи, які стоять за обходом існуючих перевірок на підтвердження? Тепер, розуміння того, що « лінивий консенсус » стосується відсутності надійного обґрунтування для рішень, може бути корисним, але як ви можете ефективно відповісти? Прямий переклад може звучати незграбно. Замість цього спробуйте щось на зразок: «Я ціную ваші відгуки. Моєю метою було спростити цей процес з огляду на продуктивність, і я задокументував обґрунтування у повідомленні про перенесення, в якому описано зміни. Однак, я визнаю, що більш формальне RFC може бути корисним для детального обговорення потенційних наслідків обходу цих перевірок — можливо, ми могли б запланувати коротку дискусію на цю тему? ” Зауважте, як оформлення його як запрошення до подальшої розмови, а не оборонне твердження робить величезну різницю. Аналогічно, під час написання ваших власних описів PR, уникайте надто технічного жаргону, якщо це можливо, і зосередьтеся на * впливі * ваших змін. « Виправляє ваду » — це добре, але « Виправляє витік пам’ яті у конвеєрі обробки даних через неефективне з’ єднання рядків » може бути занадто складним для рецензентів, які не дуже добре знайомі з кодом.

Інша ситуація виникає під час розмов Slack про запропонування нових функцій. Можливо, виникає дискусія щодо того, чи прийняти певний підхід, чи ні - скажімо, щодо того, як обробляти автентифікацію користувача. Хтось пропонує: « Давайте просто використаємо OAuth2; це стандарт ». Ви можете інстинктивно відкинути таку пропозицію: « Але чи не викликає це значних проблем з безпекою, якщо ми не реалізуємо X і Y належним чином? » Зрозумівши, що підтримка RFC (запит на коментарі) є чинним процесом формального дослідження цих проблем — замість простого відкидання пропозиції — ви продемонструєте свою зацікавленість у управлінні проектом. Це показує, що ви критично мислите про потенційні ризики і конструктивно вносите свій внесок у процес прийняття рішень.

Нарешті, пам’ятайте, що навіть здавалося б невеликі фрази можуть мати значні наслідки. Використання активного голосу («Я вірю…») зазвичай краще, ніж пасивного голосу («Це слід розглядати…»). І послідовне посилання на встановлені процеси, такі як «ДКО (Додаток власника авторських прав) керівництва» або «CLA (Договору про ліцензію співробітника)» демонструє, що ви знайомі з правовою базою проекту і зобов’язані дотримуватися його правил.

# Example: Using git to check for a CLA file associated with a repository
git ls-tree -r --name-only HEAD | grep CLA

Ця команда, хоча і проста, ілюструє, як технічний словник безпосередньо пов’язаний з практичними потоками роботи в рамках проекту з відкритим кодом - перевірка відповідності і розуміння юридичних аспектів вкладу. Освоєння цього поєднання технічної термінології і чіткого спілкування є ключем до того, щоб стати цінним членом будь-якого співтовариства з відкритим кодом.