Як ви формулюєте слово "це відкритий код, надішліть виправлення", щоб воно було дружнім?

У відповідях Що таке канонічний реторат до "це відкрите джерело, надішліть виправлення"? , багато людей висловлювали думку про те, що просто просити людей надати патч - це зарозуміло та грубо.

Але мені здається, що як розробник будь-якого проекту з відкритим кодом, ви побачите в списку розсилки набагато більше запитів на функції, ніж ви могли б реалізувати. Тож, коли користувач каже: "Я хотів би побачити функцію X", правда полягає в тому, що шанси на її реалізацію досить малі, якщо вони самі не подадуть патч. Крім того, іноді може знадобитися трохи заохочення, щоб перетворити користувача на дописувача.

З іншого боку, ви не хочете відлякувати (потенційних) учасників, відриваючись, як грубі.

То як би ви сказали "будь ласка, надсилайте виправлення замість того, щоб просити функції" дружньо?

Оновлення: Дякую за всі пропозиції! Я бачу, що більшість із них потребують досить тривалих пояснень. Але оскільки я вважаю за краще уникати (а) пояснювати те ж саме через день (це забирає занадто багато часу), або (b) використовувати фрагменти, які я вставляю в електронну пошту (це стає безособовим реально швидко), мені цікаво: хтось написав це в документі, до якого я можу покластись?

(Особливості проекту, такі як написання тестів, компіляція коду та подача виправлення, все ж повинні бути задокументовані, але я думаю, що ці технічні проблеми все одно повинні входити в CONTRIBUTING.txt.)

Ви цього не робите.

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

• Чи не було б солодко, якби [...]? Можливо, це робити A, B і C. (Це приманка для: Я не маю часу, але ось конкретна ідея, якщо ви це зробите.)
• Ось патч, який потрібно зробити / ось виправлення для [...].
• Я думаю про те, щоб написати патч, щоб зробити [...] і можу використовувати зворотній зв'язок / хто хоче зацікавити.
• І т.д.

Кодери, які подають запит на функцію прямо, зазвичай роблять це з причини. Деякі з них включають (і я знаю за фактом, що останні два трапляються, наприклад, у WordPress):

• Вони заглиблюються в інші проекти з відкритим кодом, тобто не мають часу.
• Вони вільно їздять і мають намір так тримати речі.
• Це значно вищий рівень їхньої майстерності / написаний мовою, про яку вони нічого не знають.
• Вони використовують програмне забезпечення через відсутність кращого варіанту, і не хочуть мати справу з смердючою купою batsh * t ^ \ b коду.
• Їх більше не можна турбувати, оскільки їх попередні патчі були проігноровані / відхилені, тобто думають, що вони витрачають час.

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

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

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

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

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

Будьте ввічливі і чітко поясніть ситуацію. А як щодо чогось такого:

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

Розумієте, ви не можете просто сказати "Чому ви турбуєте мене зі своїми проханнями? Я не тут, щоб безкоштовно працювати над вами; якщо ви хочете цю функцію, перейдіть і реалізуйте її самостійно". Людина може бути не розробником, може не знати мови, яка використовується для розробки продукту тощо.

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

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

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

Дякуємо за запит Ми додали його до нашого відсталого проекту та незабаром будемо його переглядати.

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

Дійсно, це було так важко?

Ну а не просто сказати "надіслати патч", вам слід детальніше розробити.

• Зробіть зрозуміти, що у вас немає часу на це прямо зараз або в осяжному майбутньому, тому, якщо інші хочуть, щоб це було реалізовано незабаром, немає іншого способу, як забезпечити виправлення.
• Знайдіть час для оцінки функції. Якщо вам це щиро подобається, нічого поганого в цьому не говорите. Заохочуйте людей. Або якщо ви вважаєте, що ця функція насправді погана, то знайдіть час для пояснення цього.
• Надайте початкову допомогу. Ніхто не знає бази коду, як ви. У вас немає часу на це, але ви, мабуть, точно знаєте, як би ви це зробили і з чого б почати. Протягом 5-10 хвилин ви можете поділитися знаннями про те, що іншим потрібні години, щоб розібратися. Також це допомагає вашій великій картині переважати. Замість того, щоб пришвидшити функції чужорідних функцій до вашого проекту, ви можете направити учасників на добру інтеграцію.

Ось що я зазвичай кажу ...

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

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

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

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

Тому моя відповідь часто, просто роздрібніть.