Contributor Guidelines

Welcome! We're so glad you're interested in contributing to the Zooniverse mobile app! Here's how it works:

1. Choose an issue. We have several issues for open source contributors documented here in this GitHub project board.. If you have an idea of your own, please create an issue first. Once you have your issue, feel free to get in touch with us ([email protected]) to let us know, or ask questions, or collect additional details about the issue.

2. Fork the repo and pull it down. Please make sure that you can get it running! The instructions in the README should be all you need. Please let us know if they aren't.

3. Please make sure that your solution works on both iOS and Android. We've run into many surprises where something worked on one and not the other: that's what's hard about dual platform development!

4. Please also include tests for any logic you introduce. We use snapshot tests for components, but for methods that do any real calculating or figuring, please pull them into their own file so it is easier for you to unit test! You can find examples of unit tests and snapshot tests in the existing code base.

5. When you open a pull request, please fill out the template description for the PR. It will ask you to link the PR to the issue that it fixes. It also has a checklist of things you should check and asks you what the reviewer should check and/or be able to do with this PR. The template also asks you for your goals. We want to take those into account when we review your PR so we can help you achieve them!

For example, here are some of our goals, and things we'll look for when reviewing your code:

1. Legibility: This is an open source app. Are other maintainers likely to understand your solution?

2. Simplicity: We know that sometimes you might need to do a complex calculation, and that's fine. We want to avoid situations that have a large number of edge cases, or edge cases that are going to grow. Here is an example of a PR where we strategically rewrote something for simplicity.

3. Accessibility: We want the app to be fun to use for folks of all ages, in all kinds of environments. We also want folks with disabilities to be able to contribute to science on our app. Here is an example of a PR where we changed something for accessibility.

4. Robustness: Whatever it is, it should be hard to break. One time we accidentally made a release with an easy-to-break button, and we deployed it in a museum exhibit. When the exhibit opened, hundreds of children got to engage with the app, and immediately found the vulnerability 😂. Here's where we fixed it.