I run a hardware company and mandate all boards are done in KiCad. That means I have invested a lot of money in to KiCad and given monetary incentive for EEs to

I run a hardware company and mandate all boards are done in KiCad. That means I have invested a lot of money in to KiCad and given monetary incentive for EEs to learn it/use it. We love it. Automation, git integration, small size on disk, runs on all platforms, it's great! Thanks for your hard work. Recently due to chipageddon and imminent production of our major equipment we have been reaching for some less common (but available) components. Therefore we've started drawing up symbols/footprints/3D models more regularly. Even basic stuff is sometimes not there. I naturally want to contribute back but noticed: (1) https://github.com/KiCad/kicad-footprints https://github.com/KiCad/kicad-footprints is now read-only on Github but had 336 unanswered pull requests. Then moved to Gitlab, where it has 412 merge requests. Meanwhile, existing user pulls from Github aren't getting new data. (2) https://github.com/KiCad/kicad-symbols https://github.com/KiCad/kicad-symbols is now read-only on Github but had 217 unanswered pull requests. Then moved to Gitlab, where is has 304 merge requests. Meanwhile, existing user pulls from Github aren't getting new data. (3) https://github.com/KiCad/kicad-packages3D https://github.com/KiCad/kicad-packages3D is now read-only on Github but had 75 unanswered pull requests. Then moved to Gitlab, where it has 93 merge requests. Meanwhile, existing user pulls from Github aren't getting new data. Things I take from this: (1) Fundamentally the transition to Gitlab (which I support!) could have been handled better by KiCad, and this is harming community engagement - eg. you should either keep them up to date as mirrors of Gitlab or shut down the old Github repos and redirect users to Gitlab. (2) Gitlab requires SSH keys to allow cloning, which breaks for most scripts/automation (by design). This should have been considered deeply before the move with a strategy to mitigate the user impact. (3) The current de-facto UX of having to mystically discover a move happened, manually creating a Gitlab account, upload an SSH key and manually re-clone three repos in-place while preserving KiCad path configuration is a poor user experience to say the least, which less technical users will not be able to do, and should preferably have been handled automagically by KiCad itself using rsync or something. Asking devs to validate submissions is insane. Instead, consider to invest some time to create an off-git unified submissions process which enables users to verify one another's uploads, sort of like a captcha, ie. "does this pin on this footprint match this datasheet?" or "do the overall dimensions of this package match this datasheet?". This would allow for submissions but require some community engagement on upload to lessen the load for existing maintainers. To make up for potential inaccuracy, just fire the same content at a few people to verify, or even hand out open source experience library helperships to students: KiCad summer of datasheets. My 2c. Keep up the great work!