How to help the Library-Team?

Hello,

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 https://kicad.org/libraries/contribute/
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.

3 Likes

AFAIK, the only way is over GitLab https://gitlab.com/kicad/libraries. 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:

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

:man_facepalming:

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.

One thing that could help on the footprint side is to require contributors to make dimensioned drawings of their contribution and include that as a screenshot now that the footprint editor has decent dimensioning features (The reason why we had it as optional in the past was because we really could not expect users to learn freecad or even librecad for this).

That would reduce the time needed for reviewing by moving part of the responsibility to the contributor as well as improving the chances to get it right the first time round as the contributor would automatically do their own review while making the drawing (again speeding up the process as there is then a lot less communication required).

This of course only makes sense on footprints that are not generated with the IPC generators (and if a series of for example connectors is made with a script then only a select few of them need the drawing. Most likely the one with the lowest and highest pin counts plus possibly one in the middle)

Also one could require that these drawings should be dimensioned in the same manner as the drawing in the datasheet (if possible even have the dimensions in similar places)


What could also help is requireing users to give the page in the datasheet that has the relevant info. So for footprints the page of the dimensioned drawing they used and for symbols the page that has the pin table (The times i needed to search in the datasheets is way too high and how often i then discovered that the linked datasheet does not even contain the required info was also frightengly high) Forcing users to give this info might again increase the chance that they find errors on their own as they might not be aware what info they really need to make assets.

In the end everything that ofloads work to the contributors while still being reasonable should really be considered (I think i was too careful with this when i was the head librarian).


Plus i hopefully finish my theisis soon so i might be able to then help out again before summer (i hope) Took me long enough now (i kind of miss working on the scripts)

Now, i have one :wink:
About Logic: If this is the topic to start with, why not.

Maybe generic symbols with footprint filters are most usefue only with “resistor” and “capacitor”.
Apart from this, I like a symbol which already includes the correct footprint, so there’s no danger to choose a wrong footprint. “SO-14” or “TSSOP-14” is easy. However with all this slightly different variants of e.g. a 5x5 BGA with 1mm pitch from different companies, I like to have the correct footprint already attached, so I don’t click on the wrong one (or need to read data sheet every time I use the chip for 5min to sure to get the right footprint).

Ah, ok, the logic is aready covered. About the hidden power pins: To change such a philosophy, that is really a lot f work because it affects a lot of chips. What it is changed to? Eagle uses explicit power symbols. Mentor uses a property in the logic symbol with text like “VCC=VA_P5V0;GND=DGND”

Maybe this is a nice idea for a python generator: Start with a table of logic functions, amount of gates in the chips, pinout, footprint. Then the rest is auto-generated so it does not make much work if another change of philosophy of power pins happens.

Yes, this probably disappoints contributors. On the other side, it is a lot of details which can go wrong with drawing symbols and footprints. So it is a lot of checking necessary.
Is there an idea of quality control? something like a voting system, so if an user notices something is wrong, he can mark the symbol as wrong (with a short error description). Or, on the other side, he can mark as “confirmed and works as intended”, so others can see that the symbol already got 5 points (out of 5) from 10 users, so probably it is ok.
Maybe also as “group marking”, so after the PCB is soldered and the circuit works, with one mouseclick, the user can mark all symbols as “work as intended”

Oh, yes, that is a really big time save, I assume.
I know the problem of finding the dimensions, especially which the data sheets of connectors.