Миша Грачев, Никита Соболев и Леша Смирнов на Open source camp
Позвали контрибьютеров, чтобы было полезно.
Мы задали им вопросы про Open source и получили ответы, которыми будем делиться с вами в ближайший месяц. Куда коммитить, как общаться с мейнтейнерами, как развивать проект, как бороться с уязвимостями, поможет ли GitHub на собеседовании – об этом и многом другом читайте здесь.
Наши эксперты (на фото по порядку): Open source-разработчики Михаил Грачев и Никита Соболев, а также основатель CodeScoring и ведущий канала @codemining Алексей Смирнов.
Позвали контрибьютеров, чтобы было полезно.
Мы задали им вопросы про Open source и получили ответы, которыми будем делиться с вами в ближайший месяц. Куда коммитить, как общаться с мейнтейнерами, как развивать проект, как бороться с уязвимостями, поможет ли GitHub на собеседовании – об этом и многом другом читайте здесь.
Наши эксперты (на фото по порядку): Open source-разработчики Михаил Грачев и Никита Соболев, а также основатель CodeScoring и ведущий канала @codemining Алексей Смирнов.
🔥5
Зачем и как коммитить в Open source?
Open source-разработчик Никита Соболев:
«Если вы не понимаете, как и зачем коммитить в Open source – значит, вам пока рано это делать. Да и вообще, вопрос не «зачем», а «почему» – потому что хочется!
Знаете, как и зачем, но не знаете, что? Есть три пути.
Первый – когда вы чем-то уже пользуетесь и хотите это улучшить. Идете в репозиторий на GitHub, создаете задачку, в которой описываете, что нужно добавить. И ждете реакции мейнтейнера. Она может быть разной – от «да, окей» до молчания. Что с этим делать – расскажу в следующих постах.
Второй путь – если хочется заняться чем-то масштабным, например, на React, Babel или Python. Выбираете задачу, они обычно помечаются специальными значками и можно понять хардкорная задачка или же и новичку подойдет. Делаете по правилам и руководствам, которые написаны для этого проекта, у крупных проектов они всегда есть.
Третий вариант – специальные сервисы-агрегаторы задач и проектов. Cамые популярные – goodfirstissue.dev, goodfirstissues.com, firsttimersonly.com, firstcontributions.github.io».
Open source-разработчик Никита Соболев:
«Если вы не понимаете, как и зачем коммитить в Open source – значит, вам пока рано это делать. Да и вообще, вопрос не «зачем», а «почему» – потому что хочется!
Знаете, как и зачем, но не знаете, что? Есть три пути.
Первый – когда вы чем-то уже пользуетесь и хотите это улучшить. Идете в репозиторий на GitHub, создаете задачку, в которой описываете, что нужно добавить. И ждете реакции мейнтейнера. Она может быть разной – от «да, окей» до молчания. Что с этим делать – расскажу в следующих постах.
Второй путь – если хочется заняться чем-то масштабным, например, на React, Babel или Python. Выбираете задачу, они обычно помечаются специальными значками и можно понять хардкорная задачка или же и новичку подойдет. Делаете по правилам и руководствам, которые написаны для этого проекта, у крупных проектов они всегда есть.
Третий вариант – специальные сервисы-агрегаторы задач и проектов. Cамые популярные – goodfirstissue.dev, goodfirstissues.com, firsttimersonly.com, firstcontributions.github.io».
👍3
Собираем merge за выходные —18.06 и 19.06
Добро пожаловать в комментарии со ссылкой :)
Добро пожаловать в комментарии со ссылкой :)
Я хочу, чтобы меня знали в сообществе, что для этого делать?
Open source-разработчик Михаил Грачев:
«Для этого нужно пиарить свой open source-проект. Есть несколько способов.
Самый простой вариант – добавить проект в awesome-репозиторий на GitHub. Такие репозитории есть под каждый язык программирования или фреймворк. Чтобы найти подходящий awesome-репозиторий для своего проекта, можно начать поиск здесь.
Ещё можно анонсировать свой проект в популярных социальных сетях. Чтобы как можно больше людей узнало о вашем проекте, можно попросить владельцев популярных аккаунтов лайкнуть вашу запись и сделать репост.
Хороший вариант – написание статьи о вашем проекте и публикации ее на популярных площадках, таких как: reddit.com, medium.com, dev.to.
Последнее по порядку, но не по значению – выступление на митапе или конференции».
Open source-разработчик Михаил Грачев:
«Для этого нужно пиарить свой open source-проект. Есть несколько способов.
Самый простой вариант – добавить проект в awesome-репозиторий на GitHub. Такие репозитории есть под каждый язык программирования или фреймворк. Чтобы найти подходящий awesome-репозиторий для своего проекта, можно начать поиск здесь.
Ещё можно анонсировать свой проект в популярных социальных сетях. Чтобы как можно больше людей узнало о вашем проекте, можно попросить владельцев популярных аккаунтов лайкнуть вашу запись и сделать репост.
Хороший вариант – написание статьи о вашем проекте и публикации ее на популярных площадках, таких как: reddit.com, medium.com, dev.to.
Последнее по порядку, но не по значению – выступление на митапе или конференции».
GitHub
GitHub - bayandin/awesome-awesomeness: A curated list of awesome awesomeness
A curated list of awesome awesomeness. Contribute to bayandin/awesome-awesomeness development by creating an account on GitHub.
🔥2👍1
Как сделать так, чтобы разработчики приходили в проект и активно коммитили в него?
Open source-разработчик Михаил Грачев:
«Нужно сделать несколько вещей.
Проект должен быть contributor-friendly, включать в себя файл CONTRIBUTING.md. В нем обычно содержится вся необходимая информация для новых разработчиков. Например, какие зависимости нужно установить перед началом работы или какой формат коммитов используется в проекте. Ещё в этот файл можно добавить информацию про то, как запустить проект, тесты или линтеры, что значительно упростит порог входа новым разработчикам.
Нужно создать issues на GitHub с подробным описанием задачи, которую вы хотите решить с помощью новых контрибьютеров. И повесить на эти issues специальные метки – good first issue и help wanted. Это поможет новым разработчикам находить задачи, которые можно брать в работу. Например, через специальные сайты: up-for-grabs.net или goodfirstissue.dev».
Open source-разработчик Михаил Грачев:
«Нужно сделать несколько вещей.
Проект должен быть contributor-friendly, включать в себя файл CONTRIBUTING.md. В нем обычно содержится вся необходимая информация для новых разработчиков. Например, какие зависимости нужно установить перед началом работы или какой формат коммитов используется в проекте. Ещё в этот файл можно добавить информацию про то, как запустить проект, тесты или линтеры, что значительно упростит порог входа новым разработчикам.
Нужно создать issues на GitHub с подробным описанием задачи, которую вы хотите решить с помощью новых контрибьютеров. И повесить на эти issues специальные метки – good first issue и help wanted. Это поможет новым разработчикам находить задачи, которые можно брать в работу. Например, через специальные сайты: up-for-grabs.net или goodfirstissue.dev».
🔥4
Как находить время на опенсорс?
Open source-разработчик Никита Соболев:
«Я поступил радикально – отказался от основной занятости в пользу Open source. Но это не самый лучший вариант.
Заниматься Open source на выходных? Тоже не рекомендую. Лучше предпочесть другие дела – воспитывать детей, гулять с собакой, заниматься спортом. А не сидеть и тратить свое время, воспринимать Open source как работу. А вот относиться к нему, как к хобби – это нормально.
Помните, не стоит тратить на опенсорс много времени до тех пор, пока он не станет «самодостаточным» – то есть превратится в инструмент заработка и развития».
Open source-разработчик Никита Соболев:
«Я поступил радикально – отказался от основной занятости в пользу Open source. Но это не самый лучший вариант.
Заниматься Open source на выходных? Тоже не рекомендую. Лучше предпочесть другие дела – воспитывать детей, гулять с собакой, заниматься спортом. А не сидеть и тратить свое время, воспринимать Open source как работу. А вот относиться к нему, как к хобби – это нормально.
Помните, не стоит тратить на опенсорс много времени до тех пор, пока он не станет «самодостаточным» – то есть превратится в инструмент заработка и развития».
🔥3
Помогает ли Open Source найти работу?
Open source-разработчик Михаил Грачев:
«Считаю, что open source-проекты могут помочь в поиске работы. Как и активный профиль на GitHub, кстати. Многие HR-специалисты уже давно используют GitHub, как площадку для поиска новых разработчиков. Готовые open source-проекты часто помогают избежать выполнения тестовых заданий при устройстве на работу, так как по ним можно также определить уровень разработчика.
Есть немало компаний с развитой open source-культурой. Они выделяют силы и время на создание собственных open source-решений, дополнительно оплачивают время, которое разработчики тратят на работу в open source-проектах. Примеры таких компаний: Evrone и Evil Martians».
Open source-разработчик Никита Соболев:
«На мой взгляд, лучше подготовиться к собеседованию, чем рассчитывать на свои Open source-проекты.
Имеет ли смысл показывать эти проекты на собеседовании? Скорее всего, никакого влияния на работодателя такая презентация не окажет. У HR есть четкие протоколы и процессы, в которых Open source не фигурирует. Иногда упоминание ваших Open source-проектов может даже навредить – некоторые работодатели подумают, что «будет вместо работы своим опенсорсом заниматься».
Open source-разработчик Михаил Грачев:
«Считаю, что open source-проекты могут помочь в поиске работы. Как и активный профиль на GitHub, кстати. Многие HR-специалисты уже давно используют GitHub, как площадку для поиска новых разработчиков. Готовые open source-проекты часто помогают избежать выполнения тестовых заданий при устройстве на работу, так как по ним можно также определить уровень разработчика.
Есть немало компаний с развитой open source-культурой. Они выделяют силы и время на создание собственных open source-решений, дополнительно оплачивают время, которое разработчики тратят на работу в open source-проектах. Примеры таких компаний: Evrone и Evil Martians».
Open source-разработчик Никита Соболев:
«На мой взгляд, лучше подготовиться к собеседованию, чем рассчитывать на свои Open source-проекты.
Имеет ли смысл показывать эти проекты на собеседовании? Скорее всего, никакого влияния на работодателя такая презентация не окажет. У HR есть четкие протоколы и процессы, в которых Open source не фигурирует. Иногда упоминание ваших Open source-проектов может даже навредить – некоторые работодатели подумают, что «будет вместо работы своим опенсорсом заниматься».
🔥2👍1
Собираем merge за выходные и сегодня, 27.06
Добро пожаловать в комментарии со ссылкой :)
Пока наши инженеры оценивают новые issue, завтра появится новый пак, stay tuned.
Добро пожаловать в комментарии со ссылкой :)
Пока наши инженеры оценивают новые issue, завтра появится новый пак, stay tuned.
Как давать обратную связь?
Open source-разработчик Никита Соболев:
«Обычно обратная связь на GitHub – про баги или новые возможности.
Про баги: пишите по классическому шаблону – что происходит, чего ожидаете, какие шаги. Создаете баг и отправляете.
Про возможности. Здесь сложнее, нужно описать мотивацию: зачем это нужно, какие есть возможности сделать по-другому, какие это несет ограничения и риски. Общая мысль – хочу такую новую фичу. А можно еще звездочку поставить.
Если давать обратную связь по-другому – ее абсолютно точно воспримут как неконструктивную. Например, если написать человеку на почту, что его приложение – отстой, это так себе обратная связь.Такая манера общения многое говорит о человеке. В том числе и то, что прислушиваться к нему не стоит. Периодически такое происходит почти со всеми, но большинство мейнтейнеров такой фидбэк просто игнорируют.
Обратную связь нужно давать по этикету. Он обычно описан в файлах CONTRIBUTING.md или readme, в шаблонах GitHub: как создавать issues, как их оформлять, что писать, что не писать. Помните, что люди делают это бесплатно, в свое свободное время, не надо тратить это время на пустые разговоры».
Open source-разработчик Никита Соболев:
«Обычно обратная связь на GitHub – про баги или новые возможности.
Про баги: пишите по классическому шаблону – что происходит, чего ожидаете, какие шаги. Создаете баг и отправляете.
Про возможности. Здесь сложнее, нужно описать мотивацию: зачем это нужно, какие есть возможности сделать по-другому, какие это несет ограничения и риски. Общая мысль – хочу такую новую фичу. А можно еще звездочку поставить.
Если давать обратную связь по-другому – ее абсолютно точно воспримут как неконструктивную. Например, если написать человеку на почту, что его приложение – отстой, это так себе обратная связь.Такая манера общения многое говорит о человеке. В том числе и то, что прислушиваться к нему не стоит. Периодически такое происходит почти со всеми, но большинство мейнтейнеров такой фидбэк просто игнорируют.
Обратную связь нужно давать по этикету. Он обычно описан в файлах CONTRIBUTING.md или readme, в шаблонах GitHub: как создавать issues, как их оформлять, что писать, что не писать. Помните, что люди делают это бесплатно, в свое свободное время, не надо тратить это время на пустые разговоры».
Как отличить полумертвый проект?
Open source-разработчик Никита Соболев:
«Проекты бывают разные и состояние их зависит от кучи факторов.
Есть проекты, в которых все готово. Их как раз можно назвать мертвыми – это законченные проекты, у меня таких штук пять есть. Если мне напишут про их доработку – я, скорее всего, это проигнорирую. И не потому, что проект мертвый. А потому, что проект закончен и я не считаю нужным в него что-то добавлять. Если какой-то баг – другое дело. Но обычно в таких проектах нет багов, все давно отлажено, ими активно пользуются, и они решают свои задачи.
Нужно уметь отличать полумертвые проекты и тупиковые ветки. А есть проекты, которые сейчас никто не развивает, но они актуальны и сообщество хочет, чтобы они были активнее.
Есть, например, какой-то компонент для React, которым активно пользуются. Но автор больше не занимается Open Source, а рыбачит на природе. Жмете кнопочку Project pulse на GitHub, смотрите на активность. Здесь можно понять, что мейнтейнер забросил проект.
Можно написать этому человеку письмо. Мол, спасибо за шикарный проект, я хочу его развивать, вот моя ветка, в которой я много всего сделал, назначьте меня соавтором и я буду вносить эти изменения. Часто люди говорят «да, давай, мне нравится направление развития». или они говорят «да мне уже пофиг, я этим сто лет не занимаюсь, забирай». Смена главного мейнтейнера – нормальная ситуация.
Если человек не ответит, а вам очень хочется его заполучить – можно форкнуть проект, назвать «Мой проект v2» и заниматься развитием форка. Желательно, конечно, развивать старый проект, но если совсем никак – то только форк».
Open source-разработчик Никита Соболев:
«Проекты бывают разные и состояние их зависит от кучи факторов.
Есть проекты, в которых все готово. Их как раз можно назвать мертвыми – это законченные проекты, у меня таких штук пять есть. Если мне напишут про их доработку – я, скорее всего, это проигнорирую. И не потому, что проект мертвый. А потому, что проект закончен и я не считаю нужным в него что-то добавлять. Если какой-то баг – другое дело. Но обычно в таких проектах нет багов, все давно отлажено, ими активно пользуются, и они решают свои задачи.
Нужно уметь отличать полумертвые проекты и тупиковые ветки. А есть проекты, которые сейчас никто не развивает, но они актуальны и сообщество хочет, чтобы они были активнее.
Есть, например, какой-то компонент для React, которым активно пользуются. Но автор больше не занимается Open Source, а рыбачит на природе. Жмете кнопочку Project pulse на GitHub, смотрите на активность. Здесь можно понять, что мейнтейнер забросил проект.
Можно написать этому человеку письмо. Мол, спасибо за шикарный проект, я хочу его развивать, вот моя ветка, в которой я много всего сделал, назначьте меня соавтором и я буду вносить эти изменения. Часто люди говорят «да, давай, мне нравится направление развития». или они говорят «да мне уже пофиг, я этим сто лет не занимаюсь, забирай». Смена главного мейнтейнера – нормальная ситуация.
Если человек не ответит, а вам очень хочется его заполучить – можно форкнуть проект, назвать «Мой проект v2» и заниматься развитием форка. Желательно, конечно, развивать старый проект, но если совсем никак – то только форк».