How to help the Library-Team?


I just made finished my first KiCAD layout, and I like to help to improve this software. Because I’m not a programmer I might help with the component library. I made about 40 PCBs in my professional life, with several different PCB software packages - Eagle, Mentor and Geddy (sic!)

On the page
it says:

“Currently KiCad librarians team counts with just a few people against a lot of merge requests and work to do, having your help would be very appreciated.”

So it seems that this is the way to go. However, I did not find any method to contact the library team. I might spend something like 3 to 5 hours per week for this.


AFAIK, the only way is over GitLab Have fun.

Or you can try invoking the library gods @chschlue or ex-gods @Rene_Poschl to more precise pointers.

Make sure that you read the KLC thoroughly:

The library guys are very strict on standards, in order to maintain the overall quality of KiCad libraries.

In fact, we’re even reaching for the stars and try to improve the overall quality.

That aside, help is appreciated, of course, but be aware that it’s not easy to get started right now because we’re in the v6 transition. (Meaning reading the KLC and other guides doesn’t really help because everything is changing.)

I would assume the KLC is quite ok for the footprint side of things or are you planning to do massive changes there as well?

True, footprints will mostly stay as they are.

Thanks for the information. In this case, it seems to me that is is better I contact you after the dust of the action/chaos of the v6-release settled a bit.

ML9104 wrote:

AFAIK, the only way is over GitLab

I interpreted the sentence “librarians team counts with just a few people against a lot of merge requests” that it is better to help on “the other side” of the merge requests. Instead of producing more of them, probably mainly with parts nobody else ever needs…

Do you have anything specific in mind?
There’s a lot of symbol libs in need of cleanup for v6, for example, and many librarians (myself included) seem to be pretty busy with real life ATM.

One of the highest impact will be if you help out with reviewing contributions of others at least during a “normal” time (as @chschlue indicates right now is not such a normal time). But this also requires more work than contributing a few assets that you anyway made for your own use.

I can speak from experience when i say it is fun (at least for a while) to help out this way. One learns a lot about how to communicate with others especially as most of the work is to point out errors made by them. Which is an inherently challenging task as nearly nobody likes having their work criticized.

You have a similar “problem” as we had when we cleaned up for v5. No matter how much you do you will always find something that can still be improved (this is kind of the nature of maintaining such a huge system).

So my tip here is focus on what you can achieve and be proud of that. And don’t be afraid to focus on what interests you personally even if you suspect the community might want you to focus on something else (this was the reason why we for example did not fix the logic libs with the v5 release and instead got a lot more footprint generators especially for connectors)

And of course feel free to ignore me completely. After all i am no longer active enough in this community to be really allowed to make suggestions.

Nothing special. The component library is just the point where I can help. My programming is not good enough for helping with the main source code. Just (python) scrips would be possible for me, for footprint generators or similar…

Rene wrote:

don’t be afraid to focus on what interests you personally even if you suspect the community might
want you to focus on something else

I assume I start with whatever is needed most at the moment. And later, when I know more about the project and its needs, I switch more to things which both I’m interested in and need to be done… Let’s see.

Is this the point where I (ca. half a year ago) searched how to use a 74HC132 logic gate with the SO-14 package but only found the through-hole DIL-14? And later found out somebody obviously renamed the SO-xx footprints in the library so the names did not match to the footprint filter in the schematic symbol anymore? That was the moment when I thought some help is needed with the library…

This shouldn’t happen all too often.

OTOH, footprint filters for generic symbols don’t really make sense anyway.

On the third hand, it may well be that logic symbols shouldn’t be generic after all. The classic ones available in DIP, SOIC and TSSOP are increasingly falling out of favor while the newer low voltage single and double gate parts aren’t really generic at all.

Glad that you’re interested in the logic libs. :smiley:
Do you happen to have a GitLab account?

Never mind. Having a gray eminence lurking around doesn’t hurt. :stuck_out_tongue:

Recommended related standards for schematic symbols (bold from original post missing):

I am currently reworking logic libs using symgen. The main issues are to do with hidden power pins I think.

Although I would say, the real bottleneck in the library process is reviewing and approving merge requests (and always has been).

1 Like

Feel free to use any symbols from here (updated) or here for your templates, if appropriate.


Right. Sorry, I forgot.

This has many discussed several times before, the question I asked then is “how do we improve the review process?”. There has never really been an answer to that.

As @Rene points out, the main checking task requires human attention, so although the KLC scripts help, they are not the solution.

Tbh, I am not sure it is fair to ask people to submit MRs, since they will probably sit there becoming stale, and contributors become disappointed. There are currently 915 MRs, dating back 3 years.

I, for one, don’t really have an answer.

I totally get that motivation tends to be low when people are asked to fix their contributions months or sometimes years later, but then, I wouldn’t really want to actively discourage contributions.