Как открыть исходный код: Как посмотреть исходный код страницы

Содержание

c++ — Как посмотреть исходный код программы?

Я хочу подправить исходный код, ничего серьезного, только вывод нескольких строк. Программа написана скорее всего на С++. Мне использовать отладчик? Или как-то открыть в IDE? Просто я не хочу запускать программу, хочу просто поковыряться в коде. И может посоветуете какой нибудь? P.S. Сам файл — .exe

c++
отладчик

Исходный код раскрыть невозможно если для этого постарались обеспечить безопасность (особенно если это фирменная вещь).

Но есть способы полностью или частично раскрыть код.

IDA Pro — самый лучший из безплатных взломщиков, некоторые макросы возможно позволяют преобразовать код назад. Но не всегда. Особо хорошо раскрываются borland-продукты.
Hiew.Exe бесплатная утилита, очень маленькая, позволяет править код на языке ассемблера. Можно править текстовые и целые константы. Можно ею даже сделать «перевод» программы на другой язык, затереть имя фирмы и т.п.

Если есть PDB-файл, или подшита debug-info к файлу то код можно получить в среде разработки (если debug-info полная) редко можно использовать. Исходный код получить нельзя, но можно получить «номера строк и имена исходников», а так же имена/значения всех констант, локальных переменных, избежать «раздроблености функций» а так же получить классы с начинкой класса (почти все структуры кроме текста программы) что значительно упростит понимание работы программы. Для некоторых библиотек (dll) pdb-файлы можно скачать отдельно. Врядли уважающая себя фирма допустит утечку pdb своего стоящего продукта.
Debug info, существует DebugInfo-информация встроеная в exe. Если есть такая информация, и соответствующая утилита (Например на Borland Delphi собран, и он есть в наличии), то можно сделать аналогичное предыдущему пункту. Но врядли уважающая себя фирма допустит такую «глупую» ошибку (аналогично pdb).
Если файл написан на с# его можно почти полностью просмотреть в кодах с помощью disSharp (такие программы «подключают» в таблице импорта лишь mscorlib и всё). DisSharp плохо дизассемблирует некоторые части программы, но возможно его платная версия или платная версия подобных утилит раскрывает код лучше.
Если файл написан на FoхPro, clipper и других подобный байт-кодовых языках — он раскрывается спец-утилитами (Refox например).
Утилита exescope.exe ResourceHacker.exe и её-подобные утилиты позволяют смотреть шапку, подключенные библиотеки (по ним можно понять на чём писана программа) и редактировать ресурсы программы (ресурс-формы в.т.ч. delphi, иконки, картинки, таблицы ресурсо-строк).
Если извесно чем создан код — думаю есть специальные утилиты способные его раскрыть (они платные и малодоступные).

Опять-же, это при условии что нету паковщика кода (тогда нужно сначала применить депаковщик), шифровальщика/самомодифицирующегося кода. Если не разбит обфускатором так что не распутать. Чем больше код — тем сложнее разобраться.

P.S. Лично моё мнение — раскрывается-взламывается всё, но на это нужно потратить много-много времени. Возможно год и более (зависит от опыта и инструментов, в свободном доступе хороших инструментов нету).

Рад буду ошибаться, что такого способа для «новичка» просто нет. Вам нужно дизассемблеровать exe-файл в IDA или Hiew32, ну и там уже рассматривать код на языке asm(низкого уровня).

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

Зарегистрируйтесь или войдите

Регистрация через Google

Регистрация через Facebook

Регистрация через почту

Отправить без регистрации

Почта

Необходима, но никому не показывается

Отправить без регистрации

Почта

Необходима, но никому не показывается

Нажимая на кнопку «Отправить ответ», вы соглашаетесь с нашими пользовательским соглашением, политикой конфиденциальности и политикой о куки

Почему компании не должны бояться открывать исходный код своих продуктов — Трибуна на vc.

Если вы не Microsoft, не Apple и не SAP, то вопрос открытых кодов пока еще остается на ваше усмотрение. Однако если вы работаете в сфере b2b, да еще и пытаетесь охватить зарубежные рынки, то мы рекомендуем вам задуматься, потому что open source может стать тем самым толчком, после которого ваш стартап точно взлетит.

Принято считать, что открытое ПО и коммерческое ПО — это две взаимоисключающие категории. На самом деле нет.

Исходный код — это ключ к доверию со стороны b2b-клиентов, озабоченных заявлениями Сноудена (их реально больше, чем вы думаете), это ваше конкурентное преимущество, это грамотный подход к (страшное слово) госзаказам. Тем не менее, разработчики не торопятся выставлять исходники на всеобщее обозрение, и причин тому несколько. Рассмотрим самые распространенные open source-страхи, с которыми столкнулись и мы.

Мой код украдут

Нет, если вы с умом подойдете к выбору лицензии. До формирования open source сообщества (это 1970-е, если что) такая опасность действительно существовала, однако сегодня есть несколько десятков способов защитить свой код. Да и не стоит недооценивать могущество группы людей, объединенных идейно, ведь нарушив условия лицензирования, злоумышленник пойдет не только против разработчика оригинального решения, но и против всего сообщества, а это уже чревато.

Наш опыт: Для ONLYOFFICE мы выбрали AGPLv3. Таким образом, компании могут бесплатно использовать наш продукт для внутренних нужд, однако если кто-то захочет встроить наш код в собственное приложение, придётся публиковать его под той же лицензией.

Что вам делать со всей этой информацией: зайти на Choosealicense. Чтобы облегчить нам жизнь, GitHub еще в прошлом году запустил этот проект для быстрого выбора подходящей лицензии.

Не украдут, так подсмотрят!

Рассказываю. Мы целый год не решались выложить исходные коды на SourceForge, потому что опасения были велики. Ну вот представьте: вы сделали уникальный продукт, способный конкурировать с сильными мира сего. Конечно, нам всем снится, как Google идет и смотрит наш код. А потом со своими маркетинговыми бюджетами покоряет мир с идеей НАШЕГО продукта.

Но давайте посмотрим правде в глаза. Код — это несколько миллионов строк. Если вы думаете, что их так легко подсмотреть, вы, наверное, не программист, а маркетолог.

Наш опыт: Взвесив все «за» и «против», мы прикинули, что у компании X уйдет не менее трёх лет на то, чтобы перелопатить наш код и поднять редактор сегодняшнего уровня. К этому моменту мы реализуем функциональности еще на три года таких «гонок».

Что делать вам: Обратить внимание на такой успешный проект, как Couchbase. С появлением новых версий продукта ребята просто публикуют всю предыдущую функциональность в open source. При такой схеме они зарабатывают на обновлениях, а исходный код отлично способствует повышению доверия и распространению. Среди клиентов компании — AOL, Starbucks, Skyscanner, Orbitz и т. д.

А деньги где?

Когда обычный пользователь слышит «open source», он думает: «О, бесплатно!» Когда руководитель компании слышит «open source», он думает: «стабильность».

Да, действительно, в большинстве случаев код публикуется на GitHub по принципу «Придумал решение — поделился». То есть безвозмездно и без обязательств. Но давайте вспомним начало статьи — мы говорим о b2b-секторе. Open source здесь можно рассматривать в качестве средства, а не цели (см. пример с Couchbase).

Впрочем, если мы обратимся к недавнему исследованию Forrester, то увидим, что компании действительно все больше склоняются к использованию open source продуктов. Это дешевле, это надежнее, и Большой Брат не читает вашу почту. В том же исследовании отмечено, что 71% желающих отказывается от идеи открытого ПО, потому что переживают, что не смогут самостоятельно его развернуть и поддерживать.

Именно на этом «страхе» уже много лет активно зарабатывают такие компании, как Percona, её прародитель MySQL, MongoDB, WordPress, Coachbase — продолжать можно очень долго. Если вам этого недостаточно, то вот навскидку еще несколько идей:

Кастомизация;
Расширенная функциональность в платной SaaS-версии;
Реклама.

СПО — это для гиков, а мигрировать никто не будет, потому что это дорого

Приверженцы Microsoft активно продвигают идею того, что свободное ПО на самом деле «псевдобесплатное», и миграция стоит денег. Если вы различаете понятия краткосрочных и долгосрочных затрат, то поймете, что обвинения Open Source в дороговизне голословны.

Давайте мы просто оставим здесь историю о том, как вся администрация Мюнхена (2000 человек) решила перейти с MS Office на OpenOffice и в результате сэкономила €13 млн при затратах на миграцию в €270K.

У истории есть, правда, и обратная сторона. Вместе с Мюнхеном на OpenOffice хотела перейти администрация города Фрайбург. Но ребята пожалели денег на смену ОС, и еще оставили узкому кругу пользователей офисные пакеты Microsoft. В итоге с документами у них получился полный бардак из-за несовместимости форматов, так что пришлось тратить еще более миллиона евро на то, чтобы опять всем дружно перейти на Microsoft.

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

Более того, в условиях кризиса переход на Open Source — это естественный шаг многих компаний, вызванный сокращением расходов. Сверху график затрат на проприетарное ПО, снизу — при миграции на Open Source. Взято на Zdnet.

Наш опыт: В нашей команде исторически сложилось так, что вся разработка ведется под Windows, но сейчас мы, конечно, спешно переписываем все на Mono, чтобы эффективно вписаться в инфраструктуру Open Source, и компании, которые решатся на миграцию, смогли бы использовать нас в качестве альтернативы всем известного офиса.

Что делать вам: писать сразу под Linux, конечно.

Заключительное слово

Этой статьёй мы не призываем вас, дорогие разработчики, срочно публиковать весь свой код на GitHub. SWOT-анализ еще никто не отменял. Просто так уж сложилось, что Open Source (как нам кажется) недооценивают с точки зрения маркетинга, в то время как его популярность во всем мире растет как на дрожжах. Если правильно использовать этот тренд в своей стратегии, у вас есть все шансы получить серьёзное конкурентное преимущество. Удачи!

Чтобы написать колонку для ЦП, ознакомьтесь с требованиями к публикуемым материалам.

Как внести свой вклад в открытый исходный код

Зачем вносить свой вклад в открытый исходный код?

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

— @errietta, «Почему я люблю участвовать в разработке программного обеспечения с открытым исходным кодом»

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

Почему люди вносят свой вклад в открытый исходный код? Много причин!

Улучшение программного обеспечения, на которое вы полагаетесь

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

Улучшите имеющиеся навыки

Будь то кодирование, дизайн пользовательского интерфейса, графический дизайн, письмо или организация, если вы ищете практику, для вас есть задача в проекте с открытым исходным кодом.

Познакомьтесь с людьми, которые интересуются похожими вещами

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

Найдите наставников и научите других

Работая с другими над общим проектом, вам придется объяснять, как вы что-то делаете, а также просить других людей о помощи. Акты обучения и преподавания могут быть полноценной деятельностью для всех участников.

Создавайте общедоступные артефакты, которые помогут вам повысить репутацию (и карьеру)

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

Изучите навыки работы с людьми

Открытый исходный код предлагает возможности для практики лидерских и управленческих навыков, таких как разрешение конфликтов, организация команд и определение приоритетов в работе.

Возможность вносить изменения, даже небольшие, дает возможность

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

Что значит внести свой вклад

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

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

Вам не нужно вносить свой код

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

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

— @orta, «Переход на OSS по умолчанию»

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

Нравится ли вам планировать мероприятия?

Организуйте семинары или встречи по проекту, как это сделал @fzamperin для NodeSchool
Организовать конференцию проекта (если есть)
Помогите членам сообщества найти подходящие конференции и представить предложения для выступлений

Нравится ли вам дизайн?

Реструктуризация макетов для повышения удобства использования проекта
Проведите исследование пользователей, чтобы реорганизовать и усовершенствовать навигацию или меню проекта, как это предлагает Drupal
Составить руководство по стилю, чтобы проект имел единообразный визуальный дизайн
Создайте рисунок для футболок или новый логотип, как это сделали авторы hapi. js

Вы любите писать?

Написание и улучшение проектной документации
Создайте папку с примерами, показывающими, как используется проект
Запустите информационный бюллетень для проекта или курируйте основные моменты из списка рассылки
Напишите учебные пособия для проекта, как это сделали участники PyPA
Написать перевод документации проекта

Серьезно, [документация] мегаважна. До сих пор документация была отличной и была убийственной особенностью Babel. Есть разделы, которые, безусловно, нуждаются в некоторой доработке, и даже добавление абзаца здесь или там чрезвычайно приветствуется.

— @kittens, «Приглашение участников»

Вам нравится организовывать?

Ссылка на дубликаты задач и предложение новых меток задач для систематизации
Просмотрите открытые проблемы и предложите закрыть старые, как это сделал @nzakas для ESLint
Задавайте уточняющие вопросы по недавно открытым темам, чтобы продвинуть обсуждение вперед

Любишь программировать?

Найдите открытую проблему для решения, как это сделал @dianjin для листовки
Спросите, можете ли вы помочь написать новую функцию
Автоматизировать настройку проекта
Улучшить инструменты и тестирование

Вам нравится помогать людям?

Ответьте на вопросы о проекте, например, о переполнении стека (например, в этом примере Postgres) или Reddit
Ответить на вопросы людей по открытым вопросам
Помогите модерировать форумы или каналы общения

Нравится ли вам помогать другим программировать?

Код просмотра материалов других людей
Напишите руководства по использованию проекта
Предложите наставничество другому участнику, как @ereichert сделал для @bronzdoc на Rust

Вам нужно не только работать над программными проектами!

Хотя слово «открытый исходный код» часто относится к программному обеспечению, вы можете совместно работать над чем угодно. Есть книги, рецепты, списки и классы, которые разрабатываются как проекты с открытым исходным кодом.

Например:

@sindresorhus курирует список «потрясающих» списков
@h5bp ведет список потенциальных вопросов для собеседования с кандидатами на разработку интерфейсов
@stuartlynn и @nicole-a-tesla собрали забавные факты о тупиках

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

Ориентироваться на новый проект

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

— @shaunagm, «Как внести свой вклад в Open Source»

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

Прежде чем вслепую выдвигать собственные предложения, начните с того, что научитесь читать комнату. Это увеличивает шансы того, что ваши идеи будут замечены и услышаны.

Анатомия проекта с открытым исходным кодом

Каждое сообщество с открытым исходным кодом отличается.

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

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

В типичном проекте с открытым исходным кодом участвуют следующие типы людей:

Автор: Лицо или организация, создавшие проект
Владелец: Лицо/лица, которые имеют административное право собственности на организацию или репозиторий (не всегда совпадают с первоначальным автором)
Сопровождающие: Участники, отвечающие за формирование видения и управление организационными аспектами проекта (Они также могут быть авторами или владельцами проекта. )
Участники: Все, кто внес свой вклад в проект
Члены сообщества: Люди, которые используют проект. Они могут быть активными в разговорах или высказывать свое мнение о направлении проекта

Более крупные проекты также могут иметь подкомитеты или рабочие группы, занимающиеся различными задачами, такими как инструменты, сортировка, модерация сообщества и организация мероприятий. Найдите на веб-сайте проекта страницу «команды» или в репозитории документации по управлению, чтобы найти эту информацию.

Проект также имеет документацию. Эти файлы обычно перечислены на верхнем уровне репозитория.

ЛИЦЕНЗИЯ: По определению каждый проект с открытым исходным кодом должен иметь лицензию с открытым исходным кодом. Если проект не имеет лицензии, он не является открытым исходным кодом.
README: README — это инструкция, приветствующая новых членов сообщества в проекте. В нем объясняется, почему проект полезен и с чего начать.
ВКЛАД: В то время как файлы README помогают людям использовать проект, документы помогают людям внести свой вклад в проект . В нем объясняется, какие типы взносов необходимы и как работает процесс. Хотя не у каждого проекта есть файл CONTRIBUTING, его наличие свидетельствует о том, что это желанный проект, в который можно внести свой вклад.
CODE_OF_CONDUCT: Кодекс поведения устанавливает основные правила поведения участников и помогает создать дружелюбную и доброжелательную атмосферу. Хотя не у каждого проекта есть файл CODE_OF_CONDUCT, его наличие свидетельствует о том, что это желанный проект, в который можно внести свой вклад.
Прочая документация: Может быть дополнительная документация, например учебные руководства, пошаговые руководства или политики управления, особенно для крупных проектов.

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

Система отслеживания проблем: Где люди обсуждают вопросы, связанные с проектом.
Запросы на вытягивание: Где люди обсуждают и анализируют текущие изменения.
Дискуссионные форумы или списки рассылки: Некоторые проекты могут использовать эти каналы для обсуждения тем (например, «Как мне…» или «Что вы думаете о…» вместо сообщений об ошибках или запросов функций). Другие используют средство отслеживания проблем для всех разговоров.
Канал синхронного чата: В некоторых проектах каналы чата (такие как Slack или IRC) используются для случайного общения, совместной работы и быстрого обмена мнениями.

Поиск проекта, в который можно внести свой вклад

Теперь, когда вы поняли, как работают проекты с открытым исходным кодом, пришло время найти проект, в который можно внести свой вклад!

Если вы никогда раньше не вносили вклад в открытый исходный код, прислушайтесь к совету президента США Джона Ф. Кеннеди, который однажды сказал: : «Не спрашивай, что твоя страна может сделать для тебя, спроси, что ты можешь сделать для своей страны».

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

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

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

Открытый исходный код не является эксклюзивным клубом; это сделано такими же людьми, как и вы. «Открытый исходный код» — это просто причудливый термин для обозначения мировых проблем как решаемых.

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

28% случайных вкладов в открытый исходный код — это документация, такая как исправление опечатки, переформатирование или написание перевода.

Если вы ищете существующие проблемы, которые вы можете исправить, в каждом проекте с открытым исходным кодом есть страница /contribute , на которой освещаются проблемы, удобные для начинающих, с которых вы можете начать. Перейдите на главную страницу репозитория на GitHub и добавьте /contribute в конце URL-адреса (например, https://github.com/facebook/react/contribute 9).0276).

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

GitHub Explore
Пятница с открытым исходным кодом
Только для новичков
CodeTriage
24 запроса на вытягивание
Впереди
Автор-ниндзя
Первый вклад
Исходная сортировка

`Контрольный список перед тем, как внести свой вклад`

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

Вот удобный контрольный список, чтобы оценить, подходит ли проект для новых участников.

Соответствует определению открытого исходного кода

Есть ли у него лицензия? Обычно в корне репозитория находится файл LICENSE.

Проект активно принимает вклады

Посмотрите на активность фиксации в основной ветке. На GitHub вы можете увидеть эту информацию на домашней странице репозитория.

Когда был последний коммит?

Сколько участников у проекта?

Как часто люди совершают сделки? (На GitHub вы можете найти это, нажав «Коммиты» на верхней панели.)

Далее посмотрите на задачи проекта.

Сколько открытых вопросов?

Быстро ли сопровождающие реагируют на проблемы, когда они открываются?

Ведется ли активное обсуждение вопросов?

Проблемы недавние?

Вопросы закрываются? (На GitHub щелкните вкладку «закрытые» на странице «Проблемы», чтобы увидеть закрытые проблемы. )

Теперь сделайте то же самое для пул-реквестов проекта.

Сколько существует открытых запросов на включение?

Быстро ли мейнтейнеры реагируют на пул-реквесты, когда они открываются?

Идет ли активное обсуждение пулл-реквестов?

Являются ли запросы на вытягивание последними?

Как давно были объединены запросы на вытягивание? (На GitHub щелкните вкладку «закрытые» на странице запросов на вытягивание, чтобы просмотреть закрытые PR.)

Проект приветствует

Дружелюбный и гостеприимный проект сигнализирует о том, что он будет рад новым участникам.

Отвечают ли сопровождающие на вопросы в задачах?

Дружелюбны ли люди в вопросах, на дискуссионном форуме и в чате (например, IRC или Slack)?

Проверяются ли запросы на вытягивание?

Благодарят ли сопровождающие людей за их вклад?

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

— @kfogel, Производство OSS

`Как внести свой вклад`

Вы нашли проект, который вам нравится, и вы готовы внести свой вклад. Наконец-то! Вот как правильно получить свой вклад.

`Эффективное общение`

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

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

— @shubheksha, Очень ухабистое путешествие новичка в мир открытого исходного кода

Перед тем, как открыть задачу, запрос на включение или задать вопрос в чате, помните об этих моментах, чтобы ваши идеи были эффективно реализованы.

Дайте контекст. Помогите другим быстро освоиться. Если вы столкнулись с ошибкой, объясните, что вы пытаетесь сделать и как ее воспроизвести. Если вы предлагаете новую идею, объясните, почему вы считаете, что она будет полезна для проекта (не только для вас!).

😇 «X не происходит, когда я делаю Y»
😢 «X сломан! Пожалуйста, исправьте это».

Заранее сделайте домашнее задание. Ничего не знать — это нормально, но покажи, что ты пытался. Прежде чем обращаться за помощью, обязательно проверьте README проекта, документацию, проблемы (открытые или закрытые), список рассылки и поищите ответ в Интернете. Люди оценят, если вы продемонстрируете, что пытаетесь учиться.

😇 «Я не знаю, как реализовать X. Я проверил справочную документацию и не нашел никаких упоминаний».
😢 «Как сделать X?»

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

😇 «Я хочу написать учебник по API».
😢 «На днях я ехал по шоссе и остановился, чтобы заправиться, и тут у меня появилась потрясающая идея, что мы должны сделать, но прежде чем я объясню это, позвольте мне показать вам…»

Держите все сообщения в открытом доступе. Хотя это и заманчиво, не обращайтесь к сопровождающим в частном порядке, если только вам не нужно поделиться конфиденциальной информацией (например, о проблеме безопасности или серьезном нарушении правил поведения). Когда вы держите беседу публичной, больше людей могут узнать и извлечь пользу из вашего обмена мнениями. Обсуждения сами по себе могут быть вкладами.

😇 (как комментарий) «@-maintainer Привет! Как нам поступить с этим пиаром?»
😢 (как электронное письмо) «Привет, извините, что беспокою вас по электронной почте, но я хотел бы узнать, есть ли у вас возможность просмотреть мой PR»

Можно задавать вопросы (но наберитесь терпения!). В какой-то момент все были новичками в проекте, и даже опытным участникам нужно быть в курсе, когда они смотрят на новый проект. Точно так же даже давние сопровождающие не всегда знакомы со всеми частями проекта. Проявите к ним такое же терпение, какое вы хотели бы, чтобы они проявили к вам.

😇 «Спасибо, что рассмотрели эту ошибку. Я последовал вашим предложениям. Вот результат».
😢 «Почему ты не можешь решить мою проблему? Это не твой проект?»

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

😇 «Я разочарован, что вы не можете поддержать мой вариант использования, но, как вы объяснили, это затрагивает лишь небольшую часть пользователей, и я понимаю, почему. Спасибо за прослушивание."
😢 «Почему вы не поддерживаете мой вариант использования? Это неприемлемо!"

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

`Сбор контекста`

Прежде чем что-либо делать, быстро проверьте, не обсуждалась ли ваша идея где-либо еще. Просмотрите README проекта, выпуски (открытые и закрытые), список рассылки и Stack Overflow. Вам не нужно тратить часы на просмотр всего, но быстрый поиск по нескольким ключевым терминам имеет большое значение.

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

Проблемы похожи на начало разговора или обсуждения
Запросы на вытягивание предназначены для начала работы над решением
Для легкого общения, например, уточняющего или практического вопроса, попробуйте задать вопрос в Stack Overflow, IRC, Slack или других каналах чата, если в проекте есть такой

Перед тем, как открыть задачу или запрос на вытягивание, проверьте вспомогательную документацию проекта (обычно это файл CONTRIBUTING или файл README), чтобы узнать, нужно ли вам включить что-то конкретное. Например, они могут попросить вас следовать шаблону или потребовать, чтобы вы использовали тесты.

Если вы хотите внести существенный вклад, откройте вопрос, чтобы задать его, прежде чем работать над ним. Полезно некоторое время наблюдать за проектом (на GitHub вы можете нажать «Смотреть», чтобы получать уведомления обо всех обсуждениях) и познакомиться с членами сообщества, прежде чем выполнять работу, которая может быть не принята.

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

— @gaearon о присоединении к проектам

`Открытие вопроса`

Обычно вам следует открывать вопрос в следующих ситуациях:

Сообщить об ошибке, которую вы не можете решить самостоятельно
Обсудить тему или идею высокого уровня (например, сообщество, видение или политику)
Предложите новую функцию или другую идею проекта

Советы по общению по проблемам:

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

`Открытие запроса на включение`

Обычно вам следует открывать запрос на вытягивание в следующих ситуациях:

Отправить тривиальные исправления (например, опечатку, неработающую ссылку или очевидную ошибку)
Начать работу над вкладом, о котором уже просили или который вы уже обсуждали в выпуске

Запрос на вытягивание не обязательно должен представлять законченную работу. Обычно лучше открыть запрос на вытягивание на ранней стадии, чтобы другие могли посмотреть или оставить отзыв о вашем прогрессе. Просто откройте его как «черновик» или отметьте как «WIP» (в работе) в строке темы. Вы всегда можете добавить больше коммитов позже.

Если проект находится на GitHub, вот как отправить запрос на вытягивание:

Разветвите репозиторий и клонируйте его локально. Подключите свой локальный репозиторий к исходному «восходящему» репозиторию, добавив его в качестве удаленного. Часто вносите изменения из «исходной ветки», чтобы оставаться в курсе событий, чтобы при отправке запроса на включение конфликты слияния были менее вероятными. (Подробнее см. здесь.)
Создайте ветку для ваших правок.
Ссылка на любые соответствующие проблемы или подтверждающую документацию в вашем PR (например, «Closes # 37»)
Включите скриншоты до и после , если ваши изменения включают различия в HTML/CSS. Перетащите изображения в тело вашего запроса на включение.
Проверьте свои изменения! Внесите изменения в любые существующие тесты, если они существуют, и при необходимости создайте новые. Независимо от того, существуют тесты или нет, убедитесь, что ваши изменения не нарушают существующий проект.
Внесите свой вклад в стиле проекта в меру своих возможностей. Это может означать использование отступов, точек с запятой или комментариев иначе, чем в вашем собственном репозитории, но это упрощает слияние для сопровождающего, а другим — для понимания и поддержки в будущем.

Если это ваш первый запрос на вытягивание, ознакомьтесь с разделом «Создать запрос на вытягивание», который @kentcdodds создал в виде пошагового видеоурока. Вы также можете попрактиковаться в создании запросов на вытягивание в репозитории First Contributions, созданном @Roshanjossey.

`Что произойдет после того, как вы внесете вклад`

Вы сделали это! Поздравляем! Вы стали участником открытого исходного кода. Мы надеемся, что это первое из многих.

После отправки материала произойдет одно из следующих событий:

`😭 Вы не получили ответа.`

 Надеюсь, вы проверили проект на признаки активности, прежде чем вносить свой вклад. Однако даже в активном проекте ваш вклад может остаться без ответа.
 Если вы не получили ответа в течение недели, справедливо будет вежливо ответить в той же теме, попросив кого-нибудь оставить отзыв. Если вы знаете имя нужного человека, который рецензирует ваш вклад, вы можете @-упомянуть его в этой теме.
  Не обращайтесь  к этому человеку в частном порядке; помните, что общение с общественностью жизненно важно для проектов с открытым исходным кодом.
 Если вы вежливо стукнете, а вам все равно никто не ответит, возможно, никто и никогда не ответит. Это не самое приятное чувство, но пусть это вас не обескураживает. Это случилось со всеми! Существует множество возможных причин, по которым вы не получили ответ, в том числе личные обстоятельства, которые могут быть вне вашего контроля. Попробуйте найти другой проект или способ внести свой вклад. Во всяком случае, это хорошая причина не тратить слишком много времени на внесение вклада, пока другие члены сообщества не будут вовлечены и отреагируют.
 🚧 Кто-то просит изменить ваш вклад. 
 Обычно вас просят внести изменения в ваш вклад, будь то отзыв о масштабе вашей идеи или изменения в вашем коде.
 Когда кто-то просит внести изменения, откликайтесь. Они нашли время, чтобы рассмотреть ваш вклад. Открыть PR и уйти — дурной тон. Если вы не знаете, как внести изменения, изучите проблему, а затем обратитесь за помощью, если она вам понадобится.
 Если у вас больше нет времени для работы над проблемой (например, если разговор длится уже несколько месяцев, а ваши обстоятельства изменились), сообщите об этом сопровождающему, чтобы он не ждал ответа. Кто-то другой может быть счастлив взять на себя управление.
 👎 Ваш вклад не принят. 
 Ваш вклад может быть принят или не принят в конце концов. Надеюсь, вы не вложили в него слишком много труда. Если вы не уверены, почему он не был принят, вполне разумно обратиться к сопровождающему за отзывом и разъяснениями. В конечном счете, однако, вам нужно будет уважать то, что это их решение. Не спорьте и не ведите себя враждебно. Вы всегда можете раскошелиться и работать над своей версией, если вы не согласны!
 🎉 Ваш вклад принят. 
 Ура! Вы успешно сделали вклад в открытый исходный код!
 Ты сделал это! 
 Независимо от того, сделали ли вы свой первый вклад с открытым исходным кодом или ищете новые способы внести свой вклад, мы надеемся, что вы вдохновлены на действия. Даже если ваш вклад не был принят, не забудьте сказать спасибо, когда сопровождающий приложил усилия, чтобы помочь вам. Открытый исходный код создается такими же людьми, как и вы: один выпуск, запрос на включение, комментарий или «дай пять» за раз.
 Запуск проекта с открытым исходным кодом 
 «Что» и «почему» с открытым исходным кодом 
 Итак, вы думаете о том, чтобы начать работу с открытым исходным кодом? Поздравляем! Мир ценит ваш вклад. Давайте поговорим о том, что такое open source и почему люди этим занимаются.
 Что означает «открытый исходный код»? 
 Когда проект является открытым исходным кодом, это означает, что  любой может свободно использовать, изучать, изменять и распространять ваш проект для любых целей.  Эти разрешения применяются через лицензию с открытым исходным кодом.
 Открытый исходный код является мощным, поскольку он снижает барьеры для принятия и совместной работы, позволяя людям быстро распространять и улучшать проекты. Также потому, что это дает пользователям возможность контролировать свои собственные вычисления по сравнению с закрытым исходным кодом. Например, компания, использующая программное обеспечение с открытым исходным кодом, имеет возможность нанять кого-то для внесения в программное обеспечение пользовательских улучшений, а не полагаться исключительно на решения поставщика продукта с закрытым исходным кодом.
  Бесплатное программное обеспечение  относится к тому же набору проектов, что и  с открытым исходным кодом  . Иногда вы также можете встретить эти термины в сочетании как «бесплатное программное обеспечение с открытым исходным кодом» (FOSS) или «бесплатное программное обеспечение с открытым исходным кодом» (FLOSS).  Free  и  libre  относятся к свободе, а не к цене.
 Почему люди открывают исходный код своей работы? 
 Один из самых полезных опытов, который я получаю от использования и сотрудничества с открытым исходным кодом, связан с отношениями, которые я строю с другими разработчиками, сталкивающимися со многими из тех же проблем, что и я.
 — @kentcdodds, «Как мне было здорово заняться открытым исходным кодом»
 Существует множество причин, по которым человек или организация могут захотеть открыть исходный код проекта. Некоторые примеры включают:
  Сотрудничество:  Проекты с открытым исходным кодом могут принимать изменения от кого угодно в мире. Например, Exercism — это платформа для упражнений по программированию, в которой участвуют более 350 человек.
  Принятие и ремикширование:  Проекты с открытым исходным кодом могут использоваться кем угодно практически для любых целей. Люди могут даже использовать его для создания других вещей. WordPress, например, начинался как ответвление существующего проекта под названием b2.
  Прозрачность:  Любой может проверить проект с открытым исходным кодом на наличие ошибок или несоответствий. Прозрачность важна для правительств, таких как Болгария или США, регулируемых отраслей, таких как банковское дело или здравоохранение, и программного обеспечения для обеспечения безопасности, такого как Let’s Encrypt.
 Открытый исходный код предназначен не только для программного обеспечения. Вы можете открыть исходный код всего, от наборов данных до книг. Посетите GitHub Explore, чтобы узнать, что еще можно открыть с открытым исходным кодом.
 Открытый исходный код означает «бесплатный»? 
 Одним из главных преимуществ открытого исходного кода является то, что он не стоит денег. Однако «бесплатность» является побочным продуктом общей ценности открытого исходного кода.
 Поскольку лицензия с открытым исходным кодом требует, чтобы любой мог использовать, изменять и делиться вашим проектом практически для любых целей, сами проекты, как правило, бесплатны. Если бы использование проекта стоило денег, любой мог бы на законных основаниях сделать копию и использовать вместо нее бесплатную версию.
 В результате большинство проектов с открытым исходным кодом бесплатны, но «бесплатность» не является частью определения открытого исходного кода. Существуют способы взимать плату за проекты с открытым исходным кодом косвенно через двойное лицензирование или ограниченные функции, при этом соблюдая официальное определение открытого исходного кода.
 Должен ли я запустить свой собственный проект с открытым исходным кодом? 
 Короткий ответ — да, потому что независимо от результата запуск собственного проекта — отличный способ узнать, как работает открытый исходный код.
 Если вы никогда раньше не открывали проект с открытым исходным кодом, вы можете нервничать по поводу того, что скажут люди, и заметит ли кто-нибудь вообще. Если это похоже на вас, вы не одиноки!
 Работа с открытым исходным кодом похожа на любую другую творческую деятельность, будь то письмо или рисование. Может быть страшно делиться своей работой со всем миром, но единственный способ стать лучше — это практиковаться, даже если у вас нет аудитории.
 Если вы еще не убеждены, найдите минутку и подумайте, какие у вас могут быть цели.
 Постановка целей 
 Цели могут помочь вам понять, над чем нужно работать, от чего отказываться и где вам нужна помощь других. Начните с вопроса: , почему я открываю исходный код этого проекта? 
 На этот вопрос нет единственно правильного ответа. У вас может быть несколько целей для одного проекта или разные проекты с разными целями.
 Если ваша единственная цель состоит в том, чтобы продемонстрировать свою работу, вы можете даже не хотеть участия, и даже сказать об этом в своем README. С другой стороны, если вам нужны участники, вы потратите время на четкую документацию и на то, чтобы новички чувствовали себя желанными.
 В какой-то момент я создал собственный UIAlertView, который использовал… и решил сделать его открытым. Поэтому я изменил его, чтобы он был более динамичным, и загрузил его на GitHub. Я также написал свою первую документацию, объясняющую другим разработчикам, как использовать ее в своих проектах. Вероятно, никто никогда не использовал его, потому что это был простой проект, но я был доволен своим вкладом.
 — @mavris, «Разработчики-самоучки: почему Open Source важен для нас»
 По мере роста вашего проекта вашему сообществу может понадобиться больше, чем просто код. Реагирование на проблемы, проверка кода и евангелизация вашего проекта — все это важные задачи в проекте с открытым исходным кодом.
 Хотя количество времени, которое вы тратите на задачи, не связанные с кодированием, будет зависеть от размера и масштаба вашего проекта, вы как сопровождающий должны быть готовы решить их самостоятельно или найти кого-то, кто вам поможет.
  Если вы работаете в компании, которая занимается открытым исходным кодом проекта,  убедитесь, что у вашего проекта есть внутренние ресурсы, необходимые для его процветания. Вы захотите определить, кто отвечает за поддержку проекта после запуска, и как вы будете делиться этими задачами со своим сообществом.
 Если вам нужен специальный бюджет или персонал для продвижения, эксплуатации и поддержки проекта, начните эти разговоры заранее.
 Когда вы начинаете открывать исходный код проекта, важно убедиться, что ваши процессы управления учитывают вклад и возможности сообщества вокруг вашего проекта. Не бойтесь привлекать участников, не занятых в вашем бизнесе, к ключевым аспектам проекта, особенно если они часто участвуют.
 — @captainsafia, «Так ты хочешь открыть проект с открытым исходным кодом, а?»
 Участие в других проектах 
 Если ваша цель — научиться сотрудничать с другими или понять, как работает открытый исходный код, рассмотрите возможность участия в существующем проекте. Начните с проекта, который вы уже используете и любите. Участие в проекте может заключаться в исправлении опечаток или обновлении документации.
 Если вы не знаете, как начать работу в качестве участника, ознакомьтесь с нашим руководством «Как внести свой вклад в Open Source».
 Запуск собственного проекта с открытым исходным кодом 
 Нет идеального времени для открытия исходного кода вашей работы. Вы можете открыть исходный код идеи, незавершенной работы или после нескольких лет закрытого исходного кода.
 Вообще говоря, вам следует открыть исходный код вашего проекта, когда вы чувствуете себя комфортно, когда другие просматривают вашу работу и оставляют отзывы о ней.
 Независимо от того, на каком этапе вы решите открыть исходный код своего проекта, каждый проект должен включать следующую документацию:
 Лицензия на открытый исходный код
 README
 Руководство по внесению вклада
 Кодекс поведения
 Эти компоненты помогут вам, как сопровождающему, сообщать об ожиданиях, управлять вкладами и защищать все законные права (включая свои собственные). Они значительно увеличивают ваши шансы получить положительный опыт.
 Если ваш проект находится на GitHub, размещение этих файлов в корневом каталоге с рекомендуемыми именами файлов поможет GitHub распознать их и автоматически представить их вашим читателям.
 Выбор лицензии 
 Лицензия с открытым исходным кодом гарантирует, что другие могут использовать, копировать, изменять и вносить свой вклад в ваш проект без каких-либо последствий. Это также защитит вас от неприятных юридических ситуаций.  Вы должны включить лицензию при запуске проекта с открытым исходным кодом. 
 Юридическая работа не доставляет удовольствия. Хорошей новостью является то, что вы можете скопировать и вставить существующую лицензию в свой репозиторий. Это займет всего минуту, чтобы защитить вашу тяжелую работу.
 MIT, Apache 2.0 и GPLv3 — самые популярные лицензии с открытым исходным кодом, но есть и другие варианты на выбор.
 Когда вы создаете новый проект на GitHub, вам предоставляется возможность выбрать лицензию. Включение лицензии с открытым исходным кодом сделает ваш проект GitHub открытым исходным кодом.
 Если у вас есть другие вопросы или проблемы, связанные с юридическими аспектами управления проектом с открытым исходным кодом, мы вам поможем.
 Написание README 
 README не просто объясняет, как использовать ваш проект. Они также объясняют, почему ваш проект важен и что ваши пользователи могут с ним делать.
 Попробуйте ответить в README на следующие вопросы:
 Что делает этот проект?
 Чем полезен этот проект?
 Как мне начать?
 Где я могу получить дополнительную помощь, если она мне понадобится?
 Вы можете использовать свой README, чтобы ответить на другие вопросы, например, как вы обрабатываете вклады, каковы цели проекта, а также информацию о лицензиях и атрибуции. Если вы не хотите принимать участие или ваш проект еще не готов к производству, запишите эту информацию.
 Лучшая документация означает больше пользователей, меньше запросов в службу поддержки и больше участников. (…) Помните, что ваши читатели — это не вы. Есть люди, которые могут прийти на проект с совершенно другим опытом.
 — @tracymakes, «Пишите так, чтобы ваши слова читали (видео)»
 Иногда люди избегают написания README, потому что считают проект незавершенным или им не нужны дополнения. Все это очень веские причины написать его.
 Чтобы получить больше вдохновения, попробуйте использовать руководство @dguo «Создать README» или шаблон README @PurpleBooth, чтобы написать полный README.
 Когда вы включаете файл README в корневой каталог, GitHub автоматически отображает его на домашней странице репозитория.
 Написание инструкций по содействию 
 Файл CONTRIBUTING сообщает вашей аудитории, как участвовать в вашем проекте. Например, вы можете включить информацию о:
 Как подать отчет об ошибке (попробуйте использовать шаблоны запросов и запросов на вытягивание)
 Как предложить новую функцию
 Как настроить среду и запустить тесты
 В дополнение к техническим деталям файл CONTRIBUTING дает возможность сообщить о ваших ожиданиях в отношении вкладов, таких как:
 Типы вкладов, которые вы ищете
 Ваша дорожная карта или видение проекта
 Как участники должны (или не должны) связываться с вами
 Теплый, дружелюбный тон и конкретные предложения по вкладу (например, написание документации или создание веб-сайта) могут помочь новичкам почувствовать себя желанными и заинтересованными в участии.
 Например, Active Admin начинает свое руководство с:
 Во-первых, спасибо, что решили внести свой вклад в Active Admin. Именно такие люди, как вы, делают Active Admin таким замечательным инструментом.
 На самых ранних стадиях вашего проекта файл CONTRIBUTING может быть простым. Вы всегда должны объяснять, как сообщать об ошибках или проблемах с файлами, а также любые технические требования (например, тесты), чтобы внести свой вклад.
 Со временем вы можете добавить другие часто задаваемые вопросы в свой файл CONTRIBUTING. Запись этой информации означает, что меньше людей будут задавать вам одни и те же вопросы снова и снова.
 Чтобы получить дополнительную помощь в написании файла CONTRIBUTING, ознакомьтесь с шаблоном руководства @nayafia или «Как создать CONTRIBUTING.md» @mozilla.
 Ссылка на ваш файл CONTRIBUTING из вашего README, чтобы его увидело больше людей. Если вы поместите файл CONTRIBUTING в репозиторий вашего проекта, GitHub автоматически свяжется с вашим файлом, когда участник создаст задачу или откроет запрос на вытягивание.
 Разработка кодекса поведения 
 У всех нас был опыт, когда мы сталкивались с тем, что, вероятно, было злоупотреблением, либо как сопровождающий, пытающийся объяснить, почему что-то должно быть определенным образом, либо как пользователь… задающий простой вопрос. (…) Кодекс поведения становится документом, на который легко ссылаться и на который можно ссылаться, что свидетельствует о том, что ваша команда очень серьезно относится к конструктивному обсуждению.
 — @mlynch, «Сделать открытый исходный код более счастливым местом»
 Наконец, кодекс поведения помогает установить основные правила поведения для участников вашего проекта. Это особенно ценно, если вы запускаете проект с открытым исходным кодом для сообщества или компании. Кодекс поведения дает вам возможность способствовать здоровому и конструктивному поведению в сообществе, что снизит ваш стресс как сопровождающего.
 Для получения дополнительной информации ознакомьтесь с нашим руководством по Кодексу поведения.
 В дополнение к общению  того, как  вы ожидаете от участников поведения, кодекс поведения также имеет тенденцию описывать, к кому относятся эти ожидания, когда они применяются и что делать в случае нарушения.
 Подобно лицензиям с открытым исходным кодом, существуют новые стандарты для кодексов поведения, поэтому вам не нужно писать свои собственные. Contributor Covenant — это встраиваемый кодекс поведения, который используется более чем в 40 000 проектов с открытым исходным кодом, включая Kubernetes, Rails и Swift. Независимо от того, какой текст вы используете, вы должны быть готовы применить свой кодекс поведения, когда это необходимо.
 Вставьте текст непосредственно в файл CODE_OF_CONDUCT в вашем репозитории. Сохраните файл в корневом каталоге вашего проекта, чтобы его было легко найти, и дайте ссылку на него в файле README.
 Название и брендинг вашего проекта 
 Брендинг — это больше, чем яркий логотип или броское название проекта. Речь идет о том, как вы говорите о своем проекте и к кому вы обращаетесь со своим сообщением.
 Выбор правильного имени 
 Выберите имя, которое легко запомнить и, в идеале, дает некоторое представление о том, чем занимается проект. Например:
 Sentry отслеживает приложения для отчетов о сбоях
 Thin — быстрый и простой веб-сервер Ruby
 Если вы строите существующий проект, использование его имени в качестве префикса может помочь прояснить, что делает ваш проект (например, node-fetch переносит  window.fetch  в Node.js).
 Ясность превыше всего. Каламбуры — это весело, но помните, что некоторые шутки могут быть непонятны представителям другой культуры или людям с другим опытом. Некоторые из ваших потенциальных пользователей могут быть сотрудниками компании: вы не хотите, чтобы они чувствовали себя неловко, когда им приходится объяснять ваш проект на работе!
 Избегайте конфликтов имен 
 Проверьте наличие проектов с открытым исходным кодом с похожим названием, особенно если вы используете один и тот же язык или экосистему. Если ваше имя пересекается с популярным существующим проектом, вы можете запутать свою аудиторию.
 Если вы хотите, чтобы веб-сайт, дескриптор Twitter или другие свойства представляли ваш проект, убедитесь, что вы можете получить нужные имена. В идеале зарезервируйте эти имена сейчас для душевного спокойствия, даже если вы пока не собираетесь их использовать.
 Убедитесь, что название вашего проекта не нарушает права на товарные знаки. Позже компания может попросить вас закрыть ваш проект или даже возбудить против вас судебный иск. Это просто не стоит риска.
 Вы можете проверить Глобальную базу данных брендов ВОИС на наличие конфликтов товарных знаков. Если вы работаете в компании, это одна из вещей, с которой вам может помочь ваша юридическая команда.
 Наконец, выполните быстрый поиск в Google по названию вашего проекта. Смогут ли люди легко найти ваш проект? Появляется ли в результатах поиска что-то еще, что вы не хотели бы, чтобы они видели?
 То, как вы пишете (и программируете), влияет и на ваш бренд! 
 На протяжении всей жизни вашего проекта вы будете много писать: README, учебные пособия, документы сообщества, ответы на вопросы, возможно, даже информационные бюллетени и списки рассылки.
 Будь то официальная документация или обычное электронное письмо, ваш стиль письма является частью бренда вашего проекта. Подумайте, каким образом вы могли бы произвести впечатление на свою аудиторию и какой тон вы хотите передать.
 Я пытался участвовать в каждой ветке списка рассылки, демонстрируя образцовое поведение, доброжелательность к людям, серьезное отношение к их проблемам и стремление быть полезным в целом. Через некоторое время вокруг меня остались люди, которые не только задавали вопросы, но и помогали с ответами, и, к моему полному удовольствию, они подражали моему стилю.
 — @janl на CouchDB, «Устойчивый открытый исходный код»
 Использование теплого, инклюзивного языка (например, «они», даже когда речь идет об одном человеке) может иметь большое значение для того, чтобы сделать ваш проект более привлекательным для новых участников. Придерживайтесь простого языка, так как многие из ваших читателей могут не быть носителями английского языка.
 Помимо того, как вы пишете слова, ваш стиль кодирования также может стать частью бренда вашего проекта. Angular и jQuery — два примера проектов со строгими стилями кодирования и рекомендациями.
 Нет необходимости писать руководство по стилю для вашего проекта, когда вы только начинаете, и вы можете обнаружить, что вам все равно нравится включать в свой проект различные стили кодирования. Но вы должны предвидеть, как ваш стиль написания и программирования может привлечь или оттолкнуть разные типы людей. Самые ранние этапы вашего проекта — это ваша возможность создать прецедент, который вы хотите видеть.
 Ваш контрольный список перед запуском 
 Готовы открыть исходный код вашего проекта? Вот контрольный список, чтобы помочь. Ставить все галочки? Вы готовы к работе! Нажмите «опубликовать» и похлопайте себя по спине.
  Документация 
 В проекте есть файл LICENSE с лицензией с открытым исходным кодом.
 Проект имеет базовую документацию (README, CONTRIBUTING, CODE_OF_CONDUCT)
 Название легко запоминается, дает некоторое представление о том, чем занимается проект, не конфликтует с существующим проектом и не нарушает права на товарные знаки.
 Очередь задач актуальна, задачи четко организованы и помечены.
  Код 
 В проекте используются согласованные соглашения о коде и четкие имена функций/методов/переменных.
 Код четко прокомментирован, документированы намерения и крайние случаи.
 В истории изменений, проблемах или запросах на вытягивание нет конфиденциальных материалов (например, паролей или другой непубличной информации).
  Люди 
 Если вы физическое лицо:
 Вы поговорили с юридическим отделом и/или поняли политику вашей компании в отношении интеллектуальной собственности и открытого исходного кода (если вы где-то работаете)
 Если вы компания или организация:
 Вы говорили со своим юридическим отделом
 У вас есть маркетинговый план по анонсированию и продвижению проекта
 Кто-то занимается управлением взаимодействием с сообществом (отвечая на вопросы, просматривая и объединяя запросы на вытягивание)
 Не менее двух человек имеют административный доступ к проекту
 Ты сделал это! 
 Поздравляем с открытием вашего первого проекта.