For instructions on setting up a local developer's instance of Open Library, please refer to the Installation Guide. Also, refer to the Quickstart Guide.
Look through our issues related to contributing.
- Ask here to join our Open Library slack: internetarchive#686
- Join us for our Open Library Community Call every Tuesday @ 11:30am PT
- If you notice a set of entries on Open Library which need to be updated (possibly in bulk) please report them as an issue to https://github.com/internetarchive/openlibrary-client (the Open Library Client).
- In case you are looking to add data using MARC and ONIX records, possibly in bulk please do it via at https://github.com/internetarchive/openlibrary-bots (the Open Library Bots).
- If a task requires immediate fixing, please respond to its corresponding issue by asking if it can be promoted to
blockerusing the blocker issue label.
We usually discuss weekly goals via our Tuesday Community Call and using slack.
- Look for issues with labels such as
good first issueandeasy
- Our on-going tasks are tracked here: https://github.com/internetarchive/openlibrary/projects/1
- Our quarterly goals can be found on the projects board: https://github.com/internetarchive/openlibrary/projects
Whenever working on a new feature/hotfix/refactor, the first step is to make sure a corresponding issue exists. We then take this issue number and affix it to the branch name which we will use for development.
A branch name consists of the: issue number, whether it is a feature/hotfix/refactor, and a human readable slug, e.g:
123/refactor/simplifying-authentication-using-xauthn
With respect to client side patches, before submitting your patch you'll want to check it adheres to code styling rules and tests. We use npm to test our client side code.
npm install
npm test
If it passes your patch is ready for review!
Note, many issues can be fixed automatically without any manual work from your part using the following command:
npm run lint:fix
-
Pull Requests (PRs) should link to the issue they resolve. Please take the time to check whether someone has already raised the issue you are solving. At the very least PRs should contain enough detail in the description to explain the purpose of the PR; what feature it adds, or problem it solves. Please expect PRs without sufficient details to be rejected until an clear description of the benefit is added. Thank you for your contributions!
-
When your code is ready for review, please follow our Pull Request Template to close the corresponding Issue.