Pivot_Pointer, я не могу назвать себя опытным бойцом опенсорсного фронта, но могу кратко рассказать, как начал я.
Изначально я решил попробовать около года назад, главным образом преследуя 2 цели - добавить строчку в резюме перед поиском работы и для более близкого знакомства с git. Оба пункта довольно спорные с точки зрения привлекательности для работодателей, но это не суть как важно.
Я решил пошерстить гитхаб и поискать что-то интересное. И вот здесь могу дать несколько советов.
1. Не стоит лезть в известные проекты. В первую очередь потому, что чем больше кода - тем труднее понять его человеку с улицы, что повышает порог вхождения. Не говоря уже о том, что какие-то нетрудные задачи выполняются довольно быстро и есть достаточно приличный шанс того, что пока вы будете разбираться в проблеме, кто-то уже все сделает и вы потратите время впустую. Бонусом может быть достаточно непростая установка окружения и все желание заниматься чем-то отпадет еще до чтения кода.
2. В идеале лучше взять какой-то тул/библиотеку, с которым вы работали и имеете примерное представление о функционале.
3. В списке задач в некоторых проектах на различные задачи навешиваются ярлыки типа "good first issue" или "low-hanging fruit". Так помечают какие-то нетрудные вещи, которые подходят для начинающих коммитеров. Ну и обязательно проверить дискуссию на предмет того, не взял ли кто-то эту проблему на себя.
4. Участие в опенсорсе != написание кода. Это также и тестирование, предложения по улучшению и т.д., включая правки в документации.
Если вы нашли хорошую проблему над которой можно начать работу, то надо сперва написать, что вы начали над ней работать (необязательный пункт, но где-то может быть очень полезен).
Установить окружение и попытаться запустить все у себя локально безо всяких своих правок.
Начать работу над новыми фичами.
Обязательно запустить билд у себя локально, чтобы удостовериться что все собирается без проблем и тесты проходят. Обычно в проектах используется тул под названием чекстайл, который проверяет код на соответствие принятому в проекте стилю кода. Всегда лучше заметить ошибку на ранней стадии, чем после создания пулл-реквеста увидеть свалившийся билд.
Если все ок, то ветка с изменениями пушится на гитхаб. После чего вы создаете пулл-реквест. Пулл реквест это запрос на добавление изменений в вашей ветке в основную ветку проекта (называется мастер веткой). Количество коммитов лучше делать минимальным, в идеале всего один.
Ну и напоследок кратко про то, где участвовал я.
1. Добавил несколько новых рефакторингов в эклипсовскиq
плагин для автоматического рефакторинга. Я его использовал при работе в Т-системс и пробовал на заре карьеры написать свой плагин для перевода текста, поэтому поковыряться в нем было интересно. Также пофиксил парочку багов, всего добавил чуть более 2к строк кода.
2. Пытался добавить новую проверку в чекстайл, однако там стали требовать выкладывать какие-то диаграммы на сайт, который надо предварительно создать на гитхабовском домене. У меня тулза для этого выдавала какие-то ошибки, в итоге я забил на это. Потом какой-то другой чувак подхватил это и теперь там есть предложенная мной проверка.
3. Сейчас мы на проекте использовали библиотеку для операций с json. Полез смотреть код и предложил решение проблемы в одном из обсуждений. Хотел даже написать код для этого сам, однако уже на следующий день после моего поста какой-то чувак уже все это сделал.
4. Сайт, на котором я играю в шахматы -
lichess.org является опенсорсным и лежит на гитхабе. В нем ковыряться сложнее из-за того, что написан он на Scala с использованием Akka и других вещей, с которыми я не знаком. Все хочу найти время и терпения сесть и основательно углубиться в код и попробовать запустить все локально. Пока что я ограничился помощью с переводом сайта/приложения на русский язык.
Для души коммичу в опенсорс :) А если речь про другие языки программирования, то я разве что скалой балуюсь немного.
А вообще в целом мне нравится ковыряться в джавовских потрохах.
Еще был анонс о том, что набирают у нас людей для обучения data science.