В общем, третья группа меня удивила, обидела и расстроила. Оказалось, что в опенсорсе все не так радужно, как я думал. Короче, я получил футболочку и был рад. В следующем году я уже был готов ко всему и странное поведение не удивило.
Итак, сделав 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, который проверяет и резюмирует, вы — разраб и вы — документатор. Подумайте о ревьювере, помогите ему. Всем благ!
