Each component contains a
CONTRIBUTING.md, generally in the
docs/ folder. The master version is kept in our maintainers repository for reference.
When it comes to figuring out what to contribute and where, our recommendation is invariably: choose a component you use and are interested in, and start there. If the component looks too complex, try a different one. Once you find a component you’re interested in contributing to, check to see if there are any open issues you think you might be able to address, and start by writing a unit test that reproduces the issue. You can even send a pull request with just the unit test, and ask the original reporter to review it to ensure it accurately reproduces the scenario reported. From there, figure out if you think you can provide a fix for it, and push the changes to the same branch so they’re picked up by the pull request. Pay attention to the results of continuous integration, and click through to failed builds to see what errors were reported; fix those, push, and repeat. As maintainers come through and provide feedback, incorporate the feedback, push the changes, repeat.