We welcome your skills and enthusiasm at the gdsfactory project!. There are numerous opportunities to contribute beyond writing code. All contributions, including bug reports, bug fixes, documentation improvements, enhancement suggestions, and other ideas are welcome.

If you have any questions on the process or how to fix something feel free to ask us! The recommended place to ask a question is on GitHub Discussions, but we also have a gitter matrix channel that you can use with any matrix client (such as element) and a mailing list

Where to start?#

You can fork the repo, work on a feature, and then create a Pull Request to merge your feature into the main branch. This will benefit other project community members and make you famous :).

Take a look at the open issues to find issues that interest you. Some issues are particularly suited for new contributors by the good first issue label where you could start out. These are well documented issues, that do not require a deep understanding of the internals of gdsfactory.

Here are some other ideas for possible contributions:

  • Documentation, tutorials or code improvements. Just find a typo and submit a PR!

  • Design/verification/validation improvements.

  • A new device that you found on a paper so you can use it on your next tapeout. It helps get citations as other people start using or building on top of the work from the paper.

The workflow is:

  • Fork the repo. This creates a copy into your GitHub account namespace. git clone it into your computer and install it.

  • git add, git commit, git push your work as many times as needed. Make sure GitHub Actions pass so it all keeps working correctly.

  • open a Pull request (PR) to merge your improvements to the main repository.

git flow

Code of Conduct#

This project is a community effort, and everyone is welcome to contribute. Everyone within the community is expected to abide by our code of conduct


We use towncrier for tracking changes and generating a changelog. When making a pull request, we require that you add a towncrier entry along with the code changes.

towncrier create <PR number>.<change type>

Where change type can be removed, deprecated, added, changed, fixed

Running this will create a file in the .changelog.d directory with a filename.

Then before doing a new release we run

towncrier build --version=<version-number>

Where <version-number> is the expected version number of the release