Слияние кода завершено, страница обновится автоматически
Вклад в Excelize
Хотите поработать над Excelize? Отлично! Эта страница содержит информацию об отчётах о проблемах, а также некоторые советы и рекомендации, полезные для опытных участников проектов с открытым исходным кодом. Наконец, перед тем как начать участвовать, обязательно прочитайте наши правила сообщества.
Разработчики Excelize серьёзно относятся к безопасности. Если вы обнаружите проблему безопасности, пожалуйста, немедленно сообщите им об этом!
Пожалуйста, НЕ создавайте публичный вопрос, вместо этого отправьте свой отчёт конфиденциально на xuri.me.
Отчёты о безопасности очень ценятся, и мы публично поблагодарим вас за них. В настоящее время мы не предлагаем программу вознаграждений за безопасность, но не исключаем её в будущем.
Отличный способ внести свой вклад в проект — отправить подробный отчёт, когда вы столкнётесь с проблемой. Мы всегда ценим хорошо написанный, тщательный отчёт об ошибке и будем благодарны вам за него!
Прежде чем отправлять вопрос, проверьте, что наша база данных вопросов уже не включает эту проблему или предложение. Если вы найдёте совпадение, вы можете использовать кнопку «Подписаться», чтобы получать уведомления об обновлениях. Не оставляйте случайные комментарии «+1» или «У меня тоже есть эта проблема», так как они только загромождают обсуждение и не помогают решить его. Однако, если у вас есть способы воспроизвести проблему или дополнительная информация, которая может помочь решить проблему, оставьте комментарий.
При сообщении о проблемах всегда включайте вывод go env.
Также включите шаги, необходимые для воспроизведения проблемы, если это возможно и применимо. Эта информация поможет нам быстрее рассмотреть и исправить вашу проблему. При отправке длинных файлов журналов рассмотрите возможность публикации их в виде гиста https://gist.github.com. Не забудьте удалить конфиденциальные данные из ваших файлов журналов перед публикацией (вы можете заменить эти части на «ОТРЕДАКТИРОВАНО»).
Этот раздел даёт опытным участникам несколько советов и рекомендаций.
Не уверены, стоит ли этот запрос на вытягивание? Нашли ошибку и знаете, как её исправить? Сделайте это! Мы будем признательны. Любое значительное улучшение должно быть задокументировано как проблема GitHub, прежде чем кто-либо начнёт над ним работать.
Мы всегда рады получать запросы на вытягивание. Мы делаем всё возможное, чтобы обработать их быстро. Если ваш запрос на вытягивание не будет принят с первой попытки, не расстраивайтесь!
Вы можете предложить новые дизайны существующих функций Excelize. Вы также можете разработать совершенно новые функции. Мы действительно ценим участников, которые хотят реорганизовать или иным образом очистить наш проект.
Мы стараемся поддерживать Excelize компактным и целенаправленным. Excelize не может делать всё для всех. Это означает, что мы можем отказаться от включения новой функции. Однако может быть способ реализовать эту функцию поверх Excelize.
Форкните репозиторий и внесите изменения в свою ветку форка:
Проведите модульные тесты для своих изменений. У 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» в коммитах, которые закрывают проблему. Включение ссылок автоматически закрывает проблему при слиянии.
Пожалуйста, ознакомьтесь с разделом Стиль кодирования для получения дополнительных рекомендаций.
Сопровождающие Excelize используют LGTM (Looks Good To Me) в комментариях к проверке кода, чтобы указать на принятие.
Подпись представляет собой простую строку в конце пояснения к патчу. Ваша подпись подтверждает, что вы написали патч или иным образом имеете право передать его как патч с открытым исходным кодом. Правила довольно просты: если вы можете подтвердить следующее (с сайта developercertificate.org):
Сертификат разработчика о происхождении Версия 1.1
Авторские права (C) 2004, 2006 The Linux Foundation и её участники.
Каждому разрешается копировать и распространять дословные копии этого документа лицензии, но изменение его запрещено.
Сертификат разработчика о происхождении 1.1
Внося вклад в этот проект, я подтверждаю, что:
(a) Вклад был полностью или частично создан мной, и у меня есть право представить его под открытой лицензией, указанной в файле; или
(b) Вклад основан на предыдущей работе, которая, насколько мне известно, защищена соответствующей открытой лицензией, и у меня есть право в соответствии с этой лицензией представить эту работу с изменениями, полностью или частично созданную мной, под той же открытой лицензией (если только мне не разрешено представлять её под другой лицензией), как указано в файле; или
(c) Вклад был предоставлен мне непосредственно другим лицом, которое подтвердило пункты (a), (b) или (c), и я не вносил в него изменений.
(d) Я понимаю и соглашаюсь с тем, что этот проект и вклад являются публичными, и что запись о вкладе (включая всю личную информацию, которую я предоставляю вместе с ним, включая мою подпись) ведётся бессрочно и может быть распространена в соответствии с этим проектом или задействованными открытыми лицензиями.
Затем вы просто добавляете строку к каждому сообщению git commit:
Signed-off-by: Ri Xu https://xuri.me
Используйте своё настоящее имя (извините, никаких псевдонимов или анонимных вкладов).
Если вы установите свои git-конфигурации user.name и user.email, вы сможете подписать свой коммит автоматически с помощью команды git commit -s.
Во-первых, все сопровождающие имеют три вещи:
Сопровождающих часто недооценивают, потому что их работу труднее оценить. Легко оценить действительно крутую и технически продвинутую функцию. Труднее оценить отсутствие ошибок, медленное, но устойчивое улучшение стабильности или надёжность процесса выпуска. Но именно эти вещи отличают хороший проект от великого.
Не забывайте: быть сопровождающим — это инвестиция времени. Убедитесь, что у вас будет время, чтобы быть доступным. Вам не нужно быть сопровождающим, чтобы внести свой вклад в проект!
Если вы хотите стать сопровождающим, свяжитесь с xuri.me и представьтесь.
Мы хотим, чтобы сообщество было потрясающим, растущим и основанным на сотрудничестве. Нам нужна ваша помощь, чтобы сохранить его таким. Чтобы помочь в этом, мы разработали некоторые общие рекомендации для сообщества в целом:
Будьте вежливы: будьте учтивы, уважительны и вежливы по отношению к другим членам сообщества: региональное, расовое, гендерное или другое насилие недопустимо. Нам гораздо больше нравятся хорошие люди, чем плохие!
Поощряйте разнообразие и участие: сделайте так, чтобы каждый член нашего сообщества чувствовал себя желанным гостем, независимо от его происхождения и степени его вклада, и делайте всё возможное, чтобы поощрять участие в нашем сообществе.
Соблюдайте закон: в основном, не втягивайте нас в неприятности. Делитесь только контентом, который принадлежит вам, не делитесь личным или конфиденциальным контентом. Информация и не нарушайте закон.
Оставайтесь в теме: убедитесь, что вы публикуете сообщения в правильном канале и избегайте обсуждений не по теме. Помните, что когда вы обновляете проблему или отвечаете на электронное письмо, вы потенциально отправляете его большому количеству людей. Пожалуйста, подумайте об этом, прежде чем обновлять информацию. Также помните, что никто не любит спам.
Не отправляйте электронные письма сопровождающим: нет необходимости отправлять электронные письма сопровождающим с просьбой расследовать проблему или взглянуть на запрос на вытягивание. Вместо отправки электронного письма следует использовать упоминания GitHub, чтобы привлечь внимание сопровождающих к запросу на вытягивание, предложению или проблеме.
Цель этого раздела — не найти возможности наказать людей, но нам нужен справедливый способ справиться с людьми, которые делают наше сообщество плохим.
Первое нарушение: мы дадим вам дружеское, но публичное напоминание о том, что поведение не соответствует нашим рекомендациям.
Второе нарушение: мы отправим вам личное сообщение с предупреждением о том, что любые дополнительные нарушения приведут к исключению из сообщества.
Третье нарушение: в зависимости от нарушения, мы можем удалить или заблокировать вашу учётную запись.
Примечания:
Очевидные спамеры блокируются при первом нарушении. Если мы этого не сделаем, у нас будет спам повсюду.
Нарушения прощаются после 6 месяцев хорошего поведения, и мы не будем держать обиду.
Люди, совершающие незначительные нарушения, получат образование, а не будут наказаны в процессе трёх предупреждений.
Правила применяются одинаково ко всем членам сообщества, независимо от того, насколько вы внесли свой вклад.
Чрезвычайные нарушения угрожающего, оскорбительного, разрушительного или незаконного характера будут рассматриваться немедленно и не подлежат трём предупреждениям или прощению.
Чтобы сообщить о злоупотреблении или обжаловать нарушения, обратитесь по адресу xuri.me. В случае апелляций мы знаем, что ошибки случаются, и мы будем работать с вами, чтобы найти справедливое решение, если произошло недоразумение.
Если явно не указано иное, мы следуем всем рекомендациям по кодированию сообщества Go. Хотя некоторые из этих стандартов могут показаться произвольными, они каким-то образом приводят к созданию надёжной и согласованной кодовой базы.
Возможно, кодовая база в настоящее время не соответствует этим рекомендациям. Мы не ищем массивный PR, который это исправит, поскольку это противоречит духу рекомендаций. Все новые вклады должны делать всё возможное, чтобы очистить и улучшить кодовую базу. Очевидно, применяйте своё лучшее суждение. Помните, цель здесь — сделать кодовую базу более удобной для навигации и понимания людьми. Всегда имейте это в виду, когда побуждаете других соблюдать правила.
Правила:
gofmt -s.go vet.noCommaALongVariableNameLikeThisIsNotMoreClearWhenASimpleCommentWouldDo. На практике короткие методы будут иметь короткие имена переменных, а глобальные переменные будут иметь более длинные имена.go test и... Большинство функций, использующих контекст, должны принимать его в качестве первого параметра.Не игнорируйте ошибки с помощью переменных _. Если функция возвращает ошибку, проверьте её, чтобы убедиться, что функция выполнена успешно. Обработайте ошибку, верните её или, в действительно исключительных ситуациях, вызовите панику.
Строки ошибок не должны начинаться с заглавных букв (если только это не имена собственные или аббревиатуры) и заканчиваться знаками препинания, так как они обычно печатаются после другого контекста. То есть используйте fmt.Errorf("something bad"), а не fmt.Errorf("Something bad"), чтобы log.Printf("Reading %s: %v", filename, err) форматировался без лишней заглавной буквы в середине сообщения. Это не относится к логированию, которое по умолчанию ориентировано на строки и не объединяется внутри других сообщений.
Не используйте пакет math/rand для генерации ключей, даже одноразовых. Без начального значения генератор полностью предсказуем. С начальным значением time.Nanoseconds() энтропии всего несколько бит. Вместо этого используйте Reader из пакета crypto/rand, а если вам нужен текст, преобразуйте его в шестнадцатеричный формат или base64.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )