Как вы формулируете «это открытый исходный код, отправьте патч», чтобы он был дружелюбным?

В ответах « Что такое каноническая реплика:« Это открытый исходный код, отправьте патч »? Многие люди высказывали мнение, что просто просить людей представить патч высокомерно и грубо.

Но мне кажется, что как разработчик любого проекта с открытым исходным кодом, вы увидите намного больше запросов функций в списке рассылки, чем могли бы реализовать. Поэтому, когда пользователь говорит: «Я хотел бы увидеть функцию X», правда в том, что шансы на его реализацию довольно малы, если он сам не отправит патч. Кроме того, иногда все, что нужно для того, чтобы превратить пользователя в участника, может быть немного поощрения.

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

Итак, как бы вы сказали «пожалуйста, отправляйте патчи вместо того, чтобы запрашивать функции» по-дружески?

Обновление: спасибо за все предложения! Я вижу, что большинство из них требуют довольно длинных объяснений. Но так как я предпочел бы избегать (а) объяснения одного и того же через день (это занимает слишком много времени) или (б) использования фрагментов, которые я вставляю в электронную почту (это очень быстро становится безличным), мне интересно: кто-нибудь написал это в документе, на который я могу сослаться?

(Специфичные для проекта вещи, такие как, как писать тесты, компилировать код и отправлять патч, все же, конечно, должны быть задокументированы, но я думаю, что эти технические проблемы должны все равно войти в CONTRIBUTING.txt.)

Вы не

Насколько я знаю, кандидаты в соучастники являются тинкерами, и не будут отправлять запрос на добавление функции, просто запросив его. Обычно они запрашивают это с некоторым уровнем участия:

• Не было бы сладко, если бы [...]? Может быть возможно сделать A, B и C. (Это приманка для: у меня нет времени, но вот специальная идея на случай, если вы это сделаете.)
• Вот исправление, которое нужно сделать / вот исправление для [...].
• Я подумываю написать патч, чтобы сделать [...] и мог бы использовать обратную связь / кто-нибудь заинтересован в помощи.
• И т.п.

Программисты, которые отправляют запрос на функцию, обычно делают это по какой-то причине. Некоторые из них включают (и я точно знаю, что последние два происходят в WordPress, например):

• Они глубоко вовлечены в другие проекты с открытым исходным кодом, то есть не имеют времени.
• Они фрирайдеры и намерены так держать.
• Это намного выше уровня их навыков / написано на языке, о котором они ничего не знают.
• Они используют программное обеспечение из-за отсутствия лучшего варианта и не хотят иметь дело с вонючей кучей кода batsh * t ^ \ b.
• Они больше не могут быть обеспокоены, потому что их предыдущие исправления были проигнорированы / отклонены, то есть думают, что они будут тратить свое время впустую.

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

Я думаю, что ваш самый важный приоритет должен состоять в том, чтобы не откладывать потенциальных / существующих участников, а не пытаться активно привлекать новых. Это очень важно, и я говорю это по опыту. У меня есть странный способ подобрать новую базу кода, которая включает в себя беглое чтение кода, чтобы получить некоторый уровень его понимания, переход в систему создания билетов и исправление легко выглядящих ошибок, чтобы глубоко изучить внутреннее устройство (и заполнить новые, как я тестирую). За эти годы я затопил несколько проектов с десятками билетов и патчей. Много раз этим билетам будет уделено мало или вообще никакого своевременного внимания (даже не подтверждение, например, продолжайте в том же духе!), В том числе когда они сопровождаются документированными этапами диагностики и приложенными модульными тестами.

Короче говоря, вы объясняете, что у вас нет неограниченного времени, чтобы делать свою работу бесплатно. (Вы можете пропустить часть «бесплатно»), и они могут внести свой вклад в любое время, когда они захотят, это не «ваш» проект, а проект каждого.

так что вы говорите: «Мы очень сожалеем, это отличная идея, но мы слишком заняты всей другой работой, мы добавим ее в список, но если вы действительно хотите это включить, и вы хотели бы помочь нам, внеся свой вклад в проект, тогда это было бы замечательно. У нас есть некоторая документация, чтобы помочь ребятам внести изменения в проект, они здесь, так что если у вас есть навыки и время и хотите помочь нам, тогда, пожалуйста, отправьте нам патч с вашими изменениями. Возможно, нам придётся внести в него некоторые модификации, чтобы он соответствовал стандартам проекта, но вы будете делать нам большое спасибо, по крайней мере, предоставив нам поддержку для этой работы, и мы будем любить вас за помощь ».

Конечно, как только вы начнете просить патчи, вы никогда не сможете оставлять их в своей системе тикетов слишком долго, если вы получаете много, вы будете интегрировать их больше, чем выполняете работу, к которой вы привыкли. Возможно, вам это не понравится, но это необходимо, если вы хотите, чтобы патчи продолжали появляться.

Будьте вежливы и объясните ситуацию ясно. Как насчет чего-то вроде:

Спасибо за ваш отзыв. Мы находим вашу функцию очень интересной, но, несмотря на наши усилия по внедрению наиболее востребованных функций в нашем продукте, у нас недостаточно времени для их реализации. Если вы разработчик, вы можете присоединиться к нам, внеся свой вклад в проект, поскольку он с открытым исходным кодом.

Видите, вы не можете просто сказать: «Почему вы мешаете мне с вашими запросами? Я здесь не для того, чтобы работать на вас бесплатно; если вы хотите эту функцию, иди и реализуй ее самостоятельно». Человек может быть не разработчиком, может не знать язык, используемый для разработки продукта и т. Д.

Поэтому вместо того, чтобы быть грубым, вы можете предложить принять участие в проекте, а также объяснить, почему вы не можете реализовать эту функцию самостоятельно.

Еще один способ не быть грубым - не говорить ничего. Если у вас есть веб-сайт, на котором пользователи вашего приложения могут предлагать новые функции и сообщать об ошибках, вы можете отсортировать элементы по их приоритету: например, если функция запрашивается 10 000 пользователей, а другая - только 10 Есть вероятность, что первый будет реализован первым.

На таком веб-сайте вы всегда можете разместить предложение «реализовать сами» для функций, которые через несколько дней или недель не получили достаточного количества голосов других пользователей.

Спасибо за ваш запрос. Мы добавили его в наш портфель проектов и вскоре рассмотрим его.

Обратите внимание, что из-за большого количества запросов мы не можем гарантировать, что каждый будет выполнен. Мы полагаемся на добровольцев, поэтому, если вы разработчик, рассмотрите возможность пожертвовать часть своего времени и отправить патч . В противном случае, пожалуйста, знайте, что мы все прилагаем все усилия, чтобы преодолеть отставание и как можно скорее ответим на ваш запрос.

Неужели это было так сложно?

Что ж, вместо того, чтобы просто сказать «представь патч», тебе стоит немного подробнее рассказать.

• Дайте понять, что у вас нет времени на это прямо сейчас или в обозримом будущем, поэтому, если другие захотят, чтобы это было реализовано в ближайшее время, нет другого пути, кроме как предоставить патч.
• Потратьте время, чтобы оценить функцию. Если вам это искренне нравится, говорить это не повредит. Поощряйте людей. Или, если вы считаете, что эта функция на самом деле плохая, найдите время, чтобы объяснить это.
• Предоставить некоторую стартовую помощь. Никто не знает кодовую базу, как вы. У вас нет времени, чтобы сделать это, но вы, вероятно, точно знаете, как вы это сделаете и с чего начать. В течение 5-10 минут вы можете поделиться знаниями, что другим понадобятся часы, чтобы понять. Также это помогает вашей большой картине преобладать. Вместо того, чтобы добавлять инопланетные функции в ваш проект, вы можете направить участников к приятной интеграции.

Вот что я обычно говорю ...

«Это интересное предложение, и было бы здорово, если бы FooBarLib мог это сделать. К сожалению, FooBarLib - это просто проект для меня, поэтому вряд ли я смогу сделать это в ближайшем будущем. Я приветствую материалы, представленные FooBarLib, поэтому, если вы можете реализовать это самостоятельно, тогда отправляйте патч (не забудьте сначала прочитать наши «как внести свой вклад в рекомендации FooBarLib»).

В дополнение к хорошим способам сказать «Отправить патч», также предоставьте документацию, ориентированную на разработчика, чтобы другие, кому действительно нужна эта функция, могли быстро освоить ваш проект. Многие проекты не являются дружественными для разработчиков и требуют дней, чтобы как минимум прочитать тысячи строк кода и множество небольших тестовых примеров, которые выискивают в разных частях системы, чтобы получить правильные результаты.

Если вы предоставите помощь возможным разработчикам, они будут более чем готовы оказать помощь. Это означает хорошую документацию по коду, хорошие вики-страницы, объясняющие процесс (или хорошую диаграмму UML / whiteboard), и простой способ получить исправления.

Мне действительно нравится то, как github побуждает других раскошелиться на проект. Несколько версий одного и того же проекта могут существовать под разными учетными записями пользователей. Если вам не нравится направление, в котором я веду проект, пожалуйста, раскошелитесь. Вы можете легко отправлять запросы, но не застреваете, ожидая, что я приму их.

Так что мой ответ часто, просто раскошелиться.