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

18

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

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

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

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

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

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

Джо Лисс
источник
10
Очень важно, если вы не собираетесь принимать патчи, не просите об этом! То есть, если вы говорите «Отправить патч», вы должны быть готовы принять чистый, хорошо написанный патч.
edA-qa mort-ora-y
1
@ edA-qa - не обязательно каждый чистый, хорошо написанный патч - но если вы, скорее всего, наложите вето на новые функции, у вас, вероятно, должен быть способ, которым люди могут предложить вам эти функции, чтобы, вероятно, не ответить, прежде чем инвестировать много время их разработки.
Steve314
@ Стив, я не имею в виду нежелательные патчи, это другая история. Я имею в виду конкретно, как в вопросе, если вы скажете кому-нибудь, чтобы представить патч.
edA-qa mort-ora-y
Это высокомерно и грубо, когда вы действительно имеете в виду «это может или не может быть хорошей идеей, уходи». Если вы честно имеете в виду, что это плохая идея, так и скажите. Если вы имеете в виду, что это действительно хорошая идея, что у вас нет времени на ее реализацию, так и скажите. И укажите, что вы готовы принять патч, в котором реализована эта функция. (Таким образом, может быть, кто-то на самом деле представит патч.) Проблема, связанная с тем, чтобы просто сказать «представить патч», является расплывчатой ​​и пренебрежительной.
Дэвид Шварц

Ответы:

8

Вы не

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

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

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

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

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


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

Дени де Бернарди
источник
1
Я не мог согласиться больше. Похоже, что среди проектов F / OSS существует общее мнение, что любой, кто отправляет запрос на функцию, просто ленив и может отправить патч / изменить свою установку, если он действительно хочет эту функцию. Это крайне неприятно для тех, кто просто не знает, как программировать, или не имеет времени, потому что они вовлечены в другие проекты. Это не слова «представить патч», это грубо, но предположение, что у пользователя больше ничего нет на их тарелке.
Шона
9

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

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

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

gbjbaanb
источник
Мне это нравится. Возможно, это действительно что-то лучшее, что можно вставить в документацию, поэтому вам не нужно копировать и вставлять это каждый раз, когда вам нужно это объяснить. И тогда вы просто говорите: «Вы хотите добавить патч? Http: //.../#contributing»
Джо Лисс
@JoLiss: Вы критиковали мой ответ за звучание безличного; Как вы думаете, что лучше скопировать и вставить гиперссылку на FAQ? Если вы собираетесь использовать постоянный ответ, то используйте ответ, который либо демонстрирует сочувствие, либо звучит профессионально (или оба). Эта идея для ярлыка не является ни; на самом деле это именно та грубость, на которую жаловался первоначальный вопрос.
Aaronaught
Да, интересно. Я не понимал, что люди обязательно найдут это грубым, если вы разместите ссылку. С другой стороны, я считаю, что консервированные ответы кажутся очень безличными. Так что, возможно, лучше всего просто напечатать подобные объяснения, когда они придут.
Джо Лисс
6

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

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

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

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


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

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

Арсений Мурзенко
источник
5

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

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

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

Aaronaught
источник
+1 отлично; хороший, профессиональный ответ. @ Джо Лисс: имейте в виду, что большинство людей просто хотят использовать программное обеспечение, а не посвящать ему свою жизнь.
Стивен А. Лоу
Мне нравится суть этого, но я лично думаю, что тон слишком безличен. Обычно вы не компания, занимающаяся обслуживанием клиентов, вы просто разработчик, разговаривающий с коллегами. Даже люди в 37signals избегают этого типа языка .
Джо Лисс
@JoLiss Вы которые делают обслуживание клиентов, хотите ли вы верить этому или нет. И ты ничего не сказал про "сверстников". Возможно, что человек, с которым вы разговариваете, является разработчиком, но если вы не знаете об этом на самом деле, я не думаю, что это правильное предположение (если вы не работаете над инструментами разработчика, но вы не указали что в вопросе). Наконец, парни на 37 сигналах говорят о том, что составляет ерунду ... по иронии судьбы, если не сказать больше.
Aaronaught
Гектометр Я не уверен, что хотел бы создать впечатление, что я занимаюсь обслуживанием клиентов ... Однако, ваше мнение о том, что пользователи не обязательно являются коллегами, хорошо воспринято. Что касается сигналов, вот еще одна запись в блоге, в которой говорится о тоне - я думаю, что дело не столько в том, что вы не должны ерунду, но в том, что вы не должны отрываться как безликая корпорация. На мой взгляд, это хорошая стратегия, и это еще более верно для проектов с открытым исходным кодом.
Джо Лисс
2
@JoLiss: Если вы хотите быть более личным, чем это, прекрасно, вся сила для вас - для меня это минимальный стандарт, которому вы должны соответствовать с точки зрения вежливости. Не просто говорите «представьте патч» - объясните, что вы заняты, а не ленивы или не заинтересованы; признать, что на самом деле они не могут представить патч, и что даже если они это сделают, они все равно окажут вам услугу, сделав обязательство.
Aaronaught
4

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

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

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

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

Марк Хит
источник
2

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

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

TheLQ
источник
-2

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

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

mcotton
источник