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:
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
or see Docusaurus installation for how to seed a new docusaurus project.
npm install -g yarn
Once you have installed yarn, navigate to the
docs directory & set-up the dependencies.
Once this is done, generate the docs with:
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:
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.
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
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.