Closed herostrat closed 5 years ago
In general a good idea. My tutorial for footprint checking could be useful here: https://forum.kicad.info/t/how-to-check-footprint-correctness/9279
The largest part of the work is not necessarily checking if a contribution is ok. But documenting the findings in a way that allows the contributor to fix problems. For a lot of contributions it already helps if somebody tells the contributor what travis already found. (It seems a lot of contributors do not check travis output)
Improving the travis-scripts would be good. This is fast and direct feedback - the more things that can be checked and caught automatically the better. Are there instructions for how to use travis on your own fork?
You can run the same scripts locally.
You can also read up the github documentation about setting up travis.
The lack of response is very discouraging when trying to contribute symbol/footprints. By the time there is a response that contribution has gone cold/contributor might have lost interest. It's easier for people to create their own (non-KLC-compliant) libraries, instead of contributing to the official libs. This is a waste of resources and a problem that KiCad needs to fix.
Are there instructions for how to use travis on your own fork?
Before a contributor submits footprints/symbols they ought to be made aware that they should first run the scripts at KiCad utilities locally.
The lack of response is very discouraging when trying to contribute symbol/footprints. By the time there is a response that contribution has gone cold/contributor might have lost interest.
some rules/guidelines how/when review will be done would be good. even if it takes a long time it would be good if the contributor gets some feedback that the work is moving (slowly) forward according to a work-flow in N stages - or similar.
Before a contributor submits footprints/symbols they ought to be made aware that they should first run the scripts at KiCad utilities locally.
This could be simpler:
In other news, I'm running into merge-conflicts for symbols - is there any plans for how to resolve this? Are symbols moving to one-file-per-symbol, like footprints, anytime soon?
@poeschlr Yes, your guides and tutorials are a huge for the workpackage. I am currently writing a draft of it and I hope to be able to post it here until the weekend.
@robkam I know how you feel. If you look at the open PR you see most of the maintainers also wait for a review and answers to questions in issues and reports... It is just that everyone is doing it in there freetime with no compensation and the number of people willing to put time and effort into review of the library is to low compared to the number of people pushing new content.
That's the reason I want to make it easier or probably more comprehensive to review others work and get more people to participate actively in the library (even if it is just me, it will be beneficial to have set dates and workpackages in order to help more consistent)
@aewallin I really like the idea to add a "check for KLC" button. I however do not know how easy or hard that would be to implement. I guess that would be a good wishlist candidate for the bugtracker at launchpad.
@aewallin I really like the idea to add a "check for KLC" button. I however do not know how easy or hard that would be to implement. I guess that would be a good wishlist candidate for the bugtracker at launchpad.
I have asked for that a while ago. I even played a little bit with KiCad code to see if I was able to implement it. Seems like yes but many of the DRC/ERC windows are going to be rewritten soon. I need to ask who is in charge of that and ask to see the code to adapt my feature to that.
Running the scripts or Travis same thing. It's already as easy as opening a terminal and entering a simple command line.
Submitted as bug Submitting to libraries is not immediate enough
Perhaps the problem is library maintenance needs more delegation. The work the librarians do is meticulous and careful, not everyone has the patience for it.
Submitted as bug Submitting to libraries is not immediate enough
Closed as invalid.
I mean what was the goal of that report? It has no improvement proposal and just says something everyone knows?
The only way the submitted stuff gets audited, reviewed and merged faster is if more there are more reliable people start and continue to make reliable reviews, which is what I hope to achieve.
Since KiCad and the library more is work done in free-time from volunteers the project can not just say "you three guys now work on the library full-time".
If you are willing to help stay tuned for the guide that should help out newcomers, that I try to compile here.
Hey guys,
the current amount of new contributors and additions seem to be overwhelming for the current teamsize, and this is not meant as critique.
Because I am pretty new to KiCad myself I try to help out if time allows and did first review with basic KLC checking. The highest hurdle (for me at least) was that I did not want bother you guys too much and was not sure I am informed enough to contribute.
I saw (and helped out) in a very interesting project from KDE: https://phabricator.kde.org/project/view/290/
I love the idea for KiCad as well. A review day in which newcomer are given tasks, get to know the workflow of the project with guidelines (git, kicad, freecad for dimensions) and hopefully get confident enough to contribute in the future themselves or in future review days.
Thinking about my own experience (and reading e.g. https://github.com/KiCad/kicad-symbols/issues/1217) let me to think:
(Guided) triaging could help out quite a bit in all of those points imho. And I think even guys like me that are really not "fluent" in the KLC and overall alignment of the project could help out newcomers that are eager to help.
Workflow could be something like this:
Please let me know what you think about this idea. I would love to organize this if it does not produce more work for the KiCad team.