Contribution to symbol and/or footprint libraries still welcome?

[eelik]

Too few admins or something else?

I’ve put in several updates for the symbol library, which have all simply been ignored. In the case of one, it has now become invalid because a later submission was merged in, which invalidated it. The vast majority of submissions just sit there un acknowledge, whilst others seem to be tracked quite quickly. Is it that there are too few admins or is it a matter of who you know?

Contributing to KiCAD Libraries

Hi all, I’ve done a few contributions and merge requests to the official KiCAD Libraries (Footprints, Footprint Generator, Packages 3D and Packages 3D source) around 3-4 weeks ago. I know there is only a few devs who approve it, so I have to be patient. However does anyone know how long it usually takes for the developers to accept the merge requests? I can see some from a year ago still not accepted (not sure what the reason is). Many thanks.

I'm interested in becoming a KiCAD librarian. How do I start?

I’m interested in becoming a KiCAD librarian. How do I start? I’ve made some merge requests on the library and am disappointed with the speed they’re getting reviewed, so I’d like to help solve the problem and clear the backlog while making KiCAD better.

etc., ad nauseam.

[hermit]

Librarian seems to be about the most thankless way to help the KiCad project there is.

[F_W]

I’d rather say: the most undervalued job…

[devbisme]

@JohnRob

You should ask for your money back… Oh that’s right you paid no money.

I love this comment! Or I did the first 273 times I heard it…

Since my point wasn’t clear, I’ll restate it: If you volunteer to manage the libraries, then manage the libraries. If you can’t, then just say so and release control to someone else. There’s no shame in that.

I’ve been in that situation. I created KiCost and then supported it for a few years until I just got tired of it. Luckily, @hildogjr wanted to take over and he’s done a great job supporting and extending it. I think that was a better solution than just ignoring issues and pull requests while the tool rotted. The same is true for the libraries.

And ghosting the libraries has a real cost. It’s a pain in the ass to follow the KLC only to have your submission ignored. That makes a person who put in the effort to support KiCad just a bit less positive towards it. And since KiCad doesn’t have a multimillion-dollar marketing budget, it needs those positive feelings so members of its community will recommend it to others. That’s less likely if they’re pissed off.

[gkeeth]

@devbisme

Since my point wasn’t clear, I’ll restate it: If you volunteer to manage the libraries, then manage the libraries. If you can’t, then just say so and release control to someone else. There’s no shame in that.

telling volunteers to volunteer more of their time isn’t likely to win you much sympathy.

Activity · KiCad Libraries · GitLab

[hermit]

@devbisme

And ghosting the libraries has a real cost. It’s a pain in the ass to follow the KLC only to have your submission ignored.

Valid point, but isn’t it a numbers game on the librarians ?

Could the waiting be put into a ‘pending’ library with a proper disclaimer?

[devbisme]

IDK, maybe. The point is that the current system isn’t working well. Instead of cranking away and falling further behind, new solutions are needed:

1. Include “pre-release” libraries in the KiCad distribution.
2. Create a search capability to find and load parts stored in repositories on Github/Gitlab.
3. Create an enhanced version of KiPart that supports submissions in a simplified format and generates KLC-compliant symbols automatically.
4. Or just about anything else…

[jmk]

@hermit

Could the waiting be put into a ‘pending’ library with a proper disclaimer?

And who is going to read the disclaimer?

I can envisage a forum full of:

I used this symbol/footprint from the Kicad library and it’s broken.
I thought Kicad libraries were supposed to work.

@devbisme
Unfortunately I’d have to include your ideas with Hermits, for the same reason.

I really have trouble understanding the reasons for contributors complaints.
They create a symbol/footprint, they place it in their library, it is theirs to use forever: Great!
They wish to let others use it so: Greater! It will happen, in time. Why all the fuss and dummy-spitting?

I don’t continually read:
I had a great idea for Kicad so I made a feature request and it hasn’t been implemented in twelve months?
OR:
Why isn’t the documentation complete and up to date?

Why all the carry-on with libraries?

[devbisme]

@jmk

Why all the carry-on with libraries?

I think because of the effort required to meet KLC and then the complete lack of acknowledgement/feedback. (I’m guessing since i’ve never submitted to the libraries and am just going from replies to this thread.)

[tox104]

Meeting KLC makes nicer and cleaner looking schematics and PCB designs. And it does not take to much effort.

[F_W]

Asking why people complain is pointless. This would be the same as asking why to contribute to an open source project at all!

KiCad and also its libraries have been (and still are?) an open source project relying on contributions. More on the code side; less on libraries but still both are needed.

And now we have two extremes:

1. Too much contribution (which no one can coordinate)
2. No contribution at all

Obviously both extremes do not work well.

Having noticed that the number of MRs for the libraries is increasing constantly
I “just” asked if contributions are still welcome (See #1). Nothing more, nothing less;
no complaint at this time! However this turned into a vivid discussion leading to the
conclusion that the current system is broken. And maybe this discussion leads
to a future change that improves the workflow/process - for maintainers and contributors!?

Getting back to a reason for complaining:

Most of the parts I use are not contained in any official library. And I don’t care too much as suggested.
But if I use official symbols or footprints which need fixes or extensions (e.g. derivations, KLC errors) I always need to be careful to not use the broken one from the official lib - and everytime I install a new version the trouble starts again. Why not fix the broken part instead of creating a fixed clone
and avoid the trouble at all?

Sometimes if I think that a symbol might be useful for others or used regularly I contemplate to contribute it…

[paulvdh]

I was curious about how much is going on in the libraries, so I had a look at the link below, and I count 170 posts for this month (now 17 days, so 10 posts per day on average), and this is only for the footprints.

Activity · KiCad / KiCad Libraries / KiCad Footprints · GitLab

[der.ule]

Moreover, looking at the repository, it looks like they are doing a pretty good job.

Footprint

Symbols

Whats more, you’ll only see all this changes if you install the libraries with each release or pull the repository down by yourself.

[devbisme]

I agree that the KLC serves a valuable purpose in that it prevents the libraries from becoming wildly inconsistent. And maybe I’m wrong that they are onerous. (They certainly aren’t as bad as stuff like IPC standards.)

[devbisme]

@paulvdh

I count 170 posts for this month (now 17 days, so 10 posts per day on average), and this is only for the footprints.

Activity · KiCad / KiCad Libraries / KiCad Footprints · GitLab

I apologize to the maintainers for saying they were not adequately managing the libraries. I was wrong.

Whatever the reason for the backlog in merge requests, it’s more complex than I thought.

[johnbeard]

If I may make a comment as (newish) librarian: a review of an MR takes about 10-20 minutes if there are no comments to make and the contributor provided all of these:

• screenshots of the footprint or symbol:
  • footprints: fully dimensioned drawing and a 3D fit-up with the manufacturer 3D model if available
  • symbols: screenshot of the part in a representative schematic unless trivial
• datasheet link
• screenshots of relevant datasheet extracts
• explanation of design decisions that you made
• reasons for KLC exceptions (or a green pipeline tick).

If there any comments, any questions, an unexplained KLC pipeline failure, or any uncertainty, then typing out the comments, creating screenshots, that MR will now take at least an hour of keyboard time, but also likely means a round-trip which will delay the whole process by days. In the gap between arriving at home after work and going to bed, even on a day when I can carve out time for reviews on top of other KiCad-ery, let alone my own projects, I can rarely hope to complete a single review.

On Sunday, I spent basically a whole day and started 8 or 9 reviews. None of them could be merged that day. Only one of them could be merged after the first review, all the others needed another go around. Out of the 507 open footprint MRs, I currently know of only two, maybe three, that probably can merge without further comment. Two of those are my reviews from Sunday that I need to double check before pressing the button.

The “one simple trick” you can do to getting something actually reviewed is to convince a reviewer stepping out of the car after 10 hours in the office that your MR can be merged before bedtime. You can do this by adding all the items above, which indicate firstly that you’re willing to make the effort to make the MR easy to review and second that you have actually checked the footprint or symbol is correct and complies with the KLC. Pre-empt every question a reviewer could have. Remember, the reviewer is expected to stand behind every single part they review as if they drew it themselves.

Aim for an MR that needs no comments. These do happen! Honest! Personally, I love it! I don’t like nitpicking MRs, it’s boring and I feel bad for asking for changes! Look here (for footprints): Merge requests · KiCad / KiCad Libraries / KiCad Footprints · GitLab - any MR with only one comment merged without further changes (the one comment would be “merged! thanks!”).

[Tojan]

@johnbeard

The “one simple trick” you can do to getting something actually reviewed is to convince a reviewer stepping out of the car after 10 hours in the office that your MR can be merged before bedtime. You can do this by adding all the items above, which indicate firstly that you’re willing to make the effort to make the MR easy to review and second that you have actually checked the footprint is correct and complies with the KLC. Pre-empt every question a reviewer could have. Remember, the reviewer is expected to stand behind every single part they review as if they drew it themselves.

A small remark on this: looking through the recent merge requests it seems a bit like there are no guidelines on gitlab directly on how the ideal merge request would look like? Gitlab has this great feature where you can set templates for merge requests and I think this would help both sides here greatly. The ones requesting could then easily see what information they have to provide and the reviewers can check if the required information was given and reject all others on this base.

[greg_m]

@Tojan

A small remark on this: looking through the recent merge requests it seems a bit like there are no guidelines on gitlab directly on how the ideal merge request would look like? Gitlab has this great feature where you can set templates for merge requests and I think this would help both sides here greatly. The ones requesting could then easily see what information they have to provide and the reviewers can check if the required information was given and reject all others on this base.

They are templates. However they only appear when you open a MR. It’s basic stuff like a few screen shots and datasheet link. Easy to gather.

[devbisme]

John, thanks for the details on what it takes to merge to the library.

A few years ago, I built several symbol libraries for multiple FPGA families across multiple companies. There were hundreds of parts, some having thousands of pins. These were all done with KiPart being driven from pin tables directly from the manufacturers.

If I had submitted these as libraries (I did not), would they ever have been merged? Manually verifying the pins would have taken months! Nobody would want to do that if there were easier parts to merge. Is the backlog caused by passing over more complicated merges, or is there some other factor that’s the main cause?

[hermit]

@jmk

And who is going to read the disclaimer?

The disclaimer is in the library name. Not a ‘solid’ suggestion to start discourse.