Существуют ли руководящие принципы для запроса улучшения проектов с открытым исходным кодом?
============================================================================================

 Иногда я думаю об улучшениях для приложений с открытым исходным кодом, которые я использую. Обычно я отслеживаю, где находится проект, и регистрирую запрос. Я не собираюсь вносить какой-либо код, я просто хочу внести предложение. 

  В некоторых проектах есть рекомендации по таким запросам (не разрешать их, разрешать их, а хмуриться на «я тоже» и т. Д.), А другие нет. Существуют ли какие-либо широко применимые руководящие принципы или широко упоминаемые статьи о том, как сделать это соответствующим образом? (И какие-нибудь заметки о том, как сделать запрос из контекста Ubuntu?) 

 

1. **Спросите в нужном месте.**  

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

  Начните с проектной документации. В большинстве крупных проектов есть раздел об ошибках, и они, как правило, намекают на то, где лучшее место для определенных типов ошибок. Если проект меньше или более неформальный, прямое общение (электронная почта или чат / IRC) не является плохой идеей. 

  Если разработчик раздражен тем, что вы отправляете прямые электронные письма, и вы искали альтернативы, это своего рода вина, что он не дал понять. 

  В нашем контексте (Ubuntu),  [Launchpad](https://launchpad.net/)  для ошибок,  [Brainstorm](http://brainstorm.ubuntu.com/)  для более широких запросов функций). Во многих случаях вы хотите плыть вверх по течению туда, где живет проект. Если вы можете что-то исправить или добавить в апстрим, вы можете поговорить с сопровождающими Ubuntu о получении патча или обновления в Ubuntu.
2. **Убедитесь, что нет существующего запроса.**  

 1113 Мы закрываем здесь много дубликатов, и я знаю, что Launchpad тоже. Дубликаты тратят впустую время людей, потому что они должны пройти процесс сортировки. Если вы можете найти существующую ветку о чем-то, зайдите туда.  

 Большинство трекеров имеют функцию подписки, поэтому вы можете оставаться в курсе. Если прогресс выглядит застопорившимся, я не думаю, что слишком много людей будут возражать против стиля «Как продвигается? / Могу ли я чем-нибудь помочь?» - стиль тычка.
3. **Будьте вежливы. Будьте внимательны Будь полезным.**  

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

  Независимо от ваших способностей, всегда выясняйте, можете ли вы что-нибудь сделать, чтобы помочь ситуации. Даже если вы не можете помочь напрямую, если вы можете выявить, что должно произойти от разработчика, другие люди могут помочь. Если вы знаете людей, которые могут выполнять определенные элементы, вы можете представить их в ветке и спросить, не хотят ли они помочь вам.
4. **Если можете, подумайте о пожертвовании, спонсировании или найме.**  

 1119 Да, я думаю, что я предлагаю взяточничество. Если вам действительно нужна функция до такой степени, что ее отсутствие стоит ваших денег (напрямую или через потерянное время), я не думаю, что несправедливо хотеть напрямую спонсировать улучшение.  

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

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

  Это на самом деле не очень устойчивый способ ведения дел, но это способ вернуть, который может помочь вам напрямую. Это стоит посмотреть, если вы когда-нибудь отчаялись.