Руководство по вкладу сообщества с открытым исходным кодом с нуля

[Участник сообщества Open Source] Звучит так, как будто это звание зарезервировано для лучших разработчиков, но действительно ли оно настолько недосягаемо? Следующий обмен направлен на то, чтобы демистифицировать его и помочь заинтересованным студентам легче участвовать в общественных проектах.

Прежде всего необходимо уточнить, что эта статьяавтор самНе первоначальный автор проекта в сообществе высокого уровня, а просто участник из 10 лучших участников проекта с 5k+ звездами, более 100 участников (для справки, у Vue менее 150 участников) и«Какой опыт сопровождения крупного проекта с открытым исходным кодом»По сравнению с сияющими звездами в этом вопросе это лишь маленькое прозрачное существование. Однако, поскольку у меня есть только один год опыта, я очень похож на новых студентов, которые только начали во многих аспектах, поэтому я считаю, что мой личный опыт может иметь определенную справочную ценность, поэтому я сделал здесь некоторые выводы. Если в тексте есть что-то неуместное, пожалуйста, далао, исправьте это.

Следующее содержание в основном разделено на две части:

• Начало работы и дополнительные возможности, чтобы представить, как вы можете участвовать в жизни сообщества, если вы ничего не знаете о программировании. И как сотрудничать в проектах с открытым исходным кодом через вопросы и PR после того, как у вас есть условия для участия.
• Советы и резюме, в котором рассказывается о некоторых технических деталях и о том, как начать работу с Github.деловой ударнавыки общения.

Начало

Существует три основных способа участия в проектах с открытым исходным кодом, от простого к сложному:

• Перевод документов
• сообщить об ошибке
• Отправить код

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

Взяв в качестве примера документ MDN, поддерживаемый Mozilla, многие студенты могут не знать, что документ MDN — это то же самое, что и Википедия.редактируется всеми пользователями. Например, документ MDN, в котором представлены методы позиционирования CSS, верхняя часть страницы выглядит так:

уведомлениеLanguagesа такжеEditВсе же? ты сможешьLanguagesВыберите здесь нужный язык или добавьте перевод для нового языка. Если есть перевод, вы можете напрямую нажатьEditредактировать!

В переводе текстовый редактор Mozilla можно разделить на две части, которыми вы можете управлять напрямую:

Теперь просто нажмите «Сохранить», и вы будете указаны в качестве соавторов на этой странице! Ваши изменения также будут сохранены в истории документа, поэтому проверьте их перед фиксацией. Кроме того, не обязательно заполнять весь документ за один раз, если вы готовы сохранить половину написанного, вы можете нажать кнопку внизу страницы.本地化进行中опция, чтобы вы могли добавить знак «перевод в процессе» на странице просмотра.

Кажется, мы не написали ни одной строчки кода в этом процессе, так какой в ​​этом смысл? Мое личное мнение, что перевод документации — хорошее место для начала, потому что он может:

• Помочь вам лучше понять структуру технических документов на английском языке и заложить прочную основу для будущего общения с другими разработчиками. Мы также упомянем позже, что часто вам нужно написать более одной или двух строк документации для одной или двух строк кода.
• Отлично тренируйте свои навыки письма. На начальном этапе вы можете писать технические документы, которые будут довольно неточными и непонятными, но после того, как вы ознакомитесь с ними, вы добьетесь больших успехов.
• Быстро получайте отзывы о своих вкладах. Вес MDN в Google не мал, найти переведенный контент на первой странице через Google — это большое достижение.
• Улучшить собственное понимание содержания документации. Взяв в качестве примера самого автора, при понимании области редактирования форматированного текста первое, что нужно сделать, это начать с обработкиРедактор форматированного текста в MozillaДокументация начинается с перевода, и основные концепции в этой области понятны.

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

Передовой

Если вы просто переводите документы, вы можете вскоре достичь стадии «усталости писать», и тогда вы, возможно, захотите взглянуть на более широкий мир. Найдите активный проект на Github, чтобы начать! Для проектов с открытым исходным кодом, поддерживаемых на Github, основные методы участия включают выпуск и PR:

Issue

В средних и крупных проектах с открытым исходным кодом Issue в основном используется для:

• Сообщайте об ошибках и задавайте вопросы
• Предлагайте и обсуждайте новые функции
• Установите цели Todo

Следует отметить, что у многих проектов есть свои форумы Discuz или группы в Slack, а некоторые вопросы новичков вроде [Почему установка не удалась] можно поискать в существующем Issue, а затем поднять на форуме и в чате. Если вы поднимаете вопрос по своему желанию, вы, вероятно, получитеDuplicate of #xxxЗатем ответ был отключен. Для новых студентов очень хорошим справочником являетсяИскусство спрашивать: как быстро получить ответы.

Если вы подняли проблему для проекта, ваша карта вклада Github будет зеленой в этот день, и вы также можете закрепить проект на своей личной домашней странице! Тоже вроде бы код писать не надо, это не сложно. Однако простое поднятие проблемы не сделает вас фигурирующим в списке участников проекта.Если вы действительно хотите [внести свой вклад] в код, PR обязателен.

PR

Запрос на слияние, как следует из названия, означает, что вы просите других вытащить ваш код. Это очень похоже на рабочий процесс с открытым исходным кодом: разработчики разветвляют свой собственный репозиторий, фиксируют код в своей собственной ветке, а затемПопросите сопровождающего объединить свои изменения в. Вообще говоря, PR должен хорошо делать только одну вещь, и его роль не более чем одна из следующих:

• исправлять ошибки
• Внедряйте новые функции
• Оптимизация производительности
• Регулярные обновления (такие как документация, версии зависимостей и т. д.)

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

Пока PR отправлен, график вклада Github за день будет зеленым, независимо от того, объединен он или нет, а когда PR объединен в ствол, график вклада дня также будет окрашен в зеленый цвет. Предположим, вы нашли небольшой баг, который можно исправить всего в одной строке, тогда весь процесс происходит так:

1. Поднять вопрос, внести вклад +1
2. Сделать пиар, внести +1
3. Ответить на отзыв сопровождающего, добавив +1
4. PR одобрен, вклад +1

Таким образом, даже если будет отправлена ​​только одна строка кода, достаточно нажать на зеленую карту вклада максимум четыре дня. Кроме того, по мере того, как сопровождающие просматривают или сливаются с вашим PR, их вклад соответственно увеличивается. Думая об этом таким образом, количество тысяч вкладов, сделанных участниками крупномасштабных проектов в год, не является чем-то, на что можно только смотреть.

Навык

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

Проблемно-ориентированное чтение исходного кода

Когда необходимо представить исправления ошибок, новые функции или оптимизацию производительности, прочитать исходный код фреймворка практически невозможно. Конечно, мы часто видим много статей [разбор исходного кода] в техническом сообществе (в основном Redux/Vue/Koa в ближайшем будущем). Намерения автора при написании этих статей, безусловно, благие, но, к сожалению, многие из этих статей относительно плохо читаются, иАвторы большинства этих статей не являются участниками этих фреймворков..

Мы слишком импульсивны? Мы могли бы также рассмотреть мотивацию, зачем нам читать исходный код? Это для решения практических задач или просто для того, чтобы вести блог, чтобы показать свой технический уровень? Если вы просто вставите скриншоты кода, которые выглядят высокими и высокими, а затем переведете комментарии на китайский язык, чем такая статья может помочь читателям и сообществу? По сравнению с [я прочитал исходный код этого фреймворка] и [я исправил ошибки этого фреймворка], какой из них вносит больший вклад?

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

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

Однако [как читать исходный код] выходит за рамки этой статьи. Нам достаточно остановиться здесь.

Дружелюбныйотсосать друг другуоценивать

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

Здесь мы разделяем только один момент:Как быть добрее к чужой работе. В китайском сообществе, помимо [обращающейся стороны], часто можно увидеть [троллей], напрямую нападающих на качество проекта или надевающих на людей шляпу [плагиата]. Однако жаловаться на чужой код совершенно необходимо. Как более эвфемистично указывать на проблемы с PR или отвечать на мнения в Вопросах при общении в сообществе?

Интересно, что эти слова редко можно увидеть на Github:

bad wrong dirty terrible ***...

Более просто не видеть такого утверждения:

I think this code is bad and do things wrong!

и прямой код косыbadС другой стороны, вы можете сказать:

• Express API, так сказать, громоздкий и сложный в использованииheavy to work with
• Структура модуля выражения, так сказать, не очень хороша.not intuitive
• Можно сказать, что метод обработки выражений слишком грубый.overkill
• В логике выражения могут быть лазейки, так сказатьleaky
• Есть слишком много вещей, которые нужно представить, чтобы выразить, так сказатьaggressive
• ...

а такжеI thinkЭто кажется очень произвольным, это может быть так:

• мощныйIMOилиIMHO,Прямо сейчасIn my (humble) opinion
• добавить одинNot sure, maybe missing something
• использоватьTo my knowledgeилиFor me

И, по просьбе других участников ОБЗОР или слияние, помнитеWould you pleaseа такжеCould you pleaseТоже очень хорошо. о да, не забудьThanksкакие.

Короче говоря, очень интересно изучить подходящую коммуникативную лексику, но требования к английскому языку не высоки.Чтобы использовать вышеприведенное введение, на самом деле, пока достаточно уровня английского неполной средней школы... Я считаю, что заинтересован студенты могут резюмировать больше [Диалог с открытым исходным кодом] ]😅 Кроме того, Кодекс поведения многих проектов также стоит прочитать.

эффективное общение

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

допрос опровержение

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

Например, когда считается, что у PR есть непродуманная пограничная ситуация, как рецензенту, это лучше, чем прямо судитьYou are missing XXX,КомментарийHow is it when XXXГениально [отбрасывая банку назад], я могу вежливо попросить отправителя более подробно объяснить суждение об особой ситуации или изменить код, вместо того, чтобы прямо [говорить до смерти].

Аналогичным образом, если обходной путь не одобрен, ответьтеI don't know what you mean at...Затем дождитесь объяснений другой стороны, эффект лучше, чем прямое высказывание.This is wrongБыть лучше.

Обратите внимание на описание

При отправке задачи разные методы описания могут иметь разные приоритеты и разные результаты обработки. Вот недавний пример:

В проекте, в котором мы участвовали, была проблема, описывающая [проблема с производительностью], и содержание было приблизительно [скорость очень низкая, когда входное содержимое велико]. Этот вопрос висит уже неделю-две и никто им не занимается. И я обнаружил конкретный сценарий после отладки, когда повторные перерисовки приводили к сбою страницы. После отправки проблемы с заголовком [Page Infinite Loop] автор устранил проблему в тот же день, и проблема с производительностью также была решена.

Шаблоны и инструменты

На самом деле, многие из вышеперечисленных материалов имеют фиксированные процедуры, которым нужно следовать. Например, Issue и PR имеют относительно фиксированные шаблоны, чтобы помочь участникам повысить эффективность коммуникации.

Для Выпуска общим шаблоном является примерно такой силлогизм:

1. Bug or Feature?
2. Current Behavior?
3. Expected Behavior?

Для PR это не обязательно требуется для длинного рассказа Формальная структура примерно такова:

1. This Closes #xxx
2. Current Behavior / Reason
3. Solution

При отправке вопроса важно предоставить воспроизводимые примеры, шаги или GIF-файлы. Тогда мы можем использоватьJSFiddleПредоставляет простой пример воспроизведения, также доступный на MacGiphy CaptureЭтот бесплатный инструмент для записи анимированных GIF может помочь.

Наконец, при отправке Git аккуратная запись отправки также является большим плюсом.Студенты, которые заинтересованы в этом отношении, могут обратиться к предыдущим статьям автора:Улучшите качество PR с помощью git rebase.

Суммировать

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

Кстати, вот проект редактора, который мы сейчас поддерживаемSlate. Это отличная и быстрая итеративная структура форматированного текста. Она все еще находится в стадии бета-тестирования, когда радикально добавляются новые возможности и функции. Есть много возможностей внести свой вклад, а стиль и комментарии к исходному коду достаточно полны. Еще один интересный момент заключается в том, что у автора такой же дизайнерский опыт, как и у Эвана Ю (можете представить себе сцену, где группа программистов исправляет ошибки в коде, написанном UI-дизайнерами). Я также был в предыдущем блогеAmway вместо шифера, я надеюсь, что будет больше студентов, чтобы попробовать это!

Наконец, давайте процитируем принцип проекта Chrome V8 в качестве резюме этой статьи:

In short, do the right thing for the project, not the easiest thing to get code committed, and above all: use your best judgement.