Яким чином внески у проект з відкритим кодом повинні управляти власниками (власниками)?

Керуючи проектом з відкритим кодом (використовуючи такий сервіс, як GitHub), як би відповісти на таке:

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

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

Q1. Чи прийнятно я змінювати подане джерело? (чи можливо це на GitHub?)

Q2. Чи слід відхиляти всі такі подання відповідно до вказівок щодо подання?

Q3. Якщо так, для Q2, а як насправді охайна ідея, яка погано реалізована? Чи прийнятно для мене просто йти вперед і створювати своє?

Я хочу заохочувати внесок, але в той же час важливо підтримувати певний стандарт.

open-source github

— Леа Хейс
джерело

Відповіді:

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

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

— Джеремі Хайлер
джерело

Я думаю, що ядро Linux має певні «зміни, які потребують вдосконалення» для цього сценарію.

— seppo0010

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

— Девід Шварц

Я бачив досить багато проектів, які автоматизують деякі з цих матеріалів, коли ви запитуєте про витяг.

— Ендрю Т Фіннелл

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

— Майкл Міор

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

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

Якщо ви робите щось таким чином, відповіді на Q1-Q3 будуть:

Q1: Так, відредагуйте подання, щоб подати наступний документ
Q2: Не застосовується (я припускаю, що ви ще не написали жодних вказівок)
Q3: Скажіть спасибі та перепишіть його :-) (Можливо, взагалі не застосовувати патч, якщо в наступному комітеті ви все-таки перепишете його повністю)

— KajMagnus
джерело