Почему в опенсорсе все такие агрессивные? Правила, которые помогут не нарваться на грубость
Разработчик баз данных Михаил Фесенко опубликовал в Twitter тред (точнее, даже два) о своем знакомстве с миром опенсорс-разработки. Спойлер: все оказалось не так радужно, как хотелось бы, но всего несколько правил могут сильно упростить всем жизнь. Публикуем мысли Михаила с его разрешения.
Опенсорс за футболку
Все представляют опенсорс как нечто желанное. Приходишь в GitHub, пишешь код, который тебе нравится, а еще это плюс в карму: зовут рассказывать в Twitter, на «Хабр» и на конференции о том, как вы вытащили крутой опенсорс. Но к сожалению, на деле все не так уж радужно.
Я всегда хотел попилить опенсорс, думал, что это очень круто, и два года назад узнал о Hacktoberfest. Кто не в курсе: DigitalOcean решили спонсировать опенсорс и устроили акцию: сделай четыре merge request (MR) и получи футболку. Причем неважно, откуда ты и куда, главное, сделай четыре MR. Пришлют почтой for free.
Желанные футболки Hacktoberfest
Акция сработала на ура, но DigitalOcean тоже пострадал. Нашлись халявщики, которые просто теребили MR друг другу и получали футболки. Халява — дело опасное. Но не об этом. Мне тоже хотелось — но хотелось реально помочь опенсору, реально сделать что-то полезное.
У меня есть способность/проклятие: я люблю копать, лазить в кишочках и искать некрасивости. То есть убрать дубликаты, поменять нейминг, сделать микрофиксы, которые улучшают код. Такая легкая обработка в стиле Дяди Боба. Ну я и пошел по топовым PHP- и Go-репам качать и присылать MR-чики.
Три варианта реакции
Было три варианта событий. Первые ребята сразу мержили, писали: «Спасибо! Отлично! GGWP =)». Вторые ребята говорили: «Спасибо, но поправь еще тут, поправь немного там» — и мержили. В целом, отличные ребята, но со своими правилами. И третьи ребята — это отдельный вид.
Один закрыл MR: “I don’t think this is improvment”. Другой закрыл, так как ему не нравится, что я сделал, и вообще это не полезный MR. Третий закрыл, так как увидел у меня два закрытых MR и решил тоже закрыть, ну а че. Четвертый тоже хотел закрыть MR, но вдруг пришел еще чел: «мне норм» — и помог подпилить MR.
Создатель LiveJournal Брэд Фитцпатрик не впечатлен
В общем, третья группа меня удивила, обидела и расстроила. Оказалось, что в опенсорсе все не так радужно, как я думал. Короче, я получил футболочку и был рад. В следующем году я уже был готов ко всему и странное поведение не удивило.
Когда MR не приняли
Итак, сделав pull request (PR) в разные репы, я получил разный фидбек: как позитивный, так и негативный и даже неадекватный. О позитивном особо нечего сказать, так как ребята рады, что им помогают, и сразу мержат твой PR.
Негативный — это когда тебе говорят, что ты сделал хуже, и твой PR закрывают, но обычно пишут адекватную причину, почему так НЕ лучше. Или напишут, что фикс окей, но в проекте выбран другой подход, извини. Некоторые ревьюверы долго мурыжили правками тут и там, но в итоге мержили.
Были и неадекваты, которые закрывали PR и почти матом говорили, что я тупой, куда я лезу. Некоторые писали что PR норм, но ревьюверу это не нравится и он не будет мержить. «Может, придет кто-нибудь и замержит». Были и те, кто вешал лейбл invalid и закрывал PR без комментариев.
Откуда берется агрессия?
У меня есть пара крутых знакомых: один постоянный контрибьютор в Golang, другой тоже пилит, но в менее популярной репе. Я обсудил с ними странных ребят и спросил, почему так может быть: вроде к тебе приходят люди и пытаются помочь проекту, а ты ведешь себя мегаагрессивно.
Во-первых, не все правильно (в том числе, я) представляют, каково это — пилить что-то в опенсорсе. Если тебе повезло и ты пишешь его в компании на фултайме, то тут все отлично. Приходишь на работу, ревьювишь PR, пилишь код для работы/закрываешь тасочки — все просто.
Как все представляют работу в опенсорсе
Но у большинства другая история. У тебя есть основная работа. Ты любишь опенсорс-проект, но у тебя еще семья и разные заботы. Тебе сыпятся issue, их надо разгребать. А еще PR — и их нужно не просто прочитать, а понять, что хотят и зачем. Причем чем популярнее репа — тем чаще шлют. Силы кончаются.
Получается, ты выкладываешься. Ты стараешься затащить побольше функционала и фиксов багов/производительности. В качестве фидбека часто получаешь звездочки на GitHub да и только. Иногда — приятные комменты, но к сожалению, они не покрывают твои затраты. Поэтому происходит то что происходит.
Человек становится жестким, режет все, что не нравится, принимает только адекватные хотфиксы. И чем больше поток входных данных, тем жестче правила в репе. Поэтому вот краткий список правил, которые помогут вам в контрибьюте, а так же помогут репе.
Правила опенсорса
- Обязательно читайте и следуйте CONTRIBUTING.md — это решит кучу проблем.
- Поищите свою проблему в issue/PR — возможно, ее уже сделали или есть решение. Может, вам и не нужно ничего делать. Особенно обидно, когда ваш PR закроют и скажут: вот, в #1234 уже обсуждают этот баг. У меня был кейс с багом, когда я разобрался с репой, прогнал тесты, починил и мне сказали, что это отличный фикс, но для версии master (5.0.0) а сейчас в разработке develop (6.0.0) и в ней баг уже пофикшен, сорри. Бывает и такое.
Когда баг исправлен
- Если решения нет, создайте issue и детально опишите — может, вам подскажут, как лучше сделать. Надо писать код? Пишите! Но: запускайте/пишите тесты. Если ваш фикс — на пару строк или это рефакторинг нейминга, будьте готовы к closed, так как слишком много времени читать, оно того не стоит.
- Подтяните, пожалуйста, английский. Коммуникации — это всегда сложно. А если тебе постоянно приходится читать странные PR, да еще и с ошибками, — лучше убейте. Используйте deepl.com и Grammarly. Ваша задача — не только починить, но и упростить задачу ревьюверу.
- И последнее, что я для себя понял: когда вы кидаете фикс, помните: вы — юзер, у которого болит, вы — QA, который проверяет и резюмирует, вы — разраб и вы — документатор. Подумайте о ревьювере, помогите ему. Всем благ!
Сообщить об опечатке
Текст, который будет отправлен нашим редакторам: