I prefer to see it as you have made the contribution. That contribution has not yet been formally recognised. 
Actually you have, because Gitlab has captured your submission. So fear not, you are not forgotten. As Emerson Lake and Palmer sang: The tapes have recorded their names.
Maybe I have forgotten about the contribution when it’s finally recognized? LOL
Nevertheless, I will hold back in future until the situation has improved.
This is just another example of an age-old problem:
- Create a “perfect” library.
- Ordain a set of onerous rules for adding entries to the library.
- New entries never get accepted and stop being submitted.
- The library never changes and, hence, remains “perfect” for eternity.
One solution is to automate the rules for acceptance. Maybe that’s not possible or else it would have been done by now.
Another solution is to make your library contributions available independently. It would be great if they could be placed in a centralized, curated list where others could look for them, but that runs the same risk of not being updated like the official KiCad libraries.
I can at least offer an automated list of over 1000 KiCad libraries on Github. Obviously that’s a lot to sort through. But if you do find a valuable library repository, give it a star and tell others about it to raise its visibility. And if you create such a library repo, place enough keywords in the description to make it easy for others to filter/search for in the table.
I agree with you…
On the one hand we have the (desire for) a “perfect” library - which cannot be achieved anyway IMHO.
On the other hand we have sloppy libraries all over the place with countless repositories which
could be deleted at any time (and which I’m reluctant to use).
Maybe some kind of staged submission would be a compromise:
- Submissions which can at least pass the automated KLC checks and that were briefly reviewed
are available in a kind of preliminary/preview lib (but which can be installed optionally). - Submissions from that lib that were reviewed will be merged to the “perfect” library or discarded
if not fulfilling the requirements.
Maybe there should also be well defined process to submit fixes, improvements etc.
to these “preview libraries” would also help to reduce the workload on the maintainers
and help to improve the quality at the same time?
In the post below, I had a proposal for a “melee library”. The idea is that all proposed symbols and footprints are “dumped” in it.
- This gives gives them an opportunity to be used, instead of waiting (years) on gitlab for approval.
- When people use them, there are much more inclined to give feedback.
- When people see it works, they are motivated to put some more effort in it themselves.
- When people see a library item they can actually use themselves, they are more inclined to spend some time on improvement.
- It makes the threshold to make small contributions a lot lower.
- More people joining in reduces load on the librarians.
I am also a bit in doubt from library parts that come from sites like snapeda, pcblibraries, and similar. I do not know if there are legal issues with (modified) parts from such origin to be put in the KiCad libraries. Are the KiCad librarians supposed to check for this? Should each library symbol or footprint have a copy- right/left statement?
You can always download to local storage or fork them on Github. Then they can never vanish.
I have a feeling we would get to the same place, only with submissions to the preliminary library just stacking up.
Probably agree with [paulvdh], with an oshw trash library collector, before creating some specific or new ones each time it has not be detected in the so-called official Std library.
Anyway necessary to check and verify footprints or symbols fitting your needs, as rules and constraints could differ, using or not IPC Standards (having some lacks or limitations…).
Maybe an automated workflow where you have to review 2 submissions from a pool before your submission can enter the pool. Crowd sourced reviewing no less.
Probably plenty of flaws in this unbaked idea that I’ll disavow at the drop of a hat. 
I had a short look on gitlab, and there are just over 500 merge requests waiting for footprints, and about 570 for symbols. I was wondering what the "least effort: melee-library would look like. There seem to be some real nice parts waiting for 4 years or more, for example a script based generator for PCB block transformer footprints. It’s quite a shame they sit there for so long, but I also notice it is very hard to do work on any footprint you are not in need of at the moment.
Is it feasible to use GIT to put these merge requests into two (symbols and footprints) git repositories and extract a library from it? I believe that just making them available to a wider public is already useful. If you can add those as libraries to KiCad, it is very quick to see whether some part you are interested in is in this library. These libraries should then have a remark they are not officially accepted, and any changes or remarks made to them can then be handled via the normal gitlab mechanisms. Maybe a script to add such a remark to each symbol and footprint of those melee-libraries are useful, but anyone who installs the melee-libraries should read some introduction and know the purpose and mechanism behind the library.
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
1 Like
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.