Code Contribution Policy

Do not modify this document without the consent of the project leader. All changes to this document require approval.

1. Purpose

KiCad is maintained by a small lead development team. Reviewing a merge request takes real time and attention from that team, and this policy exists so that new contributors don’t pour effort into work that won’t be merged.

2. The Rule

KiCad does not accept merge requests from new contributors without an issue that the lead development team has already assigned to the contributor.

For the purposes of this policy:

  • A feature addition is any change that adds new functionality.

  • A behavior change is any change that alters how an existing feature works in a way users will notice.

  • Accepted means a member of the lead development team has responded to the issue, agreed the work should go ahead, assigned the issue to you, and given any guidance the work needs.

3. How to Propose a Feature or Report a Bug

  1. Search the issue tracker to see whether the change has already been discussed.

  2. If no relevant issue exists, open one. Describe the problem you want to solve, the user-visible behavior you propose, and any open questions. Focus on what the user sees, not how you plan to build it.

  3. Ask on the issue whether you may work on it. Explain what you understand about the problem and how you plan to approach it.

  4. Wait for a response. If the team agrees, they will assign the issue to you. They may also push back, suggest a different approach, or ask follow-up questions before assigning.

  5. Once the issue is assigned, write the code and submit a merge request that references the issue.

If you submit an MR for without going through this process, the kicad bot will auto-close your MR.

4. Why This Policy Exists

Reviewing MRs costs the team time even when they decide not to merge them. Worse, contributors sometimes build something only to find out that the team wants to solve the issue in a different way or has additional considerations. Discussing a change as an issue first lets the team and the contributor agree on the goal and the approach before any code is written.

This is not meant to discourage contribution. We want new contributors here, and we want your work to land. The discussion step is how we make sure that happens.