Pull to refresh

Comments 93

Странная статистика. Например, для России они требуют наличия аж 59 подписчиков на твой аккаунт. А вовсе не количество публичных коммитов. В результате в половине топа какие-то левые аккаунты с всего десятком коммитов.

Какая-то странная статистика.

Например я(antonmedv) на 153 месте в Швейцарии. А vladh на 150.

Но сравните наши gh профили?

А как думаете, к какому случаю относится этот отклонённый репорт и пулриквест:

https://github.com/notepad-plus-plus/notepad-plus-plus/issues/10590

(суть репорта: Notepad++ принимает текст из буфера обмена без его проверки на размер, надеется, что в конце буфера всегда будет нулевой терминатор)

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

Ваш пул реквест был отклонен по нескольким причинам:

  • несоблюдение правил комьюнити по оформлению PR и Issues

  • неадекватное поведение в комментариях - наличие проблемы очевидно только вам, но не всем

  • проблема создана искуственно, т.е. в реальной жизни этот сценарий маловероятен

  • приложение не упало после этого, а просто вставило мусор, т.е. даже если кто-то это сделает то вреда не будет

  • и самая главная причина - ревьювер не смог повторить эту проблема, поэтому отказ

Да, наверное так и есть.

Но проблема была встречена в реальных условиях, при создании сторонней программы и практически случайном вставке текста из неё в Notepad++. По сути Notepad++ со своим багом помог найти баг о потерянном нулевом терминаторе той программы. 😎

Но потом я подумал, что в современных условиях переполнение буфера, в любом виде, рано или поздно будет как-нибудь зловредно использовано и решил помочь любимому Notepad++. А раз баг уже подтверждён в коде и исправления тривиальны, то пошёл по минимальному пути.

Там в этой дискуссии оба хороши. Автор понадеялся, что описав проблему не в соответствии с шаблоном ее тут же пофиксят (хинт — ни в коем случае так не делать. Нечего написать в шаблон — так и напишите, что не понимаете, что туда писать. Так по крайней мере не будет выглядеть, что вы умнее авторов проекта и указываете им, как делать свой проект).


Отклонивший тоже хорош — проигнорировал явно бесполезный вызов в коде (возможно, если бы автор воспользовался возможностями GitHub-а вставки перманентной ссылки на код, этого бы не случилось. Да даже просто сделать PR, а не issue. Поэтому второй совет — изучайте используемый инструмент!). Уверен, сообщи ему об этом статический анализатор, это было бы исправлено.

Плюс код был некорректно оформлен (не соблюдено форматирование, используемое в проекте).

Потому что бага там нет:
CF_UNICODETEXT
A null character signals the end of the data.

А с вашим «исправлением» — был бы:
GlobalSize
The size of a memory block may be larger than the size requested when the memory was allocated.

Не понял вашего коментария. Предположим нулевого символа по какой либо причине в буфере нет, и что?

и что?

И ничего хорошего, т.к. по контракту (см. выше) он там быть обязан.

Значит, контракт будет нарушен и чьи-то ожидания разойдутся с действительностю.


А теперь представим, что некая программа аллоцирует блок размером не "длина строки + 1", а "длина строки + 42", при этом корректно и строго по документации добавляя нулевой символ после данных. Ну или сама ОС аллоцирует больше запрошенного по каким-то своим причинам, и что?

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

У самого был реквест по багу https://github.com/sonata-project/SonataAdminBundle/pull/4498 который и не приняли и сами баг не фиксили хотя репортов было несколько. Мотивация конечно у меня была и тщеславие. Но нужно было и практически пофиксить баг так как в админке тупо не работали селекты. Пришлось отказаться от этого бандла. Через несколько лет кто то сделал эту самую правку.
Были и другие случаи. Предлагали дать правки в очень престижный проект просто чтобы расширить число контрибьбторов. Это такая же важная метрика как и количество звёзд или скачиваний. Отказался так как немного устал на тот момент.

Хм... Подумаешь - отклонили PR. Все, жизнь закончена, меня не ценят и,не любят... "Разбежавшись прыгнуть со скалы" (с)

Дышим глубже. Даже если от версии к версии накатывается один и тот же патч совсем не факт, что это нужно кому-то кроме тебя. И падение приложения у тебя совсем не означает что оно падает у всех. Потому главное,. что осваивает программист при работе с OpenSource это навыки командной работы. Второе - это умение понимать и исправлять чужой код. Да так, чтоб без лишних слов, да так чтоб код оставался понятным и соответствовал стилю проекта (а они разные у разных проектов). И только в последнюю очередь развитие и новые фичи.

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

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

  • те, кто все еще понимает задачу проекта буквально - "создать качественный набор данных, описывающий биоразнообразие в штате Мэриленд", например,

  • и те, кто без конкретной декларации такого смещения задачи, свято уверены в том, что проект существует только для того, чтобы "популяризировать (тут вписать область деятельности проекта), то есть на качество результата им вообще плевать.

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

У меня история open source намного менее насыщенная. Я просто при очередном желании контрибьютить куда-нибудь сталкивался с подмножеством проблем из списка:

  • Неуловимый Джо: В подавляющем большинстве случаев проектом пользуется полтора человека на Земле. Раз уж мы хотим тратить свое драгоценное время, не лучше ли контрибьютить в то, чем косвенно пользуются миллиарды людей?

  • Trust me, I'm an engineer: Отсутствие на момент старта проекта каких-то фич в языке или Генеральная Линия Партии приводит к велосипедам уровня поддержки ООП в Си. В итоге от чтения исходников кровоточат глаза.

  • Nothing To Do Here: Всё самое содержательное написано в первые пару лет проекта, ничего нового особо не напишешь, "всё уже украдено до нас". Часто идёт в ногу с ревью PR раз в квартал.

  • Атлант расправил плечи: Проект билдится около 8 часов, и то приходится отключать debug-символы, чтобы он собрался в бинарник без сжирания всего RAM.

  • Ты не пройдёшь!: Иногда проект имеет высокий порог входа настолько, что надо несколько месяцев/лет учить матчасть (ядро ОС, компиляторы и т.д.) Такие проекты часто разрабатывают люди из Microsoft/Google/Apple/etc. на зарплате, потому что за "спасибо" - никому не сдалось.

  • Где деньги, Лебовски?: На факт контрибьютинга в open source всем пофигу, работодатели не выстраиваются в очередь, и офферы не начнут приходить рекой.

Вы уверены что у вас есть желание контрибутить, а не _искать причины чтобы не контрибутить_?

Как вообще это работает? Вы просто сели и такой абстрактно "хочу что-нибудь куда-нибудь законтрибутить"?

Я считаю что любой программист должен контрибьютить в open source, потому что сейчас все используют open source для написания приложений. Нужно быть благодарным.

Это как с торрентом - я скачал фильм, а вот раздавать не буду. Т. е. пользоваться результатами чужого труда норм, а самому сделать вклад - нафиг надо?

UFO just landed and posted this here

Прям все и везде?

Да, за исключением, возможно, каких-то очень узкоспециализированных решений (может для Спирита и Оппотьюнити и не использовался открытый код)

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

Это только пример, новые фильмы я смотрю в кино, старые на Kinopoisk/Ivi. На торренте скачиваю то, чего в других местах не нашел (ок, не всегда, и не всегда раздаю:)).

А вы, я так понимаю, скачиваете, но не раздаете?

С другой стороны вам бесплатно дали яблоко. Подарили. Обязаны ли вы ответить взаимностью? Нет. Это лишь рекомендовано, но не предписано.

Так же и с Open Source. Риск, что взаимностью не ответят есть всегда. И это нормально.

Касательно же торрентов - пример плохой. Взял, слил чужую интеллектуальную собственность и/или сконвертировал avi в mp4 или любой другой формат - прямо адский труд. Автор герой просто. Геракл, не иначе

С другой стороны вам бесплатно дали яблоко. Подарили.

Вам его никто не дарил, вы его сами взяли. Это как человек посадил яблоню, и разрешил срывать яблоки всем. И вот вы ходите и постоянно срываете яблоки. Как бы ничего такого, он сам разрешил, но по человечески, как-то плохо постоянно пользоваться, но ничего не давать взамен.

Касательно же торрентов - пример плохой.

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

А я считаю, что любой программист должен open source ровно столько, сколько написано в лицензии тех open source продуктов, которыми этот программист пользовался. Хотите чтобы все пользователи вашей библиотеки контрибьютили в ваш проект - так и пишите в лицензии. 

Вы уверены что у вас есть желание контрибутить, а не _искать причины чтобы не контрибутить_?

Не могли бы вы развернуть мысль? Вас смущает факт, что у некоторых людей время дорогое и они не будут его тратить на деятельность без выхлопа?

Поиск причин не контрибутить — это и есть деятельность без выхлопа.

Но вы же прочитали мой комментарий, который я написал за пару минут, и ответили на него? Вот ненулевой выхлоп. А код, на который вы потратили кучу времени, я никогда не прочитаю и на меня он не повлияет. Вот и нулевой выхлоп =)

UFO just landed and posted this here

Кроме всего перечисленного, автор кода получает ещё и исправленную/доработанную программу в свое распоряжение, иначе можно до морковкина заговения ждать её починки кем-то другим.

у некоторых людей время дорогое и они не будут его тратить на деятельность без выхлопа

Вы как-то узко ограничиваете причины написать код чисто экономическими соображениями. Человек сам для себя определяет что он считает выхлопом, а что нет. И критерии отнюдь не ограничиваются деньгами. Люди слушают/играют музыку, читают художественную литературу, клеят модельки, ходят в походы, поют, выращивают цветы, занимаются вышиванием, да всё что угодно. И делают всё это не из-за денег, а потому что "им это интересно". Just for fun. И я не верю что у вас нет подобных занятий, когда вы умышленно тратите время на деятельность, не приносящую денег (а то и наоборот, требующую их на инструменты/материалы). Так вот, некоторые люди видят fun в создании свободных программ. Если вы его не видите - ну ничего страшного, занимайтесь своим любимым делом.

Проект билдится около 8 часов, и то приходится отключать debug-символы, чтобы он собрался в бинарник без сжирания всего RAM.
Обычно в таких случаях проще поправить баг патчем непосредственно бинарника, благо отладчики и дизассемблеры развились очень и очень сильно… в отличие от убогого инструментария C++, который так и застрял в начале 90-х. Нормальной работы с зависимостями там нет и по сей день, как нет и возможности проверить наличие всего необходимого ДО начала компиляции, вместо того чтобы вываливаться с ошибкой сборки через 6 часов после старта из-за того, что какая-то библиотека или иной компонент не найдены/не той версии.
В качестве примера могу вспомнить библиотеку torch, в которой я правил раздражающий баг с неуместными варнингами, зафлуживающими весь output, именно патчем бинарного libtorch_cpu.so. Собранная библиотечка представляет собой блоб на ~355 Мб бинарного кода(!), но при этом благодаря современным средствам реверсинжениринга поиск и правка бага заняли всего лишь около полутора часов, при том что из исходников проект собирать не менее 12 часов, это если он вообще соберётся с первого раза, а не вывалится часов через 5-7, как это обычно происходит с плюсовыми проектами.
UFO just landed and posted this here
Если речь не о сценарии «пропатчил и удалил», то инкрементальная компиляция приходит на помощь: хоть первая сборка и займёт часы, зато каждая следующая — считаные минуты.
UFO just landed and posted this here

На факт контрибьютинга в open source всем пофигу, работодатели не выстраиваются в очередь, и офферы не начнут приходить рекой.

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

Произошла чудовищная ошибка(выжившего)! А если серьезно - то если всрать такое количество ресурсов в контрибут в проекты, в которых заинтересованы работодатели, то имхо те же усилия приложенные к натаскиванию на собеседования дадут гораздо больший выхлоп. К тому же это будет интересно не только тем работодателям которые используют ваши проекты.

Вы возразите, что вам это в кайф, и карьера просто приятный бонус. И конкретно для сета ваших проектов оно так, потому что в вашем воображении эти проекты интересны. В воображении других интересна какая-то другая тематика, в которую они готовы вкладывать силы на энтузиазме. Возможно даже больше сил, чем вы. Только карьерный выхлоп с них будет околонулевой. И чтобы он был отличным от нуля, таким энтузиастам нужно искать что-то релевантное тому за что платят деньги, и через силу строчить коммиты туда. Что опять возвращает нас к вопросу не рациональнее ли приложить эти силы на подготовку к собеседованиям вообще?

Ну если вы это делаете только для поиска работы, то наверное да) Но это такая скука)

Тут подвох в том, что авторы реплик "я делал опенсорс и о это дало мне работу" обычно тактично опускают тот факт, делали опенсорс для довольно узкого круга проектов, которые востребованы у работодателя. И просто благодаря этому многие контрибьюторы пролетают.

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

Очень сомневаюсь, что в проектах, куда контрибутит условный @0xd34df00d, нет отбоя от карьеристов.

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

@0xd34df00d это редкое исключние из правил. И по узости специальности и по языку и по способностям. При этом сотни таких как он, вложив душу в чуточку другой стэк, отправились подыхать под забор по причине невостребованности. И у них тоже наверняка были сложные проекты где кроме них да еще пары сверхувлеченных, никто не коммитил.

Ну и зачем?

За пределами мира розовых поней интересной работы на всех не хватает. И даже интересная, обложенная сроками, ограничениями и прочим, недолго остается таковой.

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

Присоединяюсь. Пару раз бывало: "так, эту проблему я уже решал N лет назад в таком-то проекте, где тот мой патч?" При этом в код, написанный на "основной работе", после ухода с неё уже не заглянуть.

"Отпускай хлеб твой по водам, потому что по прошествии многих дней опять найдешь его."

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

У меня есть подозрение что проблема в этих самых ваших плодах труда, а не в плохих дядьках, не желающих по абсолютно разным причинам их принимать. Ссылок на PRы покажете?

Не покажу, мне еще немало крамолы тут писать.

Сам наткнулся на ситуацию, когда сделанный совместно с еще одним человеком патч (патч исходно его, я немного доработал) не принимают более года. Там и другие pr, о которых просили в issues также висят. Сам проект - библиотека для конфигурирования, родоначальник одного из форматов для конфигурации. Майнтейнер - коммерческая компания, выпустившая популярный в определённых кругах фреймворк (и даже не один). Там даже посторонние люди писали, что это немыслимо, что по pool request-у нет даже feedback-а. Не уверен, что изначальный автор библиотеки там еще работает, т.к. в ответ на письмо про помощь с развитием, он ссылался на эту компанию в третьем лице. Подозреваю, что у них тупо нет ресурсов для развития библиотеки, а текущий функционал их устраивает и они не хотят чтото сломать у себя (или у своих клиентов: библиотека используется в целой экосистеме). Подозреваю, что нормальный выход из ситуации - создание форка, но на это у самого тупо нет времени.

Никогда не понимал этой боязни "что-то сломать". Они там про SemVer не слышали что ли?

UFO just landed and posted this here

Никто не предлагает обновлять зависимости своего проекта. Но выпустить новую версию свой библиотеки для своих пользователей, а самим пользоваться старой версией, раз она их устраивает, им кто запрещает?

UFO just landed and posted this here

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

UFO just landed and posted this here

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

Не согласен про "тусовочку", но я гляжу на всего один проект конечно, LibreOffice. И там такого точно нет, каждому патчу рады, если он реально делает что-то нужное.

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

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

UFO just landed and posted this here

пользователи в обсуждениях уже предлагают другу другу вручную применять патч и делать билды самостоятельно

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

> известного торрент-клиента

Аналогичный опыт с Transmission, если про этот клиент. Правда всего три месяца подождать пришлось, с ответом через месяц после каждой правки.

UFO just landed and posted this here

Многих авторов опенсорс проектов вполне можно понять, если встать на их место. Когда человек действительно занимается проектом, обдумывает его развитие и у него сформировано определенное видение развития, а конкретнее - как, и что данный софт должен делать, и самое главное, чего он не должен делать. И когда ему приходится постоянно отбиваться от всяких "контрибьютеров", которые вообще не разобравшись с проектом лезут со своими PR "новой модной фичи", и которым нужно каждый раз объяснять, почему их "улучшение" не будет принято, то после определенного момента, этих авторов это все задалбывает и они без объяснений начинают закрывать подобные PR. А дальше идут обиды, что автор токсичный мудак и вообще не достоин находится в нашем комьюнити (вспоминается автор Actix). Я сам наблюдал такую трансформацию несколько раз.

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

Если ваш PR не принимают, это может значит одно из многого. Но чаще всего - из-за недостатка времени у ментейнеров. PR же осмыслить надо, убедиться, что вреда от него значительно меньше, чем пользы. А это - время. Его мало. Да и самих ментейнеров мало в сравнении с контрибьютерами. Значительно проще и безопаснее дать вашему PR умереть своей тихой смертью от руки бота. Знаю о чём говорю, потому что сам ментейню проект с 18k звёзд на гитхабе. До этого успел наконтрибьютить где-то в 40 проектов разной степени популярности.

Но чаще всего — из-за недостатка времени у ментейнеров.

С другой стороны, зачем нужен мейнтейнер, если у него нет времени на проект? Разве это не его прямая задача — иметь время на проект (просто по самому определению ментеййнерства)? Это значит, что его и нет, но формально он есть и занимает место того человека, у которого время бы нашлось.

Вы правда думаете, что места ментейнеров - ограниченный ресурс? Что они могут быть заняты и вакантны? Что ментейнеры кому-то что-то должны, кроме их работодателей?

Взялся за гуж — не говори, что не дюж


Никто на этой должности не держит. Уйти можно в любой момент

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

Будучи ментейнером, очень приятно разобраться со всеми реквестами. Но контрибьютеров много, а ментейнеров почему-то мало. В Kubernetes - это довольно острая проблема. И Линус о том же говорит.

Ну вот я точно знаю, что у меня нет прям такой любви к проекту, что я смогу его ментейнить (== добровольно взять обязательства следить за проектом, отвечать на требования сообщества). Поэтому ничего и не мейтейню. А если бы мейнтейнил, но не справлялся, то так бы об этом и написал на странице проекта — ищу нового человека. А судя по вашим репликам у меня складывается мнение, что вы считаете совершенно нормальным, что у вас не хватает времени на эту работу, но сообщить об этом сообществу и пригласить себе помощника или замену не хотите. Если такие попытки есть, но кандидатов не видно — то мой вам почет и уважение. Если нет — извините, но только порицание.

Я ведь написал, придти может любой, у кого достаточно квалификации. Требования обычно в файле GOVERNANCE.md лежат. Новым ментейнерам всегда рады независимо от того, сколько их уже есть. Наверно, просто мало любви у людей к проекту?

Хаха)) Вы думаете там конкурс? В большинстве случаев если майнтейнер уйдет, то проект можно архивировать

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

У меня есть реальная история. У проекта был майнтайнер, который раз в 2 месяца принимал PR-ы с фиксами. Это даже был не майнтейнер, а просто чувак с правами принимать PR-ы. Но потом появился инициативный чувак и сказал, а давайте я буду майнтенером! И стал. Мерджил все подряд, сломал все что можно и слился. Тот первый посмотрел на это и свалил с проекта. Так и висел проект 2 года в полуразобранном состоянии.

Бывают и исключения, благо существуют форки.

большинство серьёзных опенсорсных проектов ментейнятся людьми на зарплате. 

вот прямо на зарплате компании/организации, которая владеет проектом? или с попустительства/разрешения работодателя? или в свободное от работы время?

это будут совсем разные истории: ментейтер как должностная обязанность, или ментейннер пока не надоело.

Разные истории работы и жизни:

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

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

Ну, да. Я же про серьёзные проекты говорю, а не про хобби.

Есть ещё одна проблема, с которой я не имею ни малейшей идеи как быть, кроме как не принимать реквесты совсем: Двойное лицензирование.
Как автор библиотеки я могу это сделать со своим кодом, но не с кодом, который попадает в OpenSource форк через реквесты. И у меня нет желания мейнтейнить 2 разных форка примерно одного и того же.

К сожалению или к счастью, на данный момент проблема чисто теоретическая.

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

На самом деле вы задали несколько каверзных вопросов, которыми я не задавался. Как контрибьютор, всегда думал, что таки да, я передаю код под лицензиею, что использует репозиторий, куда я отправляю код (напрямую или через реквест). И на самом деле пока я не комичу что-то этакое (что-либо, что я могу переиспользовать в другом проекте, или что либо, потенциально нарушающее авторские права/патент/etc) — это проблемы мейнтейнера.

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

У меня была/есть такая же проблема. iOS приложение, опубликовал под GPL, отдельная лицензия для AppStore. Чтобы не было проблем с Apple, у меня должны быть все права на код. Поначалу единственным решением тоже казалось не принимать пулл-реквесты.

Но есть и немного лучшее решение: Contributor License Agreement (CLA). По сути, контрибьютор передаёт автору проекта все возможные права на внесённый код. Принятие соглашения легко автоматизируется через cla-assistant.

С юридической стороны всё отлично: автор проекта может лицензировать новый код как угодно.

С практической стороны, конечно, это антигуманно. Мало того, что контрибьютор сделал доброе дело, так его/её ещё заставляют читать несколько страниц забористого юридического жаргона и отказываться от своих прав в пользу автора проекта. В общем, CLA отпугивает контрибьюторов даже эффективнее чем "спасибо, но мы не принимаем пулл-реквесты." Но всё таки даёт хотя бы теоретическую возможность принимать пулл-реквесты.

Когда создаешь большой PR, нужно понимать что у автора проекта есть свое видение его развития, есть roadmap и ограниченное количество времени на ведение проекта. Автор легко примет небольшой PR, который потребует 10 минут на review, но отклонит большой от неизвестного чувака, потому что изучение кода потребует много времени, а принимать его "на доверии" он не будет.

Поэтому, если вы действительно хотите внести большой вклад в open source, не нужно контрибьютить в 50 разных проектов, выберите 1, станьте частью core team и коммитьте на здоровье.

Поэтому я, например, стараюсь, чтобы мои PR не вылезали за 10 коммитов, а каждый коммит собирался и проходил все тесты. И вместо одного большого PR слать десятки. Примут один — сразу открываем следующий, благо, код для них уже написан и только и ждет, когда примут предыдущий. А если PR друг от друга не зависят, или зависят мало, то одновременно можно открывать.


К сожалению, даже в такой ситуации ничего не поделать, если мейнтейнерам плевать на проект. Уже вроде и все расписано, и все зааппрувили, только кнопку в интерфейсе нажать — и все равно висит, как здесь. Причем, периодически там в issues отписываются люди, у которых есть права на нажатие кнопки.

Регулярно контрибьючу мелочь которая нужна самому (а так же принимаю чужие PR в свои). Основная проблема - непонятно - попадутся нормальные адекватные ревьюеры, или ЧСВ-шники с синдромом вахтёра.

Нужен какой-то бейдж в репозиторий, который говорит о том что он contributor-friendly, или что-то вроде того.

А так же список пунктов, которым должен соответствовать проект чтобы зваться contributor-friendly. К примеру, PR принимается во всех случаях при выполнении условий:

  • Не ломает текущую функциональность

  • Покрыт юнит-тестами

  • Удовлетворяет требованиям по code-style

  • В случае проблем с архитектурой / etc. - ревьюер предлагает как поправить PR чтобы он вписался в архитектуру (и никак - не ответ, либо пиши как переделать - либо принимай)

  • В случае если новая функциональность не вписывается в идеологию проекта - предлагать переписать в виде стороннего плагина. Нету системы плагинов или через неё сделать нельзя? Принимай PR!

В целом - в мелкие / средние проекты довольно легко контрибьютить, авторы как правило адекваты и рады PR-ам. Хотя есть и исключения.

В крупных - как повезёт (зависит от проекта и от конкретного ревьюера).

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

В случае если новая функциональность не вписывается в идеологию проекта — предлагать переписать в виде стороннего плагина. Нету системы плагинов или через неё сделать нельзя? Принимай PR!

Не-не-не, так дело не пойдет. Зачем мне видеоплеер в текстовом редакторе, например?


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

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

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

Т. е. если PR добавляет ненужные возможности, то он будет принят? Через год проект превратится в такого крокодила что им никто не захочет пользоваться и коммитить в него))

Скорее нужен бейдж "Адекватный контрибьютер" ))

UFO just landed and posted this here

Скажу как мейнтейнер одного крупного (1.5 млн строк) java-проекта:

  • Новичку зачастую не знакома история проекта и история различных "багов". В результате появляются исправления вида "я тут посмотрел код и нашел решение". Формально оно исправляет баг, но де-факто лишь прикрывает костылем одну из дырок.

  • Следствие из предыдущего пункта -- если человек сделал объемный PR и, алилуйа, даже тесты написал (что бывает крайне редко), но при этом не дожал или пошел не по тому пути, то приходится самому разбираться в проблеме и дописывать код. Это иногда раздражает и отнимает лишнее время.

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

  • А вообще, новый разработчик в проекте -- это всегда радость. Пусть даже и небольшие исправления от него. Собственно, как и любая активность от обычных пользователей вроде баг репортов или предложений.

Согласен на 100%, тут большенство комментаторов жалуются что не принимают их очень важные PR-ы, а то что на GitHub-е куча неадекватов и каждый PR нужно досконально проверить, их не волнует. Человек, который веред проект, часто, делает это в свободное время, он не обязан тратить его на чей-то говнокод, поэтому принимает только мелкие и понятные PR-ы, а портянки отклоняет.

Э-э-э, а просто указать автору PR, что вот тут недоисправлено — не вариант?

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

Чтобы указать где недоисправлено, нужно изучить код, но в большинстве случаев говнокод видно сразу и проще его отклонить, чем разбираться

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

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

Я бы обощил еще больше. Пусть А - субъект выполняющий действие. Р - результаты труда его действия. П - вероятность выкидывания Р субъекта А на помойку. Тогда для любых А и Р, П > 0.

Sign up to leave a comment.

Articles