I use git a bit, but not an expert.
You can see the files committed in the merge requests. Not sure if you can pull them via git (you should be able to clone the branch for a particular merge request).
Alternatively you can just download them manually from via GitLab web interface.
If they are KiCAD symbols / footprints / 3D models - just copy them to your libraries and try.
If it’s a python “generator” script - run it to generate symbols, etc.
Some parts might even be obsolete when they are finally accepted (if ever). 
Anyway: I think our little discussion here does not lead anywhere as not even an official statement
or whatever was given. The topic just doesn’t seem to be “sexy” enough for the project lead.
For me it means that I will refrain from submitting symbols as I don’t see any benefit to
take the extra work of passing the KLC checks if that doesn’t speed up or help the process.
From my experience, changes to the codebase get a lot of attention. Anything involving the surrounding KiCad ecosystem (e.g., symbol libraries) is left to rise or fall on its own.
The usual rejoinder to this is “the developers are volunteers and they choose what they want to work on. Yadda yadda…” That excuse is wearing a bit thin. KiCad development is not a free-for-all: somebody is controlling the release schedule and what milestones will be included and which are left for the future. And, at one time, somebody set up the KLC rules. Maybe it’s time for somebody to realize the system for updating the libraries is broken. Then they can make an explicit decision that a fix is needed or, instead, that good, up-to-date libraries aren’t actually needed. Then we can all move on with a clear idea of what the direction is.
I think it’s important to realize that the librarian team is almost entirely a different group of people than the development team - there seem to be some comments in this thread that conflate the two.
A little full of ourselves today aren’t we? You should ask for your money back… Oh that’s right you paid no money.
Personally I would prefer any resources work on the code and program functions. The symbol and footprints I can do, coding I cannot.
As for the libraries, I don’t see why some folks are putting so much discussion into the libraries. I can create a symbol or foot print spending only a little more time than it takes me to verify either. My point of view is, this is my design, I’m going to verify every part and footprint that goes into it.
John
etc., ad nauseam.
Librarian seems to be about the most thankless way to help the KiCad project there is.
I’d rather say: the most undervalued job…
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.
telling volunteers to volunteer more of their time isn’t likely to win you much sympathy.
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?
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:
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?
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.)
Meeting KLC makes nicer and cleaner looking schematics and PCB designs. And it does not take to much effort.
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:
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…
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.
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.
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.)
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.
