Слияние кода завершено, страница обновится автоматически
Вклад в GoReporter
Хотите поработать над GoReporter? Отлично! Эта страница содержит информацию об отчётах о проблемах, а также некоторые советы и рекомендации, полезные для опытных участников проектов с открытым исходным кодом. Наконец, перед тем как начать участвовать, обязательно прочитайте наши правила сообщества.
Разработчики GoReporter серьёзно относятся к безопасности. Если вы обнаружите проблему безопасности, пожалуйста, немедленно сообщите им об этом!
Пожалуйста, НЕ создавайте публичный отчёт, вместо этого отправьте свой отчёт конфиденциально на адрес iamwgliang@email.com.
Отчёты о безопасности очень ценятся, и мы публично поблагодарим вас за них. В настоящее время мы не предлагаем программу вознаграждений за безопасность, но не исключаем её в будущем.
Отличный способ внести вклад в проект — отправить подробный отчёт при возникновении проблемы. Мы всегда ценим хорошо написанный, подробный отчёт об ошибке и будем благодарны вам за это!
Прежде чем отправлять отчёт, проверьте, что наша база данных проблем уже не включает эту проблему или предложение. Если вы найдёте совпадение, вы можете использовать кнопку «Подписаться», чтобы получать уведомления об обновлениях. Не оставляйте случайные комментарии «+1» или «У меня тоже», так как они только засоряют обсуждение и не помогают его разрешить. Однако, если у вас есть способы воспроизвести проблему или дополнительная информация, которая может помочь решить проблему, оставьте комментарий.
При сообщении о проблемах всегда включайте вывод команды go env.
Также включите шаги, необходимые для воспроизведения проблемы, если это возможно и применимо. Эта информация поможет нам быстрее рассмотреть и исправить вашу проблему. При отправке длинных файлов журналов рассмотрите возможность публикации их в виде гиста (https://gist.github.com). Не забудьте удалить конфиденциальные данные из ваших файлов журналов перед публикацией (вы можете заменить эти части на «ЗАМАСКИРОВАНО»).
Этот раздел даёт опытным участникам несколько советов и рекомендаций.
Не уверены, стоит ли эта опечатка запроса на вытягивание? Нашли ошибку и знаете, как её исправить? Сделайте это! Мы будем признательны. Любое существенное улучшение должно быть задокументировано как проблема GitHub, прежде чем кто-либо начнёт над ней работать.
Мы всегда рады получать запросы на вытягивание. Мы делаем всё возможное, чтобы обработать их быстро. Если ваш запрос на вытягивание не будет принят с первой попытки, не расстраивайтесь!
Вы можете предложить новые дизайны существующих функций GoReporter. Вы также можете разработать совершенно новые функции. Мы действительно ценим участников, которые хотят реорганизовать или иным образом очистить наш проект.
Мы стараемся поддерживать GoReporter компактным и целенаправленным. GoReporter не может делать всё для всех. Это означает, что мы можем отказаться от включения новой функции. Однако может быть способ реализовать эту функцию поверх GoReporter.
Форкните репозиторий и внесите изменения в своём форке в функциональной ветке:
— Если это ветка исправления ошибок, назовите её XXXX-что-то, где XXXX — номер проблемы. — Если это функциональная ветка, создайте проблему улучшения, чтобы объявить о своих намерениях, и назовите её XXXX-что-то, где XXXX — номер проблемы.
Проведите модульные тесты для своих изменений. У Go есть отличная встроенная тестовая среда; используйте её! Взгляните на существующие тесты для вдохновения. Перед отправкой запроса на вытягивание запустите полный тест на своей ветке.
Обновляйте документацию при создании или изменении функций. Проверьте свои изменения документации на ясность, краткость и правильность, а также на чистоту сборки документации.
Пишите чистый код. Универсально. Отформатированный код способствует лёгкости написания, чтения и сопровождения. Всегда запускайте команду gofmt -s -w file.go для каждого изменённого файла перед тем, как зафиксировать изменения. Большинство редакторов имеют плагины, которые делают это автоматически.
Описания запросов на включение (pull request) должны быть максимально ясными и включать ссылки на все проблемы, которые они решают.
Прежде чем вносить большие или важные изменения, постарайтесь скоординироваться с сопровождающими проекта перед отправкой запроса на включение. Это позволит вам избежать лишней работы, которая может быть не принята.
Большие запросы на включение, отправленные без предварительного общения, вряд ли будут успешными.
Хотя запросы на включение являются методологией отправки изменений в код, изменения с большей вероятностью будут приняты, если они сопровождаются дополнительной инженерной работой. Хотя мы не определяем это явно, большинство этих целей достигаются через общение о целях дизайна и последующих решениях. Часто помогает сначала сформулировать проблему, прежде чем представлять решения.
Как правило, лучшие методы достижения этого — отправить задачу, сформулировав проблему. Эта задача может включать формулировку проблемы и контрольный список с требованиями. Если предлагаются решения, следует перечислить и исключить альтернативы. Даже если критерии исключения решения незначительны, так и скажите.
Более крупные изменения обычно лучше работают с проектными документами. Они сосредоточены на предоставлении контекста дизайну во время создания функции и могут информировать будущие вклады в документацию.
Сообщения фиксации должны начинаться с заглавной буквы и краткого резюме, написанного в повелительном наклонении, за которым следует необязательный, более подробный пояснительный текст, отделённый от резюме пустой строкой.
Сообщения фиксации должны следовать лучшим практикам, включая объяснение контекста проблемы и того, как она была решена, включая предостережения или последующие изменения, необходимые. Они должны рассказывать историю изменения и давать читателям понимание того, что к нему привело.
На практике лучший подход к поддержанию хорошего сообщения фиксации — использовать git add -p и git commit --amend, чтобы сформулировать надёжный набор изменений. Это позволяет собирать изменение по мере поступления информации.
Если вы объединяете серию коммитов, не просто отправьте их. Перепишите сообщение фиксации, как будто серия коммитов была одним гениальным ходом.
Тем не менее, нет требования иметь один коммит для запроса на включение, пока каждый коммит рассказывает историю. Например, если есть функция, требующая пакета, может иметь смысл иметь пакет в отдельном коммите, а затем сделать последующий коммит, который его использует.
Помните, вы рассказываете часть истории с помощью сообщения фиксации. Не делайте свою главу странной.
Комментарии проверки кода могут быть добавлены к вашему запросу на включение. Обсудите, затем внесите предложенные изменения и отправьте дополнительные коммиты в свою ветку функций. Оставьте комментарий после отправки. Новые коммиты отображаются в запросе на включение автоматически, но рецензенты уведомляются только тогда, когда вы комментируете.
Запросы на включение должны быть аккуратно перебазированы поверх основной ветки без смешивания нескольких веток в PR.
Совет Git: если ваш PR больше не сливается чисто, используйте rebase master в своей ветке функций, чтобы обновить свой запрос на включение вместо merge master.
Перед тем как сделать запрос на включение, объедините свои коммиты в логические единицы работы с помощью git rebase -i и git push -f. Логическая единица работы — это согласованный набор исправлений, которые следует рассматривать вместе: например, обновление версии сторонней зависимости и использование её теперь доступной новой функции составляют две отдельные единицы работы. Реализация новой функции и вызов её в другом файле составляют одну логическую единицу работы. Подавляющее большинство представлений должно иметь один коммит, поэтому, если вы сомневаетесь: объедините до одного.
После каждого коммита убедитесь, что тест пройден. Включайте изменения документации в тот же запрос на включение, чтобы при возврате были удалены все... Следы функции или исправления.
Включайте в коммиты, закрывающие задачу, ссылку на неё вроде Closes #XXXX или Fixes #XXXX. При слиянии такие ссылки автоматически закрывают задачу.
См. раздел Стиль кодирования для дополнительных рекомендаций.
Сопровождающие GoReporter используют LGTM (Looks Good To Me) в комментариях к проверке кода, чтобы указать на принятие.
Подпись — это простая строка в конце пояснения к патчу. Ваша подпись подтверждает, что вы написали патч или иным образом имеете право передать его как патч с открытым исходным кодом. Правила довольно просты: если вы можете подтвердить следующее (с сайта developercertificate.org):
Сертификат разработчика о происхождении Версия 1.1
Авторские права (C) 2004, 2006 The Linux Foundation и её участники. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129
Каждому разрешено копировать и распространять дословные копии этого документа лицензии, но изменение запрещено.
Сертификат разработчика о происхождении 1.1
Делая вклад в этот проект, я подтверждаю, что:
(a) Вклад полностью или частично создан мной, и у меня есть право представить его под открытой лицензией, указанной в файле; или
(b) Вклад основан на предыдущей работе, которая, насколько мне известно, защищена соответствующей лицензией с открытым исходным кодом, и у меня есть право в соответствии с этой лицензией представить эту работу с изменениями, созданными полностью или частично мной, под той же лицензией с открытым исходным кодом (если только мне не разрешено представлять её по другой лицензии), как указано в файле; или
(c) Вклад был предоставлен мне непосредственно другим лицом, которое подтвердило пункты (a), (b) или (c), и я не изменял его.
(d) Я понимаю и соглашаюсь с тем, что этот проект и вклад являются публичными, и что запись о вкладе (включая всю личную информацию, которую я предоставляю вместе с ним, включая мою подпись) ведётся бессрочно и может быть распространена в соответствии с этим проектом или задействованными лицензиями с открытым исходным кодом.
Тогда просто добавляйте строку к каждому сообщению git commit: Signed-off-by: Jack Wang iamwgliang@email.com
Используйте своё настоящее имя (извините, никаких псевдонимов или анонимных вкладов).
Если вы установите свои git-конфигурации user.name и user.email, вы сможете подписать свой коммит автоматически с помощью команды git commit -s.
Во-первых, все сопровождающие имеют три вещи:
Сопровождающих часто недооценивают, потому что их работу труднее оценить. Легко оценить действительно крутую и технически продвинутую функцию. Труднее оценить отсутствие ошибок, медленное, но устойчивое улучшение стабильности или надёжность процесса выпуска. Но именно эти вещи отличают хороший проект от отличного.
Не забывайте: быть сопровождающим — это инвестиция времени. Убедитесь, что у вас будет время, чтобы быть доступным. Вам не нужно быть сопровождающим, чтобы внести свой вклад в проект!
Если хотите стать сопровождающим, свяжитесь с Джеком Вангом iamwgliang@email.com, представьтесь.
Мы хотим, чтобы сообщество было потрясающим, растущим и совместным. Нам нужна ваша помощь, чтобы сохранить его таким. Чтобы помочь в этом, мы разработали несколько общих рекомендаций для сообщества в целом:
Будьте милы: будьте вежливы, уважительны и вежливы по отношению к другим членам сообщества: региональное, расовое, гендерное или другое насилие недопустимо. Нам нравятся милые люди гораздо больше, чем злые!
Поощряйте разнообразие и участие: пусть каждый в нашем сообществе чувствует себя желанным гостем, независимо от его происхождения и степени вклада, и делайте всё возможное, чтобы поощрять участие в нашем сообществе.
Соблюдайте закон: Быть частью пакета утилит. Просто оставьте его неэкспортированным и хорошо задокументированным.
Все тесты должны запускаться с помощью команды go test, и не должно требоваться использование сторонних инструментов. Нет, нам не нужна ещё одна среда модульного тестирования. Пакеты утверждений допустимы, если они обеспечивают реальное добавочное значение.
Хотя мы называем это «правилами», на самом деле это просто рекомендации. Поскольку вы прочитали все правила, теперь вы это знаете.
Если вам трудно проникнуться идиоматикой Go, рекомендуем прочитать Effective Go. Также отличным ресурсом является Go Blog. Верить в успех Go намного проще, чем оставаться равнодушным.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )