Contributing
Please read the general guidelines on contributing to OpenRefine first, then review the information on reporting and tracking issues, and on making your first pull request below)
Reporting and tracking issues
If you need to file a bug or request a feature, create an Issue in the OpenRefine Github repository. Github issues should be used for reporting specific bugs and requesting specific features. If you just don't know how to do something using OpenRefine, or want to discuss some ideas, please:
Contributing to the documentation
We use Docusaurus for our docs. For small documentation changes, you should be able to edit the Markdown files directly and submit them as a pull request. A preview of the docs will be generated automatically.
But it is also possible to preview your changes locally.
We used Yarn to install Docusaurus, see docs/yarn.lock;
or see Docusaurus installation for how to seed a new docusaurus project.
You need to have Node.js installed, which includes npm. You also need to install Yarn before you can build the site:
npm install -g yarn
Once you have installed yarn, navigate to the docs directory & set-up the dependencies.
cd docs
yarn
Once this is done, generate the docs with:
yarn build
You can also spin a local web server to serve the docs for you. A browser window will open at http://localhost:3000 and will auto-refresh when you edit the source files:
yarn start
Your first code pull request
This describes the overall steps to your first code contribution in OpenRefine. If you have trouble with any of these steps feel free to reach out on the developer mailing list or the Gitter channel.
Install OpenRefine, learn to use it by following some tutorials or watching some videos. That will ensure you understand the user workflows and get familiar with the terminology used in the tool.
Fork the GitHub repository, clone it on your machine and set up your IDE to work on it. We have instructions for this.
Browse through the list of issues to find an issue that you find interesting. You should pick one where you understand what the problem is as a user, you can see why fixing it would be an improvement to the tool. It is also a good idea to pick an issue that matches your technical skills: some require work on the backend (in Java) or in the frontend (Javascript), often both. We try to maintain a list of good first issues which should be easier than others and should not require any difficult design decision.
Reproduce the issue locally, by following the steps described in the issue. You might need to locate a particular dialog, use a specific importer on a sample file, or follow any other user workflow. If you have followed all the steps described in the issue and cannot observe the issue mentioned, write a comment on the issue explaining that you are not able to reproduce it (perhaps it was fixed by another change).
Locate the code that is relevant for the issue you want to solve. Text search across files is often useful for that. For instance, if the issue you want to solve is about a dialog entitled "Columnize by key/values", you can search for "Columnize" in the entire source code. For more details about this technique, see this comment.
Study how the current code works. You might want to use a debugger to put breakpoints at the relevant locations (for inspecting the backend, use your IDE's debugger, for the frontend, use your browser's developer tools).
Create a git branch for your fix. The name of your branch should contain the issue number, and a few words to describe the topic of the fix, for instance "issue-1234-columnize-layout".
Make changes to the code to fix the issue. When you change the backend code, it's conveniant to also write one or more tests in Java to demonstrate the fix. You can imitate existing tests of comparable functionalities for that.
We now have functional tests. These are built with Cypress. They mimic a human user in front of a Chrome browser. If you change has a meaningful impact on the user interface, a functional test should probably be written.
If you made Java changes, run linting to make sure they conform to our code style, with
mvn formatter:format.commit your changes, using a message that contains one of the special words "closes" and "fixes" which are detected by Github, followed by the issue number, e.g. "closes #1234" or "fixes #1234", this will link the commit to the issue you are working on.
push your branch to your fork and create a pull request for it, explaining the approach you have used, any design decisions you have made.
Thank you!