Feature 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 feature-addition or behavior-change merge requests from new contributors without an issue that the lead development team has already accepted.

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.

This policy does not apply to bug fixes. The defect itself is enough justification for the change.

3. How to Propose a Feature

  1. Search the issue tracker to see whether the feature 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 a feature or behavior change without going through this process, the team may close it and ask you to open an issue first.

4. Why This Policy Exists

Unannounced feature MRs cost the team time even when they decide not to merge them. Worse, contributors sometimes build something large only to find that it conflicts with where the project is headed, or with work somebody else is already doing. Discussing a feature 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.