Contributing ​

Thanks for your interest in contributing to Open Library! This guide explains how to choose work, coordinate with maintainers, and submit a pull request successfully. For setup instructions, see the Quick Start guide.

How contributing works ​

1. Find an unassigned issue
2. Comment to request assignment and describe your plan
3. Wait for assignment
4. Complete the work and test it
5. Open a self-contained PR
6. Respond to review comments clearly

Before you begin ​

Please request assignment to an issue before starting work. Our maintainers triage issues weekly (or immediately for high-priority items) to ensure your contribution aligns with current priorities and prevent duplicate effort.

When requesting assignment:

• Focus on one meaningful issue at a time rather than requesting many
• Explain the problem and your proposed approach in your own words
• Mention which files or components you plan to modify

Use AI tools responsibly. Be prepared to explain the problem and your proposed solution in your own words.

Please respect current assignments. If someone is already assigned or actively working on an issue, coordinate on the issue before starting related work.

Choosing work ​

Good First Issues ​

Browse Good First Issues — ideal for first-time contributors.

• Only work on issues that are not assigned to anyone
• Request assignment before you start
• If an assigned issue has been inactive for 2 weeks, ask whether it can be reassigned

When no Good First Issues are available ​

• Browse unassigned issues sorted by recently updated
• Revisit older issues and confirm they're still relevant before starting
• Ask in Slack — request an invite on our volunteers page
• Attend the weekly community call to hear about current priorities

Opening a pull request ​

• Test your changes before opening a PR so reviewers can focus on the code rather than basic setup issues
• Mark the PR as draft if it's still in progress
• Complete the pull request template fully so reviewers have the context they need
• Make PRs self-contained so reviewers can understand them without extra context

Review comments are a normal part of the process. Most PRs need at least one round of changes before merge.

Responding to review ​

• Reply to each review comment with the change you made or why you chose a different approach
• Resolve all review comments before requesting another review
• When resolving a comment, reply with "DONE" or "WON'T FIX because ..."
• If the issue has a Lead: @username label, that person is usually the best reviewer to tag

If you haven't heard back within one week of requesting assignment, feel free to tag the Lead: on the issue.

Community & getting help ​

Please read our Code of Conduct. We're a non-profit, open-source, inclusive project committed to creating a safe place for everyone.

Get involved:

• Join Slack — request an invite on our volunteers page
• Attend weekly community calls — check the community call page for times
• Review the Open Library Roadmap to understand current priorities