Як обговорювати відкриті джерела внесків англійською мовою

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

---

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

** Upstream ** — початковий проект, з якого було створено ваш розгалужений проект. Коли ви відгукуєтеся на цю пропозицію, ви робите свій внесок у « початковий код ». « Я надіслав виправлення вади початковому коду — супроводжувач об’ єднав його у той же тиждень. »

** Fork ** — особиста копія чиєїсь сховища, де ви можете вільно експериментувати без впливу на оригінал. « Я зробив розгалужування бібліотеки, щоб додати потрібну мені функціональність — якщо супроводжувач зацікавлений, я відкрию PR. »

** Супроводжувач ** — особа або група, відповідальна за керування проектом: перегляд внесків, сортування проблем і прийняття рішень щодо випуску. « Супроводжувач попросив про деякі зміни перед тим, як вони об’ єднають мою PR — я розглянув всі коментарі. »

** Внесок** — будь- хто, хто зробив прийнятий внесок у проект, чи це код, документація, переклади або звіти про вади. « Я став співробітником після того, як було об’ єднано мій третій PR. »

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

** Добрий перший випуск ** — це мітка, яку використовують супроводжувачі для позначення випусків, які підходять для нових співробітників. « Я почав з випусків, які мають мітку « хороший перший випуск » — це чудовий спосіб ознайомитися з кодовою базою. »

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

---

Фрази для відкриття запиту на завантаження

Важливо, як ви пишете і говорите про ваш запит на звантаження. Ясний опис PR збільшує шанси на те, що його буде переглянуто і об’ єднано:

• «Я відкрив PR, який розв’язує проблему #142 — вона додає підтримку для налаштування нетипового тайм-аута»
• Зміни мінімальні і зворотньо сумісні — не впроваджено ніяких змін
• «Я включив тести і оновив документацію, щоб відобразити нову поведінку»
• «Я відкритий для відгуків про реалізацію — може бути кращий підхід, який я не розглядав»
• Це проект PR для раннього відгуку — я не готовий до злиття, але хотів би знати деякі напрямки»

---

Фрази для взаємодії з супроводжувачами

Супроводжувачі часто є волонтерами з обмеженим часом. Бути уважним, коротким і самодостатнім - це дуже багато:

• «Я прочитав рекомендації щодо внесків і зробив усе можливе, щоб дотримуватися їх»
• «Я помітив, що ця проблема не мала активності впродовж деякого часу — чи вона все ще актуальна, чи вона була виправлена ​​деінде?»
• «Я був би радий взяти це на себе, якщо ніхто інший не працює над цим — просто дайте мені знати»
• «Я розумію, що це суперечлива зміна — щасливий обговорити компроміси, перш ніж я вкладу більше часу»
• «Не поспішай з рецензією — я розумію, що у тебе багато відкритих PR»

---

Фрази для обговорення відкритого коду в інтерв’ю на роботу

Інтерв’юери часто запитують про внесок у відкритий код. Ці фрази допоможуть вам впевнено говорити про вашу роботу:

• «Я активний учасник [проекту] — у мене було вісім PR, які об’єдналися за останній рік»
• «Я вносжу свій внесок в відкритий код, тому що це відкриває мені кодові бази і перегляд стандартів, з якими я не стикався б на моїй повсякденній роботі»
• «Мій найважливіший внесок був рефакторинг системи плагінів — це зменшило поверхню API і зробило бібліотеку легше розширити»
• «Я також підтримую невелику власну бібліотеку — вона має близько 400 зірок GitHub і активну спільноту»
• «Внесок у розробку означає, що я розумію проекти, від яких залежить моя команда, на набагато глибшому рівні»

---

Норми, які варто знати

Спільноти з відкритим кодом мають неписані правила, які досвідчені співробітники приймають як належне. Знаючи ці речі, ви станете більш ефективним співробітником:

• ** Пошук перед відкриттям проблеми. ** « Я пошукав існуючі проблеми і не зміг знайти дублікат — ось нова проблема. »
• ** Будь терплячим. ** “Я розумію, що перегляд може зажадати часу — будь ласка, дайте мені знати, якщо є щось, що я можу зробити, щоб допомогти.”
• ** Припустимо, що ваші наміри добрі. ** « Я, можливо, неправильно зрозумів намір оригінального коду — раді, що вас виправили. »
• Закрити петлю. “Проблема, яку я підняв у #320 була вирішена змінами в #345 — я закриваю це.”

---

Фрази, яких слід уникати

Avoid	Try instead
”Why haven’t you merged my PR yet?"	"I wanted to follow up on the PR — is there anything blocking the review?"
"This is a bug — fix it."	"I believe I’ve found a bug — here are the steps to reproduce it."
"My approach is better."	"I’ve taken a slightly different approach — happy to discuss the trade-offs."
"Nobody maintains this project."	"This project seems to have reduced activity — is it still actively maintained?”

---

Краткий справочник

Situation	Phrase
Opening a PR	”I’ve opened a PR that addresses issue #X.”
Starting with a new project	”I started with ‘good first issue’ labels.”
Asking about status	”I noticed this hasn’t had activity — is it still relevant?”
Showing interview value	”Contributing upstream gives me a deeper understanding of our dependencies.”
Closing the loop	”This was resolved by #345 — I’m closing this issue.”
Respecting maintainer time	”No rush on the review — I understand you have many open PRs.”

Внесок у відкритий код - це довга гра. Розробники, які будують репутацію в спільнотах з відкритим кодом, є тими, хто чітко спілкується, дотримується норм і проявляє терпіння. Словник, який міститься у цьому довіднику, є вашою початковою точкою.

Навигація потоками: практичні фрази для внесків з відкритим кодом

Будьмо чесними - обговорення внесків з відкритим кодом може здатися неймовірно технічним, навіть коли ви чудово розумієте код. Мова, яку використовують, часто передбачає рівень знайомості, який нові співробітники можуть не мати. Крім простого розуміння того, що таке «запит на витяг» *, мова йде про те, щоб сформулювати свої ідеї чітко і з повагою до встановлених норм спільноти. Це не тільки про синтаксис; це про демонстрацію професіоналізму і ефективний внесок у здоров’я проекту. Ключовою частиною цього є розуміння того, як супроводжувачі зазвичай спілкуються - вони часто використовують коротку, директивну мову, зосереджену на швидкому вирішенні проблем. І навпаки, учасники повинні прагнути до ясності і пояснити свої аргументи.

Однією з поширених перешкод є конструктивне оформлення зворотнього зв’язку. Замість того, щоб сказати « Цей код неоднозначний », краще сказати « Я помітив деякі невідповідності у форматуванні; можливо, вирівнювання з посібником зі стилів проекту покращить його читабельність ». Аналогічно, коли ви пропонуєте зміни, уникайте нечітких тверджень на зразок « це потребує виправлення ». Замість цього спробуйте сказати « Я вважаю, що зміна цього розділу для реалізації [особливої можливості] вирішить [визначену проблему] і відповідатиме цілям проекту, описаним у [відповідному документі/ обговоренні ] ». Пам’ ятайте, що супроводжувачі часто маніпулюють декількома пріоритетами — шануйте їх час, будучи точними. Також, розумійте різницю між « upstream » (оригінальним сховищем) і « forks » — fork представляє незалежну гілку розробки, тоді як upstream — це початковий код, з яким ви працюєте безпосередньо. Правильне використання цих термінів показує глибше розуміння потоку роботи.

Крім того, не бійтеся просити про пояснення. Краще визнати, що ви впали в хаос, ніж робити припущення. Фрази на кшталт «Чи можете ви розібратися, чому був обраний цей підхід?» або «Мені цікаво, чи є логіка за [конкретним рішенням]» показують залученість і бажання навчатися — якості, які високо цінуються в спільнотах з відкритим кодом. Нарешті, завжди пам’ятайте про тон; навіть здавалося б нейтральна мова може мати непередбачені наслідки. Сфокусування на тому, що потрібно зробити, а не на тому, як це слід зробити, часто призводить до гладшої співпраці.

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

# Assuming you've created a branch 'feature/new-functionality'
git checkout feature/new-functionality
git diff > changes.patch  # Creates a patch file containing the changes
git add . # Stages all changed files in your working copy
git commit -m "feat: Implement new functionality as requested"

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