🇺🇸 English version
Contributing to open-source is like joining a stranger's party. Before jumping in with your own suggestions, start by learning how to read the room. This increases the chances that your ideas are noticed and heard. Every community is different, so start by familiarizing yourself with people, documents, tools, ways of working, and so on.
We love your input! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
We use github to host code, to track issues and feature requests, as well as accept pull requests.
We Use Github Flow, So All Code Changes Happen Through Pull Requests
Pull requests are the best way to propose changes to the codebase (we use Github Flow). We actively welcome your pull requests:
- Fork the repo and create your branch from
main. - If you've added code that should be tested, add tests.
- If you've changed APIs, update the documentation.
- Ensure the test suite passes.
- Make sure your code lints.
- Issue that pull request!
In short, when you submit code changes, your submissions are understood to be under the same license that covers the project. Feel free to contact the maintainers if that's a concern.
We use GitHub issues to track public bugs. Report a bug by opening a new issue; it's that easy!
This is an example of a bug report I wrote, and I think it's not a bad model. Here's another example from Craig Hockenberry, an app developer whom I greatly respect.
Great Bug Reports tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can. My stackoverflow question includes sample code that anyone with a base R setup can run to reproduce what I was seeing
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
People love thorough bug reports. I'm not even kidding.
I'm again borrowing these from Facebook's Guidelines
- We use linting with ESLint
- 2 spaces for identation, do not use tabs
- Use of semicolon
; - Wrap the properties of arrow functions around parentheses
- Add a space before and after the arrow function
=> - Do not use duplicate imports
- You should run
yarn lintto lint your code before reviewing a PR - Your code will be run against our CI
- Your code should pass our CI pipeline to be able to be merged against the main branch
By contributing, you agree that your contributions will be licensed under the project's license.
This document was adapted from the open-source contribution guidelines for Facebook's Draft
🇧🇷 Versão em português
Lembre-se: contribuir para novos projetos é que nem participar de uma festa com pessoas que você não conhece, então sugerimos que primeiro você se familiarize com as pessoas (contribuidores e mantenedores), as documentações, ferramentas e os métodos de trabalho que estão sendo utilizados.
Nós adoraríamos sua sugestão! Queremos facilitar o processo para que você possa contribuir para este projeto da forma mais fácil e objetiva o possível, independente de qual seja sua contribuição. Sugerimos que você:
- Reporte um bug
- Discuta o estado atual de um código
- Submeta uma correção
- Proponha novas funcionalidades
- Se torne um mantenedor
Nós usamos o Github para desenvolver, para monitorar os bugs, ouvir as sugestões de melhorias e aceitar pull requests.
Nós usamos Github Flow, então todos os códigos mudamos através de pull requests
Pull requests são a melhor forma de propôr mudanças para o códigobase (usamos Github Flow). Nós ativamente aceitamos suas pull requests:
- Faça um fork do repositório
- Se você tiver adicionado código que deve ser testado, adicione testes.
- Se você tiver mudado APIs, atualize a documentação.
- Verifique se o teste está correto.
- Verifique se seu código linta.
- Envie sua pull request!
Resumindo, quando você enviar código novo, suas alterações serão consideradas sob a mesma licença que o projeto. Se você tem alguma dúvida, entre em contato com o mantenedor.
Nós utilizamos Github's issues para reportar bugs. Reporte um bug reportando um novo issue; simples assim!
Esse é um exemplo de um bug report que eu escrevi. Aqui está outro exmplo do Craig Hockenberry.
** Bons bug reports** tendem a ter:
- Um resumo e/ou background
- Passos para reproduzir
- Seja específico!
- Dê código de exemplo se possível. Meu Stackoverflow question inclui código de exemplo que qualquer pessoa com um ambiente base R pode executar para reproduzir o que eu estava verificando
- O que você esperava que acontecesse
- O que aconteceu
- Anotações (que possa incluir uma razão por que você acha que isso possa ter acontecido, ou coisas que você tentou que não funcionaram)
Todo mundo gosta de explicações detalhadas sobre bugs!
- Utilizamos o linter ESLint
- 2 espaços para identação, não use tabs
- Uso de ponto e vírgula
; - Envolver as propriedades das arrow functions por volta de parenteses
- Adicionar um espaço antes e depois da arrow function
=> - Não usar imports duplicados
- Você deve rodar
yarn lintpara verificar que o código está consistente antes de subir um pull request - O seu código será verificado em nosso CI e deve passar todas as etapas
- Seu código deve passar em nosso pipeline do CI antes de ser mergeado na main
Ao contribuir, você aceita que suas contribuições serão licenciadas sob a mesma licença que o projeto.
Esse documento foi adaptado do projeto open-source Facebook's Draft