librepcb library contribution workflow

Librepcb is meant to have the best library management system but I don’t see much contributions to the libraries.
The work flow at the moment is to fork the github repo of the library you wish to contribute to and create a pull request. If the PR has outstanding issues or is not noticed by the maintainers it would likely just languish there. Since it’s a fork it’s not straight forward for another person to fix the issues if the original pull requester doesn’t fix the them.
I’m wondering if we had something like a dev library where contributions from new or inexperienced users could land. With this dev library having more eyes on it the response time may be quicker encouraging the requester to continue contributing. If this dev workflow is not a fork but a branch on the dev library repo then someone else with an interest in the device could fix the issues if the original person isn’t heard from again for some days or weeks. Maybe if the main issues with the PR are fixed then it could be considered good enough to merge into the dev library and an gh issue could be raised for the outstanding minor issues. Often this might just be a trusted person verifies against the data sheet.
After a time the device could be re-based onto the proper library once it’s considered to be correct. Possibly the work flow could be that symbol/component and package/device could be two separate pull requests so that if only one has issues then the other can be merged instead of all or nothing.
I’m not a git/github expert so maybe this workflow doesn’t make sense but might inspire other ideas.

Hi @Recycled0080,

Thanks for your thoughs. Generally I did have something similar in mind already, but due to lack of time not being able yet to seriously work on this topic. But I know we have to improve this workflow.

Just a few comments:

Actually for us maintainers it’s not a problem if PRs come from a fork not maintained anymore. Usually we get write access on the branch of the fork (it’s a GitHub feature) and thus we can push updates. I do this quite often.

I think one problem is currently also that to make contributions, you’d have to fork many repositories, which is cumbersome. It would be much easier to have a single location where contributions can be made, no matter what library they belong to.

As mentioned, that’s something I was thinking about already. What concerns me is that when merging “bad” library elements, fixes might need breaking changes (i.e. we’d have to change their UUIDs), effectively making any dependent library element obsolete (need new UUIDs as well). For devices it’s not a problem (as nothing depends on them) but other elements can be very frustrating if they need breaking changes. And of course for users of this “community library” this can be frustrating.

Anyway, maybe we need to take this “risk” to improve the overall library ecosystem. That’s to be clarified…

Yes that’s always a good thing! I’m already very happy about every contribution split into smaller pieces. PRs with tons of elements are currently very unlikely to ever get merged.

EDIT: Btw, sorry for the delay - the forum has blocked your post :-/