Thank you for your interest in contributing to Openverse! This document is a set of guidelines to help you contribute to this project.
By participating in this project, you are expected to uphold our Code of Conduct.
Please consult the README file at the root of this repository.
Please read the processes in our general Contributing Code guidelines on the Creative Common Open Source website. It contains some general instructions that should be followed when contributing to any of the WP Photos open-source repositories.
If you find a bug, please open an issue in this repository describing the bug. You can file a bug here. You will see a bug report template with the required information you should provide.
Please see our testing guidelines for general instructions and recommendations for how to test the application.
If you have an idea of a new feature or change to how the Openverse frontend works, please file an issue so we can discuss the possibility of that change or new feature being implemented and released in the future. This lets us come to an agreement about the proposed idea before any work is done.
If you'd like to build a new feature but don't have a specific idea, please check out the historic public roadmap. Choose something from the pipeline of ideas and follow the same process as above.
Before you start writing code, make sure there is an issue open. Pull requests
without a link to an existing issue won't be merged. All pull requests must
target the main branch of the repository.
If you want to get started contributing code to this project but don't know exactly what to work on, we compiled a good list of issues labeled as 'good first issues' which are small in scope and not so complex to solve. There are also issues labeled as 'help wanted' which can be a bit more complex but are good examples of things we are currently accepting help from the community.
Any code modifications will have to be accompanied by the appropriate unit tests. This will be checked and verified during code review. Once the pull request is opened, our CI server will run the unit test suite and run a code linter to verify that the code follows the coding guidelines.
If you want to run the unit tests and linter on your machine, run the following commands:
pnpm test:unit for unit tests
pnpm lint for linter.
You can also configure your editor of choice with a ESLint plugin so you can get the linter feedback as you write code.
We use native TypeScript everywhere we can. Currently there are very few edge cases where it is not possible to use TypeScript, primarily in older components that do not use the composition-api or that rely on Nuxt's auto-component importing.
TypeScript support for Vue 2 is limited to composition-api based components
(i.e., components that use defineComponent and declare a setup function). If
you'd like to use TypeScript for a Vue SFC, add lang="ts" to the script tag
and add the file to the tsconfig.json includes array.
Elsewhere, simply use (and prefer) the .ts extension for all new files.
See Vue's official documentation about IDE support for Vue with TypeScript for guides on how to set up your editor.
Some older modules use JSDoc flavored TypeScript. This was primarily used before the project had included support for native TypeScript. Please do not extend the use of JSDoc TypeScript outside of modules that already use it. If you feel so inclined, we always welcome PRs updating such modules to native TypeScript.
We use Tailwind CSS for writing styles. There are some legacy components that have been written in "hand-written" CSS. Our aim is to eventually re-write these using Tailwind classes.
Our Tailwind configuration lives at
./tailwind.config.js and is a useful reference for
Openverse specific spacing and color classes. Please refer to the official
Tailwind CSS documentation for a detailed and
searchable list of the available classes. At times you'll need to cross
reference this documentation with our specific configuration in the
tailwind.config.js file.
We also use the Tailwind CSS RTL plugin to make writing right-to-left (RTL) styles seamless. Most use cases of the right/left based classes should use the start/end variants introduced by the plugin instead.
Feel free to join us on Slack and discuss the project with the engineers and community members on #openverse.