Предыдущий инцидент со злоупотреблением Issue отечественными пользователями постепенно утих.После бури у нас остались некоторые мысли: как мы можем участвовать в таком глобальном сообществе с открытым исходным кодом и отдавать ему?
Как человек, много лет скитающийся по GitHub, хочу рассказать о своем опыте и опыте, надеясь помочь вам не наступить лишний раз на яму.
【В качестве туриста】
При посещении репозитория вы столкнетесь с тремя кнопками: Watch (подписаться) / Star (звездочка) / Fork (форк).
Наблюдать означает, что вы заинтересованы в событиях, происходящих в этом репозитории, таких как появление новых проблем и т. д. Когда эти события происходят, GitHub автоматически отправит вам уведомление на страницу и отправит электронное письмо на ваш зарегистрированный адрес электронной почты.Конечно, вы также можете отключить эти уведомления в интерфейсе настроек уведомлений. Когда вы просматриваете много складов, письма с уведомлениями могут переполнить ваш почтовый ящик.В это время, помимо установки правил в вашем собственном почтовом ящике, вы также можете отключить уведомления здесь.
Звездочка означает специально отметить этот репозиторий, что соответствует звездочке в почтовом ящике. Строго говоря, это просто краткая аннотация, которую вам лично нужно часто посещать, чтобы вы могли быстро найти эти элементы через страницу «Ваши звезды» (например, элементы, в которых я отметился). Это часто используется как голосование в поддержку, и это официально пропагандируется, но я редко это делаю.
Форк имеет две цели: во-первых, вы должны участвовать в нем и отправлять код для него, что я подробно расскажу в разделе [Как участник] позже; во-вторых, этот репозиторий может быть удален первоначальным автором, так Форк выходит, так что даже если автор его удалит, у меня все равно есть снимок версии Форка на тот момент времени. Однако следует отметить, что версия, выпущенная Fork, не будет автоматически обновляться с исходным репозиторием. В идеале последний случай следует считать неправомерным использованием, потому что первоначальный автор кода с открытым исходным кодом не должен быть удален, но он был удален. Поэтому иногда я рассматриваю акт разветвления, но не отправку PR, как вотум недоверия автору библиотеки. Конечно, большинство авторов репозиториев так не думают.
【Как участник】
Существует две формы вклада: отправка вопроса и отправка запроса на вытягивание, обе из которых имеют некоторые общие требования, в том числе:
- Внимательно прочитайте и следуйте шаблону вопроса / шаблону PR, предоставленному другой стороной.
- Своевременно реагируйте, когда у другой стороны есть ответ, вы должны дать достаточно четкий ответ как можно скорее. Если вы чувствуете, что ответ другой стороны решил вашу проблему, или это действительно не проблема, вовремя закройте его и не ждите, пока это сделает автор.
- Большинство репозиториев упоминаются на английском языке, за исключением репозиториев, предназначенных для китайских пользователей. На самом деле это не так сложно, как представлялось. Google Translate теперь очень мощный, и на https://translate.google.cn можно зайти, не переворачивая стену.Просто напишите по-китайски, потом переведите на английский, а потом Just fix английский перевод.
Далее я подробно расскажу о них.
Поднятие проблемы означает постановку вопроса, который можно разделить на два типа: поднятие ошибки и поднятие требования (запрос функции/предложение).
Основное требование для подачи сообщения об ошибке — идентифицировать ее как проблему и сделать ее ясной.
Авторы открытого исходного кода заняты, и у большинства из них нет времени на общение с вами, и они не хотят тратить долгие часы только на то, чтобы задавать вопросы. Автор будет очень разочарован - если не возмутится, если после долгих попыток окажется, что это вообще не проблема.
Итак, если вы обнаружите проблему, сначала скажите себе, что это «подозрительная проблема», а затем попытайтесь воспроизвести ее с другими проектами или даже с другими средами, и вы должны записать эти процессы. После того, как вы подтвердите, что это действительно проблема, откройте вопрос и включите свои попытки и их результаты, а также результаты, которые вы ожидаете. При этом проекты, созданные при этих попытках, лучше всего выкладывать в личное пространство на GitHub, чтобы автор мог напрямую воспроизвести вашу проблему без пересборки окружения. Этой работе очень важно, чтобы автор обратил внимание на вашу проблему и решил ее.
Обратите внимание: если вы просто не знаете, как им пользоваться, вместо того, чтобы найти ошибку в самом коде, пожалуйста,не хочуПодать проблему. Поскольку проблемы не являются прямым поездом, чтобы спросить автора, вы должны пойти на профессиональный Q & A, как Stackoverflow, чтобы задать вопросы. Многие авторы репозиториев с открытым исходным кодом также активны на сайте Q & A, такие как Stackoverflow, поэтому не беспокойтесь о получении профессионального ответа.
Основное требование повышения спроса — уметь спокойно принимать отказ других.
Каждое программное обеспечение с открытым исходным кодом имеет свой собственный план развития.Для более популярного проекта хорошо, что ваш запрос функции будет принят с вероятностью 1%. Что вам нужно сделать, так это как можно яснее объяснить все тонкости этого запроса в первом сообщении. Если вы обнаружите, что автор неправильно понял ваши потребности, вы можете ответить на сообщение, чтобы объяснить, но не грубите и высокомерный. Если вы считаете, что отказ оправдан, поблагодарите и закройте свой запрос функции.
Отправка запроса на слияние (сокращенно PR) — это приложение для слияния кода с основной библиотекой, что является высокотехнологичной работой.
Предпосылка отправки PR состоит в том, чтобы сначала разветвить репозиторий другой стороны, а не клонировать его и загрузить в свой собственный репозиторий.В этом случае GitHub не будет знать, что две библиотеки имеют одно и то же происхождение.
После форка у вас на личном складе появится филиал-склад.Вы можете отправить код на этот филиал-склад.После того, как вы почувствуете, что достигли заданной цели PR, нажмите его и вернитесь на страницу GitHub, чтобы инициировать PR (GitHub выдаст PR на странице GitHub. Страница активно предлагает вам отправить PR, просто следуйте).
Основным требованием при подаче PR является соответствие стандартам качества кода другой стороны. Если покрытие модульным тестом репозитория другой стороны высокое, вам также следует убедиться, что код, который вы отправляете, имеет достаточное тестовое покрытие. Если другая сторона просит использовать встроенные комментарии в коде для создания документации, вы также должны написать соответствующие комментарии к документации. Если у другой стороны есть строгие требования к формату кода, вам тоже следует им следовать. Конечно, лучшие репозитории с открытым исходным кодом обычно имеют соответствующие инструменты для проверки, и если они не сработают, они будут помечены.
Если ваш PR устарел, у вас есть два варианта: если новая версия другой стороны решила эту проблему, пожалуйста, закройте свою собственную; если у вас все еще есть эта проблема, перебазируйте свой репозиторий локально на другую сторону Последняя версия, разрешите конфликт, а затем отправить его в свой собственный репозиторий.После того, как вы отправите его, поток PR другой стороны автоматически отразит эти изменения, без необходимости закрывать PR и запускать его снова (я упомянул об этом, когда упоминал первый PR) ..сделал такую глупость).
Если другая сторона отвечает на ваш PR и просит вас внести некоторые изменения, если вы считаете это разумным, вы можете изменить его соответствующим образом.Если вы считаете, что это неразумно, вы можете продолжить обсуждение и уточнить свою точку зрения. Но обычно другая сторона более опытна, чем вы, и может иметь более высокий уровень, пожалуйста, подумайте хорошенько над ее рациональностью, прежде чем отвечать.
【Как автор】
Как автор репозитория, первое, что нужно сделать, это включить в репозиторий явный файл LICENSE.
Обычно репозитории кода выбирают более открытые протоколы, такие как MIT.Если вы фанатик открытого исходного кода, вы также можете выбрать более радикальные протоколы, такие как GPL, но следует отметить, что в принципе GitHub не позволяет коду в открытых репозиториях используйте протокол частных/чистых коммерческих лицензий. Я не анализировал тщательно, разрешено ли это юридически, но, по крайней мере, не разрешено морально. В то же время существующий код с открытым исходным кодом с использованием протоколов с открытым исходным кодом, таких как MIT, по закону не может быть закрытым исходным кодом, то есть он не может иметь обратную силу. Например, если ваш 1.0 находится под лицензией MIT, то другие всегда могут использовать версию кода 1.0 согласно MIT, но вы можете изменить 2.0 на другой протокол или даже отказаться от открытого исходного кода (GPL является исключением, как только он открытый, он никогда не закроется). Но даже в этом случае, согласно MIT, другие могут свободно использовать код 1.0.
Склады на основе документов обычно выбирают протоколы CC или CC-BY-NC. Разница между ними заключается в том, что первый разрешает коммерческое использование, а второй не разрешает коммерческое использование или требует отдельной авторизации для коммерческого использования.
Во-вторых, предоставьте вспомогательные документы, такие как руководство по вкладу CONTRIBUTING.md, чтобы помочь разработчикам, как внести свой вклад. Если вы хотите предоставить шаблоны для проблем и PR, вы можете включить.github/ISSUE_TEMPLATE.mdа также.github/PULL_REQUEST_TEMPLATE.mdфайл, так что когда другие захотят участвовать, они сначала увидят содержимое этого шаблона, что предотвратит их неправильное использование.
И, наконец, если это было разрекламировано или привлекло много внимания, не сдавайтесь легко, а придерживайтесь этого.Если вы не можете придерживаться этого, пожалуйста, передайте это кому-то другому. Ответственность за это лежит на авторе открытого исходного кода. Конечно, экспериментальные проекты, которые не продвигались, не должны подпадать под это ограничение. Однако, за исключением случаев крайней необходимости (например, по соображениям безопасности), не удаляйте репозиторий с открытым исходным кодом, это грубо, при необходимости вы можете удалить его и написать README, чтобы сообщить читателям, где найти перемещенную версию.
【Заключение】
Помните: открытый исходный код — это убеждение, а не ступенька к заявлению о приеме на работу или инструмент для получения KPI. Это не невозможно сделать, но, пожалуйста, не забывайте о своем первоначальном намерении. Как только у вас будут условия, вы должны вернуть сообществу открытого исходного кода в различных формах. Это основа процветания сообщества открытого исходного кода.