Слияние кода завершено, страница обновится автоматически
Вклад в проект Aurora
Хотите поработать над проектом Aurora? Отлично! Эта страница содержит информацию об отчётах о проблемах, а также некоторые советы и рекомендации, полезные для опытных участников проектов с открытым исходным кодом. Наконец, перед тем как начать участвовать, обязательно прочитайте наши правила сообщества.
Разработчики Aurora серьёзно относятся к безопасности. Если вы обнаружите проблему безопасности, немедленно сообщите о ней!
Пожалуйста, НЕ создавайте публичный отчёт, вместо этого отправьте свой отчёт конфиденциально на xuri.me.
Отчёты о безопасности очень ценятся, и мы публично поблагодарим вас за них. В настоящее время мы не предлагаем программу вознаграждений за обнаружение проблем безопасности, но не исключаем её в будущем.
Отличный способ внести вклад в проект — отправить подробный отчёт при возникновении проблемы. Мы всегда ценим хорошо написанные и подробные отчёты об ошибках и будем благодарны вам за это!
Прежде чем отправлять отчёт, проверьте, что наша база данных проблем уже не включает эту проблему или предложение. Если вы найдёте совпадение, вы можете использовать кнопку «Подписаться», чтобы получать уведомления об обновлениях. Не оставляйте случайные комментарии «+1» или «У меня тоже есть эта проблема», так как они только засоряют обсуждение и не помогают решить проблему. Однако, если у вас есть способы воспроизвести проблему или дополнительная информация, которая может помочь решить проблему, пожалуйста, оставьте комментарий.
При сообщении о проблемах всегда включайте вывод команды go env.
Также включите шаги, необходимые для воспроизведения проблемы, если это возможно и применимо. Эта информация поможет нам быстрее рассмотреть и исправить вашу проблему. При отправке длинных файлов журналов рассмотрите возможность публикации их в виде гиста (https://gist.github.com). Не забудьте удалить конфиденциальные данные из ваших файлов журналов перед публикацией (вы можете заменить эти части на «ОТРЕДАКТИРОВАНО»).
Этот раздел даёт опытным участникам несколько советов и рекомендаций.
Не уверены, стоит ли отправлять запрос на включение из-за опечатки? Нашли ошибку и знаете, как её исправить? Сделайте это! Мы будем признательны. Любое существенное улучшение должно быть задокументировано как проблема GitHub, прежде чем кто-либо начнёт работать над ним.
Мы всегда рады получать запросы на включение. Мы делаем всё возможное, чтобы обработать их быстро. Если ваш запрос на включение не будет принят с первой попытки, не расстраивайтесь!
Вы можете предложить новые дизайны существующих функций Aurora. Вы также можете разработать совершенно новые функции. Мы действительно ценим участников, которые хотят реорганизовать или иным образом очистить наш проект.
Мы стараемся поддерживать Aurora компактной и сфокусированной. Aurora не может делать всё для всех. Это означает, что мы можем отказаться от включения новой функции. Однако может быть способ реализовать эту функцию поверх Aurora.
Форкните репозиторий и внесите изменения в своём форке в функциональной ветке:
— Если это ветка исправления ошибок, назовите её 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 в коммитах. Закрыть вопрос.
Вопросы закрываются автоматически при слиянии.
Пожалуйста, ознакомьтесь с разделом Стиль кодирования для получения дополнительных рекомендаций.
Для подтверждения принятия кода в процессе проверки разработчики Aurora используют комментарий LGTM (Looks Good To Me).
Подписание представляет собой простую строку в конце пояснения к патчу. Ваша подпись подтверждает, что вы написали патч или иным образом имеете право передать его как патч с открытым исходным кодом. Правила довольно просты: если вы можете подтвердить следующее (с сайта developercertificate.org):
Сертификат разработчика версии 1.1
Всем разрешается копировать и распространять дословные копии этого лицензионного документа, но изменение его запрещено.
Сертификат разработчика версии 1.1
Внося вклад в этот проект, я подтверждаю, что:
(a) Вклад полностью или частично создан мной, и у меня есть право представить его под открытой лицензией, указанной в файле; или
(b) Вклад основан на предыдущей работе, которая, насколько мне известно, защищена соответствующей лицензией с открытым исходным кодом, и у меня есть право в соответствии с этой лицензией представить эту работу с изменениями, созданными полностью или частично мной, под той же лицензией с открытым исходным кодом (если только мне не разрешено представлять её по другой лицензии), как указано в файле; или
(c) Вклад был предоставлен мне непосредственно другим лицом, которое подтвердило пункты (а), (b) или (c), и я не вносил в него изменений.
(d) Я понимаю и соглашаюсь с тем, что этот проект и вклад являются публичными, и что запись о вкладе (включая всю личную информацию, которую я предоставляю вместе с ним, включая мою подпись) ведётся бессрочно и может быть распространена в соответствии с этим проектом или соответствующими лицензиями с открытым исходным кодом.
Затем вы просто добавляете строку к каждому сообщению git commit:
Signed-off-by: Ri Xu https://xuri.me
Используйте своё настоящее имя (извините, никаких псевдонимов или анонимных вкладов).
Если вы установите свои git-конфигурации user.name и user.email, вы сможете подписывать коммиты автоматически с помощью команды git commit -s.
Во-первых, все сопровождающие имеют три качества:
Сопровождающих часто недооценивают, потому что их работу труднее оценить. Легко оценить действительно крутую и технически продвинутую функцию. Труднее оценить отсутствие ошибок, медленное, но устойчивое улучшение стабильности или надёжность процесса выпуска. Но именно эти вещи отличают хороший проект от отличного.
Не забывайте: быть сопровождающим — это инвестиция времени. Убедитесь, что у вас будет время, чтобы быть доступным. Вам не нужно быть сопровождающим, чтобы внести свой вклад в проект!
Если вы хотите стать сопровождающим, свяжитесь с xuri.me и расскажите о себе.
Мы хотим, чтобы сообщество было потрясающим, растущим и основанным на сотрудничестве. Нам нужна ваша помощь, чтобы сохранить его таким. Чтобы помочь в этом, мы разработали несколько общих рекомендаций для сообщества в целом:
Будьте вежливы: будьте вежливы, уважительны и вежливы по отношению к другим членам сообщества: региональное, расовое, гендерное или другое насилие недопустимо. Нам нравятся хорошие люди гораздо больше, чем плохие!
Поощряйте разнообразие и участие: сделайте так, чтобы каждый член нашего сообщества чувствовал себя желанным гостем, независимо от его происхождения и степени его вклада, и делайте всё возможное, чтобы поощрять участие в нашем сообществе.
Соблюдайте закон: в основном, не втягивайте нас в неприятности. Делитесь только контентом, который вам принадлежит, не делитесь личной или конфиденциальной информацией и не... Нарушения правил — метод трёх предупреждений
Цель этого раздела не в том, чтобы найти возможности наказать людей, но нам нужен справедливый способ иметь дело с людьми, которые делают наше сообщество хуже.
Примечания:
Если явно не указано иное, мы следуем всем правилам кодирования сообщества Go. Хотя некоторые из этих стандартов могут показаться произвольными, они каким-то образом приводят к надёжной и согласованной кодовой базе.
Возможно, кодовая база в настоящее время не соответствует этим правилам. Мы не ищем массивный PR, который это исправит, поскольку это противоречит духу правил. Все новые вклады должны прилагать максимум усилий для очистки и улучшения кодовой базы. Очевидно, применяйте своё лучшее суждение. Помните, цель здесь состоит в том, чтобы сделать кодовую базу более удобной для навигации и понимания людьми. Всегда имейте это в виду, когда побуждаете других соблюдать правила.
Правила:
gofmt -s.golint.noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo. На практике короткие методы будут иметь короткие имена переменных, а глобальные переменные будут иметь более длинные имена.go test и снаружи.Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )