Getting Started

The first thing to do before anything is to join the KiCad Developers Mailing List. Here you can ask broad questions and present your ideas or plans if it’s beyond a bug fix.

KiCad uses Git for source control.

If you are new to git, it is highly suggested you find and follow the many tutorials available online like this one and/or read the git documentation.

We also are dedicated to using GitLab as our primary hosting platform for our Git repositories.

All repos can be found here.

The repository for the main application can be found here

Follow the instruction in the documentation corresponding to your platform to set up a working build environment and successfully build KiCad from source.

To familiarize yourself with the code base you can read the documentation generated by Doxygen. When submitting new code, please remember to update the documentation descriptions. You can run make doxygen-docs to generate the documentation locally.

The latest version of the same docs are also available on the Jenkins server, see KiCad Developer Docs for the C++ API.

You can also find various developer notes in the Doxygen docs, see the related pages.

After you make changes, please ensure your code meets the KiCad Coding Style Policy.

Your commit messages should follow the rules stated in the KiCad Commit Message Format Policy

If you feel like working on the user interface, you will find useful reading the User Interface Guidelines.

It’s important for us to keep the codebase readable by all developers. Your patches will not be accepted until adhere to the rules set forth in these policies.

Programming is an iterative process, don’t worry if you have to go back and make changes to your patches, we all do.

All patches should be submitted as a merge request on GitLab. See this How to create a merge request for new users on how.

Note: There is a GitHub mirror of KiCad but all pull requests are ignored, we only accept changes on GitLab

The GitLab repository has Continous Integration (CI) enabled. This means it automatically runs processing steps on incoming commits to do a few tasks from making sure the code can compile to coding style policy.

You can find the status of the CI job on the merge request page and see its output. If you need help, you may ask in the merge request for a developer to comment on what to do to resolve it.