google summer of code
1.0.0
Ресурсы для программы Google Summer of Code.
Привет! И добро пожаловать в хранилище ресурса Google Summer of Code (GSOC).
GSOC - это глобальная программа, которая предлагает новым участникам (которому 18 лет и старше) возможность оплатить за участие в проекте с открытым исходным кодом в течение трехмесячного периода. Участникам платят Google за работу под руководством наставников из сообщества с открытым исходным кодом. GSOC - отличная возможность учиться, развить новые навыки, наладить связи, приобрести опыт работы с более крупной и часто распределенной командой, и получить финансовую компенсацию за ваши усилия.
В этом хранилище вы найдете информацию о том, как подать заявку на GSOC и список потенциальных идей, которые могут послужить основой для проекта GSOC.
Ожидается, что участники GSOC будут работать либо 350 часов (полный рабочий день), 175 часов (неполный рабочий день), либо 90 часов (краткосрочный эквивалент) в течение программы. График по умолчанию проходит в течение 3 месяцев (12 недель) и потенциально может быть распределен в течение более длительного периода.
Дата начала программы не подлежит обсуждению . Все участники GSOC должны начать программу одновременно.
Чтобы подать заявку на GSOC со Stdlib, вы должны:
Пожалуйста, помните, что все приложения должны пройти через систему приложений Google, и вы должны подать заявку на веб -сайте Google . Если вы не подаете заявление на веб -сайте GSOC, мы не можем принять ваше заявление.
Цель GSOC - предоставить новым участникам возможность присоединиться и участвовать в мире открытого исходного кода. Скорее всего, участники будут отобраны и в конечном итоге преуспевают, - это те, кто участвует в сообществе и надеется продолжить свое участие до продолжительности программы GSOC. В целом, для большинства проектов быть хорошим членом сообщества важнее быть хорошим кодером .
Общаться. Общение, вероятно, является наиболее важной частью процесса подачи заявления. Поговорите с наставниками и другими разработчиками STDLIB, послушайте, когда они предлагают советы, и продемонстрируйте, что вы поняли их предложения, включив их обратную связь в то, что вы предлагаете. Неспособность включить обратную связь значительно снижает ваши шансы на успех.
Прочитайте инструкции. Всегда читайте (и перечитывайте) все инструкции при отправке предложений. Не просто отправляйте резюме, научную статью, презентацию или другой файл, который не содержит никакой информации о проекте, который вы хотели бы продолжить. Неспособность следовать инструкциям гарантированно приведет к отказу предложения.
Быть профессиональным. Покажите уважение и продемонстрируйте, что вы серьезно относитесь к наставничеству. Это означает активное слушание, когда вы получаете отзывы и всегда оцениваете время каждого участника в сообществе STDLIB. Плохое общение и неспособность читать и следовать инструкциям. их личный рост как член сообщества STDLIB.
Если у вас есть вопросы, сначала проверьте, были ли на вопросы уже ответы на FAQ GSOC. Если у вас все еще есть вопрос после консультации с FAQ GSOC, вы можете протянуть руку на канале элемента STDLIB.
Вы можете использовать элемент для получения обратной связи о первоначальных идеях проекта и для получения помощи, когда вы начинаете работать с кодовой базой STDLIB. Имейте в виду, что чем более конкретные и прояснить ваши вопросы на форумах Stdlib, тем больше вероятность того, что вы получите хороший ответ. Открытый или смутный вопрос вряд ли получит полезный ответ.
Например, хороший вопрос может быть чем -то вроде
Я заинтересован в Project X, и я провел немного исследования и обнаружил, что проблемы Y и Z кажутся связанными. Основываясь на моих выводах, A, B и C уже реализованы, поэтому я хотел бы знать, было бы разумно предложить проект, который достигнет D, E и F.
Напротив, следующий вопрос слишком открыт и слишком расплывчат, чтобы получить значимый ответ
Меня интересует проект X. Пожалуйста, помогите мне поработать над этим.
Принимая руку по элементу, обязательно представьте себя, чтобы мы могли познакомиться с вами. Некоторые полезные материалы информации, чтобы включить
Прежде чем работать над своим приложением GSOC, просмотрите наш список идей, чтобы увидеть, найдете ли вы проект, который вас волнует. Список существующих идей предоставляется для того, чтобы служить вдохновением и указать, какие направления могут быть хорошими для STDLIB.
Если вы найдете существующую идею, которую вы хотите продолжить, пожалуйста, обязательно свяжитесь с нами в нашем канале элементов, чтобы сначала обсудить ее! Всегда не забудьте спрашивать об этих идеях до работы над приложением, чтобы получить последнюю информацию о том, что уже реализовано и что именно должно быть сделано.
Список идей организован метками в соответствии со следующими конвенциями:
Приоритет
high : идеи, которые считаются важными в нашей дорожной карте.normal : идеи, которые не срочно, но было бы неплохо иметь раньше, чем позже.low : идеи, которые являются новыми или интересными, но низкие в нашем списке приоритетов.Сложность
1 : Идея, подходящая для кого -то, у которого мало или без JavaScript.2 : Идея, подходящая для кого -то с рабочим знанием JavaScript.3 : идея, которая может быть сложной, но управляемой.4 : Идея, которая может быть сложной задачей и имеет амбициозные цели.5 : идея, которая может быть трудно реализовать с несколькими неизвестными.Технология
javascript : идея, которая включает в себя программирование в JavaScript. По крайней мере, какой -то JavaScript, вероятно, потребуется для всех идей.nodejs : идея, которая требует разработки с Node.js. Работа с node.js, вероятно, потребуется для большинства, если не все идеи, так как Node.js является средой по умолчанию для тестирования, сравнительного анализа и локальной разработки.c : Идея, которая включает в себя программирование в C. Это требуется для нативных надстройки Node.js.fortran : Идея, которая включает в себя программирование в Фортране. Это требуется для работы над привязками BLAS/LAPACK.html/css : идея, которая включает в себя использование HTML и CSS (например, при создании фронтального приложения).jsx/react : идея, которая включает в себя программирование с React JSX (например, при работе на веб -сайте STDLIB).native addons : идея, которая включает в себя развитие Node.js Native Addons.typescript : идея, которая включает в себя программирование в TypeScript.Приоритет, сложность, технология и тематическая область не имеют никакого отношения к шансам принятия идеи. Все идеи одинаково хороши, и ваши шансы на принятие зависят исключительно от качества вашего приложения .
Длина проекта
GSOC допускает три различных длины проекта: 90 часов, 175 часов и 350 часов. Каждая идея должна указывать, лучше ли идея подходит для 90, 175 или 350 часов.
В некоторых случаях мы можем расширить 175 -часовой проект на 350 -часовой проект, расширив идеи того, что можно сделать. Точно так же в некоторых случаях 350 -часовой проект может быть сокращен до 175 -часового проекта, только внедрив часть идеи и оставив остальную часть для будущего проекта. В любом случае, если вы хотите отрегулировать длину проекта, пожалуйста, свяжитесь с нами в нашем элементе, чтобы сначала обсудить ее!
Если вы хотите представить свою собственную идею, это также приветствуется; Просто обязательно предложите свою идею сначала наставниках Stdlib! После обращения, мы сообщим вам о том, была ли идея уже реализована, если идея повлечет за собой достаточно работы, чтобы продолжить продолжительность программы GSOC, если идея требует слишком много работы, чтобы быть значительно выполненной во время GSOC, и если Идея находится в рамках STDLIB. Незапрошенные, не представленные идеи менее склонны к принятию.
Лучший проект для вас - это тот, который вас больше всего интересует и знает. Волнение и способность являются двумя ключевыми ингредиентами успешного проекта и помогают обеспечить вашу приверженность и способность видеть проект до завершения. Так что, если есть что -то, чем вы особенно увлечены и что, по вашему мнению, соответствует масштабу и целям Stdlib, мы будем рады услышать ваш шаг!
После обсуждения с нами в нашем канале элементов и получения разрешения на представление вашей идеи, пожалуйста, откройте проблему, которая описывает вашу идею, используя шаблон проблемы Idea .
В дополнение к письменному предложению, мы требуем, чтобы каждый заявитель GSOC написал патч и объединился в основной репозиторий STDLIB.
При просмотре вашего предложения мы проводим ваши патчи в STDLIB . Отправка одного или нескольких патчей - ваша лучшая возможность продемонстрировать, что вы способны сделать то, что включено в ваше предложение.
Отправить патч,
Форк репозиторий Stdlib.
Установите свою платформу для разработки stdlib (например, установите GIT, клонируйте свой раздвоенный репозиторий, установите ее для отслеживания удаленного репозитория STDLIB, установить зависимости и инициализацию вашей локальной среды разработки). Наше руководящее руководство проведет вас через настройку GIT и подробно описывает наш предпочтительный способ развития.
Пожалуйста, не отправляйте исправления через веб -редактор GitHub. Вам нужно будет узнать, как использовать GIT и разрабатывать stdlib локально, если ваш проект будет принят. Потратив время на использование GIT и развитие Stdlib локально увеличивает ваши шансы на успех и помогает вам решить, подходит ли STDLIB для вас.
Найдите что -нибудь в Stdlib, которое не работает, нуждается в улучшении или будет полезным дополнением. Если вам нужно вдохновение, не стесняйтесь исправить любую проблему в списке проблем, которые хороши для участников первых.
В дополнение к вопросам поиск FIXME или TODO в кодовой базе. Вы можете использовать grep из командной линии с git grep "TODO" .
Вы также можете поиграть в STDLIB Repl и найти что -то, что требует исправления или может быть реализовано.
После того, как вы что -то нашли, если проблема еще не существует, откройте проблему на трекере выпуска Stdlib, описывающей проблему и предлагаемое вами решение.
Если ваш проект будет использовать язык, отличный от JavaScript (например, C или Fortran), вам также следует отправить исправления, которые также используют этот язык, чтобы продемонстрировать, что вы обладаете опытом в этом языке.
Обратите внимание, что ваш патч должен быть связан с кодом, а не документация. Хотя исправления документации всегда приветствуются, они не удовлетворяют требования к патчу.
И далее обратите внимание, что ваш патч не должен быть связан с предлагаемым вами проектом, чтобы удовлетворить требование к патчу. Чтобы ознакомиться с кодом, над которым вы будете работать, вы можете попытаться исправить соответствующую ошибку в том же или аналогичном коде, но это не является частью требования к патчу.
Опубликуйте свой патч для рецензирования, создав запрос на притяжение на GitHub. Вы должны отправить свой запрос на притяжение через GitHub (в отличие от, например, вставка исправленного файла), поскольку это самый простой способ просмотреть ваш код и предоставить обратную связь, и это то, что мы ожидаем от участника, работающего на GSOC Project.
Вы должны отправить патч, который успешно рассмотрен и объединен, чтобы удовлетворить требование к патчу. Мы не рассматриваем приложения без успешных объединенных патчей.
Успешный патч демонстрирует ваше техническое мастерство и вашу способность взаимодействовать с сообществом Stdlib.
После того, как вы создали запрос на вытягивание на GitHub, рецензенты Stdlib будут просмотреть ваш код и потенциально запросить изменения. Вы должны решить эти изменения.
На протяжении всего процесса разработки и обратной связи вы всегда должны проводить модульные тесты локально, чтобы проверить ожидаемое поведение.
Во время обзора, пожалуйста, будьте терпеливы с рецензентами. В связи с GSOC может быть несколько запросов на привлечение, и мы можем медленно пересматривать все запросы на притяжение, особенно если они представлены вблизи крайнего срока подачи заявок. Вам настоятельно рекомендуется отправить свои запросы на привлечение (ы) на ранней стадии в процессе подачи заявления, чтобы дать себе лучший шанс на объединенный патч до крайнего срока подачи заявления .
В то время как патч объединился до того, как крайний срок подачи заявления предпочтительнее, если ваш патч все еще находится под проверкой, это нормально. Важно, чтобы ваш патч был объединен до крайнего срока принятия .
Вы должны ответить на наши отзывы достаточно своевременно, чтобы ваш патч был объединен до крайнего срока принятия .
В вашей заявке, пожалуйста, предоставьте краткое изложение вашего вклада в STDLIB, включая работу, которая еще не была объединена. Это должен быть список запросов на притяжение и указание относительно того, объединен, закрыт, закрыт или все еще открыт. Если вы внесли значительные взносы за пределами ваших запросов на привлечение (например, просмотр чужой запрос на привлечение), вы также можете перечислить это.
Обратите внимание, что мы не будем терпеть плагиат в любой форме. При разработке вашего приложения сделайте это, написав своими словами .
В то время как другие заявители могут публично обсуждать и представить предложения для той же идеи, вы не должны поднимать контент из их предложений. Вы должны написать и предложить, что, по вашему мнению, является лучшим курсом действий для обеспечения успешного проекта в соответствии с временной шкалой, которая, по вашему мнению, является подходящей.
Если мы обнаружим, что ваше приложение содержит плагиат контент, мы отклоним ваше приложение без проверки.
Кроме того, хотя мы признаем, что для многих участников английский язык не может быть вашим первым языком, пожалуйста, избегайте использования LLMS (например, CHATGPT и т. Д.). Обычно мы можем сказать, когда люди полагаются на LLMS для автоматического поколения контента приложения (и кодовых вкладов!), И что это сигнализирует нам, что вы не можете потратить время на то, чтобы написать вдумчивое заявление, и что вы, вероятно, не будете способен завоевать наше доверие.
Лучшие кандидаты - это те, кто вдумчивает, которые обращают пристальное внимание на детали, а кто стремится учиться.
Этот документ заимствует у
Этот документ может быть повторно использован по лицензии Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).
