google summer of code
1.0.0
Recursos para o programa do Google Summer of Code.
Olá! E bem -vindo ao repositório de recursos do Google Summer of Code (GSOC) do Google do Google (GSOC).
O GSOC é um programa global que oferece novos colaboradores (com 18 anos ou mais) a oportunidade de ser pago por contribuir para um projeto de código aberto durante um período de três meses. Os colaboradores são pagos pelo Google para trabalhar sob a orientação de mentores de uma comunidade de código aberto. O GSOC é uma ótima oportunidade para aprender, desenvolver novas habilidades, criar conexões, adquirir experiência em trabalhar com uma equipe maior e frequentemente distribuída e ser compensado financeiramente por seus esforços.
Neste repositório, você encontrará informações sobre como se inscrever no GSOC e uma lista de idéias em potencial que poderiam servir de base para um projeto GSOC.
Espera-se que os colaboradores do GSOC trabalhem 350 horas (equivalente em tempo integral), 175 horas (equivalente em período parcial) ou 90 horas (equivalente a curto tempo) ao longo do programa. O cronograma padrão ocorre durante 3 meses (12 semanas) e pode ser divulgado por um período mais longo.
A data de início do programa não é negociável . Todos os colaboradores do GSOC devem iniciar o programa ao mesmo tempo.
Para se inscrever no GSOC com stdlib, você deve:
Lembre -se de que todos os aplicativos devem passar pelo sistema de aplicativos do Google e você deve enviar sua inscrição no site do Google . Se você não enviar sua inscrição no site do GSOC, não podemos aceitar sua inscrição.
A intenção do GSOC é fornecer uma maneira de novos colaboradores participarem e participarem do mundo do código aberto. Os colaboradores com maior probabilidade de serem selecionados e, finalmente, terem sucesso são aqueles que estão envolvidos na comunidade e esperam continuar seu envolvimento além da duração do programa GSOC. Em geral, para a maioria dos projetos, ser um bom membro da comunidade é mais importante do que ser um bom codificador .
Comunicar. A comunicação é provavelmente a parte mais importante do processo de aplicação. Converse com mentores e outros desenvolvedores de stdlib, ouça quando eles oferecem conselhos e demonstrem que você entendeu as sugestões deles incorporando seus comentários sobre o que está propondo. A falha em incorporar o feedback reduz significativamente sua chance de sucesso.
Leia as instruções. Sempre leia (e reline) todas as instruções ao enviar propostas. Não envie simplesmente um currículo, artigo científico, apresentação ou outro arquivo que não contenha nenhuma informação sobre o projeto que você gostaria de buscar. Não é garantido que a falta de acompanhamento de instruções leve à rejeição da proposta.
Ser profissional. Mostre respeito e demonstre que você levará o relacionamento de orientação a sério. Isso significa ouvir ativamente quando você recebe feedback e sempre valoriza o tempo de cada membro da comunidade Stdlib. A má comunicação e a falha em ler e seguir as instruções transmitem falta de respeito e falta de consideração pelo tempo do mentor, e nenhum mentor quer trabalhar com um colaborador que não exiba o profissionalismo necessário para garantir o sucesso de seu projeto e Seu crescimento pessoal como membro da comunidade Stdlib.
Se você tiver dúvidas, verifique primeiro se as perguntas já foram respondidas nas Perguntas frequentes do GSOC. Se você ainda tiver uma pergunta depois de consultar as perguntas frequentes do GSOC, poderá entrar em contato com o canal de elementos STDLIB.
Você pode usar o elemento para solicitar feedback sobre as idéias iniciais do projeto e obter ajuda ao começar a trabalhar com a base de código STDLIB. Lembre -se de que, quanto mais específicas e clara suas perguntas nos fóruns do stdlib, maior a probabilidade de obter uma boa resposta. É improvável que uma pergunta aberta ou vaga obtenha uma resposta útil.
Por exemplo, uma boa pergunta pode ser algo como
Estou interessado no Projeto X e fiz um pouco de pesquisa e descobri que os problemas Y e Z parecem relacionados. Com base nas minhas descobertas, A, B e C já estão implementadas, então eu gostaria de saber se seria razoável propor um projeto que alcançaria D, E e F.
Por outro lado, a seguinte pergunta é muito aberta e muito vaga para solicitar uma resposta significativa
Estou interessado no Projeto X. Por favor, ajude -me a trabalhar nisso.
Ao entrar em contato com o elemento, certifique -se de se apresentar para que possamos conhecê -lo. Algumas informações úteis para incluir
Antes de trabalhar no seu aplicativo GSOC, revise nossa lista de idéias para ver se você encontra um projeto que o excita. A lista de idéias existentes é fornecida para servir como inspiração e indicar quais direções podem ser boas para o stdlib.
Se você encontrar uma ideia existente que deseja perseguir, entre em contato conosco em nosso canal de elementos para discuti -lo primeiro! Sempre pergunte sobre essas idéias antes de trabalhar em aplicação para obter as informações mais recentes sobre o que já foi implementado e o que exatamente deve ser feito.
A lista de idéias é organizada por rótulos de acordo com as seguintes convenções:
Prioridade
high : idéias que são consideradas importantes em nosso roteiro.normal : idéias que não são urgentes, mas que seriam agradáveis por ter mais cedo ou mais tarde.low : idéias que são novas ou interessantes, mas com pouca lista de prioridades.Dificuldade
1 : Uma ideia adequada para alguém com pouca ou nenhuma experiência de JavaScript.2 : Uma ideia adequada para alguém com um conhecimento prático de JavaScript.3 : Uma ideia que provavelmente será desafiadora, mas gerenciável.4 : Uma ideia que provavelmente será desafiadora e tem objetivos ambiciosos.5 : Uma idéia que provavelmente será difícil de implementar com várias incógnitas.Tecnologia
javascript : uma ideia que envolve programação em JavaScript. Pelo menos algum JavaScript provavelmente será necessário para todas as idéias.nodejs : Uma ideia que requer desenvolvimento com Node.JS. Trabalhar com o Node.js provavelmente será necessário para a maioria, se não todas, idéias, como Node.js é o ambiente padrão para testes, benchmarking e desenvolvimento local.c : Uma ideia que envolve programação em C. Isso é necessário para complementos nativos do Node.js.fortran : Uma ideia que envolve programação em Fortran. Isso é necessário para trabalhar em ligações blas/lapack.html/css : Uma ideia que envolve o uso de HTML e CSS (por exemplo, se construir um aplicativo de front -end).jsx/react : Uma ideia que envolve programação com React JSX (por exemplo, se estiver trabalhando no site do Stdlib).native addons : uma idéia que envolve o desenvolvimento de complementos nativos do Node.js.typescript : uma ideia que envolve programação no TypeScript.Prioridade, dificuldade, tecnologia e área de tópicos não têm influência sobre as chances de uma idéia ser aceita. Todas as idéias são igualmente boas e suas chances de serem aceitas dependem apenas da qualidade do seu aplicativo .
Comprimento do projeto
O GSOC permite três comprimentos diferentes do projeto: 90 horas, 175 horas e 350 horas. Cada idéia deve indicar se a ideia é mais adequada para 90, 175 ou 350 horas.
Em alguns casos, podemos estender um projeto de 175 horas a um projeto de 350 horas, estendendo as idéias do que pode ser feito. Da mesma forma, em alguns casos, um projeto de 350 horas pode ser reduzido para um projeto de 175 horas, implementando apenas parte de uma idéia e deixando o restante para um projeto futuro. Em ambos os casos, se você deseja ajustar o comprimento do projeto, entre em contato conosco em nosso canal de elementos para discuti -lo primeiro!
Se você deseja enviar sua própria ideia, isso também é bem -vindo; Apenas certifique -se de propor sua ideia aos mentores do stdlib primeiro! Depois de entrar em contato, informaremos se a ideia já foi implementada, se a ideia implicar um trabalho suficiente para durar a duração do programa GSOC, se a ideia exigir muito trabalho para ser significativamente perseguido durante o GSOC, e se a A ideia está dentro do escopo do stdlib. As idéias não solicitadas e não discutidas têm menos probabilidade de serem aceitas.
O melhor projeto para você é o que você mais está interessado e conhecedor. Emoção e aptidão são dois ingredientes principais de um projeto de sucesso e ajudam a garantir seu compromisso e capacidade de ver um projeto até a conclusão. Portanto, se há algo pelo qual você é especialmente apaixonado e que você acredita que se alinha com o escopo e os objetivos do stdlib, ficaremos felizes em ouvir seu argumento!
Depois de discutir conosco em nosso canal de elementos e receber aprovação para enviar sua ideia, abra um problema que descreva sua ideia usando o modelo de problema de ideia .
Além da proposta por escrito, exigimos que todos os candidatos ao GSOC escrevessem um patch e o mesclaram no repositório principal do stdlib.
Levamos seus patches ao stdlib em consideração ao revisar sua proposta. Enviar um ou mais patches é a sua melhor oportunidade para demonstrar que você é capaz de fazer o que está incluído em sua proposta.
Para enviar um patch,
Fork o repositório stdlib.
Configure sua plataforma para desenvolver STDLIB (por exemplo, instalar Git, clonar seu repositório bifurcado, configurá -lo para rastrear o repositório STDLIB remoto a montante, instalar dependências e inicializar seu ambiente de desenvolvimento local). Nosso guia contribuinte o leva pela configuração do Git e detalha nossa maneira preferida de desenvolvimento.
Por favor , não envie patches através do editor da Web do Github. Você precisará aprender a usar o Git e desenvolver o stdlib localmente se o seu projeto for aceito. Reservar um tempo agora para usar o Git e desenvolver o Stdlib aumenta localmente sua chance de sucesso e ajuda a decidir se o STDLIB é um bom ajuste para você.
Encontre algo no stdlib que não funciona, precisa de melhorias ou seria uma adição útil. Se você precisar de inspiração, sinta -se à vontade para corrigir qualquer problema na lista de problemas que sejam bons para os colaboradores iniciantes.
Além dos problemas, pesquise FIXME ou TODO na base de código. Você pode usar grep da linha de comando com git grep "TODO" .
Você também pode brincar no STDLIB REPL e encontrar algo que precisa de consertar ou pode ser implementado.
Depois de encontrar algo, se um problema ainda não existir, abra um problema no rastreador de problemas do stdlib que descreve o problema e sua solução proposta.
Se o seu projeto usará um idioma que não seja JavaScript (por exemplo, C ou Fortran), você deve enviar patches que também usem esse idioma, a fim de demonstrar que você é proficiente nesse idioma.
Observe que seu patch deve estar relacionado ao código, não documentação. Embora as correções de documentação sejam sempre bem -vindas, elas não atendem ao requisito do patch.
E observe ainda que seu patch não precisa estar relacionado ao seu projeto proposto para atender ao requisito do patch. Para se familiarizar com o código em que você estaria trabalhando, você pode tentar corrigir um bug relevante no mesmo código ou similar, mas isso não faz parte do requisito do patch.
Publique seu patch para revisão por pares criando uma solicitação de tração no Github. Você deve enviar sua solicitação de tração através do Github (em oposição, por exemplo, colar um arquivo corrigido em um problema), pois essa é a maneira mais fácil de revisar seu código e fornecer feedback e é o que esperamos de um colaborador que trabalha em um Projeto GSOC.
Você deve enviar um patch que seja revisado com sucesso e fundido para atender ao requisito do patch. Não consideramos aplicativos sem patches mesclados com sucesso.
Um patch bem -sucedido demonstra sua proficiência técnica e sua capacidade de interagir com a comunidade Stdlib.
Depois de criar uma solicitação de tração no GitHub, os revisores do STDLIB revisarão seu código e potencialmente solicitarão alterações. Você deve abordar essas alterações.
Durante o processo de desenvolvimento e feedback, você deve sempre executar testes de unidade localmente para verificar o comportamento esperado.
Durante a revisão, seja paciente com revisores. Devido ao GSOC, pode haver várias solicitações de tração para revisar, e podemos demorar a revisar todas as solicitações de tração, especialmente se elas forem enviadas perto do prazo de inscrição. Você é fortemente incentivado a enviar suas solicitações de tração no início do processo de inscrição para dar a si mesmo a melhor chance de ter um patch mesclado antes do prazo de inscrição .
Embora tenha um patch mesclado antes que o prazo para o aplicativo seja preferido, se o seu patch ainda estiver em revisão, tudo bem. O que é crítico é que seu patch seja mesclado antes do prazo de aceitação .
Cabe a você responder ao nosso feedback em tempo hábil o suficiente para que seu patch seja mesclado antes do prazo de aceitação .
Em sua inscrição, forneça um breve resumo de suas contribuições ao stdlib até agora, incluindo o trabalho que ainda não foi mesclado. Esta deve ser uma lista de solicitações de tração e uma indicação sobre se cada solicitação de tração é mesclada, fechada ou ainda aberta. Se você fez contribuições significativas fora de suas solicitações de tração (por exemplo, revisando a solicitação de tração de outra pessoa), também poderá listar isso.
Observe que não toleraremos o plágio de nenhuma forma. Ao desenvolver seu aplicativo, faça -o escrevendo em suas próprias palavras .
Embora outros candidatos possam discutir e enviar propostas publicamente para a mesma idéia, você não deve elevar o conteúdo de suas propostas. Você deve escrever e propor o que você acha que é o melhor curso de ação para garantir um projeto de sucesso de acordo com uma linha do tempo que você acredita ser apropriada.
Se detectarmos que seu aplicativo contém conteúdo plagiado, rejeitaremos seu aplicativo sem revisão.
Além disso, embora reconheçamos que, para muitos colaboradores, o inglês pode não ser seu primeiro idioma, evite o uso de LLMs (por exemplo, chatgpt, etc.). Normalmente, podemos dizer quando os indivíduos confiam no LLMS para o conteúdo de aplicativos de geração automática (e contribuições de código!), E o que isso sinaliza para nós é que você não pode se incomodar em dedicar um tempo para escrever um aplicativo atencioso e que você provavelmente não será capaz de ganhar nossa confiança.
Os melhores candidatos são aqueles que são atenciosos, que prestam muita atenção aos detalhes e estão ansiosos e dispostos a aprender.
Este documento toma emprestado fortemente
Este documento pode ser reutilizado sob uma licença Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0).
