How can I help improve KiCad?
KiCad is a completely volunteer- and community-driven project. No one works full-time on developing, testing and improving KiCad* . Instead, we depend on those people (like you) who use the software to be an active member in improving it.
How can you help?
Click on the arrows below to learn how to contribute in the following ways:
Bug Reports
Bug reports are the single most helpful thing that you can do to improve the quality of KiCad.
Our core development team is only a handful of volunteers, so we won’t run into every issue. If KiCad crashes for any reason, that’s a bug. If KiCad produces invalid gerber or other production files, that’s a bug. If you are using it and something unexpected happens, that is probably a bug. If the behavior is bugging you, that might be a bug. All of these cases should be reported to the bug tracker.
Don’t worry about pestering or annoying the developers. We want to know when KiCad isn’t working correctly. And, chances are, if it doesn’t work right for you, it doesn’t work right for others as well.
Here’s how to report a bug (and check for it already being reported)
-
Create an account at Gitlab
-
Go to the bug tracker
-
Search for your bug
- If your bug already exists, don’t report it again.
- Instead, you should give a thumb up. This will let the developers know that this bug is more important.
- If the bug doesn’t exist, you should report it!
- Reporting a new bug is easy. Click the New issue button in the top right corner of the page.
- Enter a clear, concise Title stating what happened. e.g. “Grid size doesn’t update in Eeschema when I click” or “Starting circular array in pcbnew crashes the program”
- In the “Description” text box, please describe the steps to recreate the bug. If the bug is subtle, please describe both the expected behavior as well as the actual behavior.
- Critically, after describing your bug, please add the detailed build information from KiCad. Do not enter this by hand. Instead, in KiCad, go to Help→About KiCad (on Mac, this is accessed from the “KiCad” menu).
- Then, click the “Copy Version Information” button. Then you can paste this into the bug report. Please do not write any other version strings as they are not useful here.
- Finally, when a developer fixes your bug, if you can, please test the fix (see testing below) and report back whether it works for you – or not.
Testing
Most KiCad users are not developers. We are circuit designers and engineers, artists and makers.
If this is you and digging through code is not your speed, you can still help KiCad improve by testing the new software. Many platforms nightly builds that will let you try out the latest features and updates. We desperately need more testers.
The KiCad user base estimate is between 12-14 thousand users. But we have only about three dozen regular testers. This means that our testing in nightly builds is substantially lower than testing in releases.
If you are willing to help test out new features, you will help to make KiCad of the future better than ever. Many platforms provide nightly builds including Windows, OS X, Ubuntu, Fedora, Arch and OpenSUSE. You can find these at the main download link on the KiCad website.
When testing nightly builds, please note that you might find a critical bug. This means that it might corrupt your circuit. We try very hard to ensure that nightly builds are stable and free of data loss bugs. But they do happen. If you do test nightly builds, please ensure that you have backup copies of your circuits. Revision control using git, mercurial, bitkeeper or similar tool can work well for this. Keep in mind that data corruption might not be immediately apparent, so just keeping a single back up (as opposed to revision control) may be insufficient.
Importantly, when testing nightly builds, please report any issues you find, following the procedure given in the “Bug Reports” section above.
Documentation
The documentation helps both new and experienced users to navigate the complexities of KiCad. As a side benefit, if you work on the documentation, chances are, you will learn a few new tricks that you didn’t know KiCad had.
To get started with contributing to the KiCad Documentation, head over to the documentation repository and check out the instructions for builds and contributing to the documentation effort. The first step is to join the Documentation mailing list!
If you are documenting the upcoming version, you’ll want to be running the nightly build. But even if you don’t want to be running the nightly build, there are quite a few sections that still need updating even in the 5.0.x stable series.
A good way to start working on the documentation is as an editor. Read through a document and find a section that is poorly worded or incomplete. Then fix it! You build on the good work others have started and provide a solid foundation for those who come after you.
Translation
Did you know that KiCad is available in 22 different languages? Of those, only a few are complete.
Does KiCad in your native language still have a few English menu options or text blocks? Or maybe you are fluent in a language that KiCad doesn’t yet have? If so, then we’d love for you to contribute to the translation!
To get started with translation, head over to the translation repository and grab a copy of the base files. Then download a .po file editor like PoEdit or Virtaal or Lokalize. These will highlight places where the text remains untranslated in your favorite language.
There is a detailed, step-by-step, instruction manual for getting starting with translation. It includes additional steps needed for adding a new translation.
Whether you update one string or all of them, you’ve helped improve KiCad for other users! Be sure to put a pull request in to the translation repository so that everyone can benefit.
As a note, a few translations are actively developed by current contributors (these are the ones on the left in the image above). If you want to contribute to these, be sure to check in with the current contributor first (their e-mail is listed in the .po file).
Development
Are you a decent C++ programmer? We are always interested in receiving new code contributions. But this might not look like what you are expecting. New feature contributions are sometimes interesting or useful but can also require additional work to support the feature and fix bugs after it is implemented.
More useful than new feature contributions are bug fixes. Every bug that you can fix means more core developer time to get new features developed and committed to the code base. Fixing bugs also helps you to learn the internals of how KiCad works and makes it more likely that a new feature code patch you create will be accepted.
How to get started fixing bugs?
- Create an account at GitLab
- Create a fork of the code
- Read the instructions for compiling
- Read the coding style policy and commit message format documents
- Search for some bugs to fix. Here is a link to bugs marked “Starter”. These are bugs that the developers have decided are relatively self-standing.
- Once you find the bug you want to fix, leave a comment saying that you’d like to work on the issue. One of the Bug Squad or lead developers will assign the issue to you.
- Then fix the bug and test your fix. Once you are comfortable with it, use git commit following the commit policy and then push your branch fixing the issue to GitLab.
- Submit a Merge Request with your branch to the main repository. We’ll get the notification and review your patch shortly.
Tutorials
The video tutorials complement the documentation to help both new and experienced users to navigate the complexities of KiCad.
If you are creating a tutorial video for the upcoming version, you’ll want to be running the nightly build. But even if you don’t want to be running the nightly build, there are quite a few V4 videos that still need updating for the 5.1.x stable series. Workflows change in new KiCad versions making out of date videos very confusing.
The best videos are concise and tackle a small portion of KiCad functionality.
* Note that donations to KiCad also help to speed KiCad development by funding specific feature “work packages” given in the KiCad version 6 roadmap. See Wayne’s FOSDEM 2019 talk for some additional details.