Contributing to an open source project takes many forms. Below are some of the ways you can contribute to Splink!
If you have a question about Splink, we recommended asking on our GitHub discussion board. This means that other users can benefit from the answers too! On that note, it is always worth checking if a similar question has been asked (and answered) before.
Is something broken? Or not acting how you would expect? Are we missing a feature that would make your life easier? We want to know about it!
When reporting issues please include as much detail as possible about your operating system, Splink version, python version and which SQL backend you are using. Whenever possible, please also include a brief, self-contained code example that demonstrates the problem. It is particularly helpful if you can look through the existing issues and provide links to any related issues.
Contributions to Splink are not limited to the code. Feedback and input on our documentation from a user's perspective is extremely valuable - even something as small as fixing a typo. More generally, if you are interested in starting to work on Splink, documentation is a great way to get those first commits!
The easiest way to contribute to the documentation is by clicking the pencil icon at the top right of the docs page you want to edit. This will automatically create a fork of the Splink repository on GitHub and make it easy to open a pull request with your changes, which one of the Splink dev team will review.
If you need to make a larger change to the docs, this workflow might not be the best, since you won't get to see the effects of your changes before submitting them. To do this, you will need to create a fork of the Splink repo, then clone your fork to your computer. Then, you can edit the documentation in the docs folder (and API documentation, which can be found as docstrings in the code itself) locally. To see what the docs will look like with your changes, you can build the docs site locally. When you are happy with your changes, commit and push them to your fork, then create a Pull Request.
We are trying to make our documentation as accessible to as many people as possible. If you find any problems with accessibility then please let us know by raising an issue, or feel free to put in a Pull Request with your suggested fixes.
Thanks for your interest in contributing code to Splink.
If this would be your first code contribution to Splink, please comment on the relevant GitHub issue before beginning work. Briefly explain why you want to work on the issue and what you plan to do.
Please wait for a maintainer to confirm that a pull request would be welcome and to agree its scope. An open issue does not, by itself, mean that we are ready to accept a pull request for it because our main constraint is often the time required to review, test and maintain a change, rather than the time required to implement it.
We particularly welcome contributions from people who use Splink themselves and have practical problems they wish to address with the library.
Established contributors do not normally need explicit approval for small, focused changes. Substantial changes, new features and changes to public behaviour should still be discussed with the team first.
Once the work has been agreed:
- comment on the issue to say that you are working on it;
- open a draft pull request early;
- keep the change focused and as small as reasonably possible.
Pull requests that have not followed this process may be closed without detailed review.
To get set up for development locally, see the development quickstart.
It is fine to use AI assistance to help with your PR. Please observe the following guidance:
- External contributors should declare any significant use of AI in their PR.
- We ask that the PR description and all comments and interactions with the Splink team are written by yourself, not by AI