Taxonomy Maintenance

Introduction

Taxonomies play a central role in Open Food Facts. Have a look at Taxonomies for more details.

If you want to help building, extending and maintaining the taxonomies, a few options from simple to complicated, are listed here.

Just tell us

The most easy and quick way to contribute to the taxonomies, is to tell us about an issue, even if it is not related to taxonomies. If you see an ingredient that is not recognised, a category that is not translated or a NOVA-score that is not computed, it might be a taxonomy issue.

Tell us on Twitter with #openfoodfacts, in our Facebook channel, mail us on contact@openfoodfacts.org, or on Slack. And we will take care of it.

Editor

A special editor has been developed to help us.

Github

The most complicated way goes through Github. This option is only for those that are familiar with computers, downloading applications and editing large files.

Installing Github-client

In principle it is possible to do the work on the Github-website. Unfortunately the files related to taxonomies grew large and working on the website is not always possible. To circumvent this you need to install a Github-client: Github Desktop (Linux version).

You also need a editor to work with the large text files. Try Notepad++ on Windows or TextMate on MacOS.

Once you have these installed, you are ready to go.

Pull request

After making your changes and pushing them to your fork on Github, it is time to ask them to move them to the OFF-system. However before you do this, pull the latest official version into your branch and check for conflicts (see further).

For this you have to create a Pull Request. The command for this is in your Github-client.

In creating a pull request you have to define a title (prefix with chore:)and a description with why and what you changed.

After submitting your request the system will check the changes you made in order to make sure that they do not break things. If the suggested change does break some things, the team help you to get things resolved. Sometimes a suggested change might imply a change on the (break) testing.

Somebody from the team will have a look at your changes to make sure they are fit for purpose. A team member can make some suggestions or accept the change right away. If a suggestion implies that you have to change something: do the edit in your client, push the changes to your fork and the testing process will restart.

You might encounter the warning that there are conflicts. This happens when someone has changed the file you were working on while you were working on it. The system is then confused as it no longer knows which changes it should use. To prevent this you can pull the latest official version to your Github-client. Then you can resolve it on your side. If you are lost here (very easy), let someone from the team help you.

After you changes have been accepted and the pull request is closed by OFF, throw away the branch on your side. Try to start each new edit-session with a new branch.