review day - Githubissues

herostrat commented 5 years ago

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:

people have a hard time finding out where and how to help
many people do not know that there is a official repository anyone can help and contribute and do their own thing
because the KLC and workflow is imho learning by doing, asking questions and getting answer in a timely manner is important
upstreaming stuff can get frustrating because often there is no reaction at all

(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:

compile workpackages consiting of 2 or 3 footprints/symbols
each contributor can pick one and work through a prepared list of tasks with links how to do them (e.g. check dimensions in freecad, compare with datasheet, check for obvious errors like spelling)
after that he can report in the IRC/workpackage-list that he/she thinks it is good to review from a maintainer
the review day team can attach a label to the PR and/or merge the footprint

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.

poeschlr commented 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)

aewallin commented 5 years ago

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?

poeschlr commented 5 years ago

You can run the same scripts locally.

You can also read up the github documentation about setting up travis.

robkam commented 5 years ago

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.

aewallin commented 5 years ago

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:

a "KLC" button in the symbol or footprint editor, that runs the scripts on the part that is open in the editor and reports errors.
if simple instructions are available for configuring travis on your own fork of kicad-footprints and kicad-symbols, and travis is willing to handle the workload, then running travis on your own fork is a good alternative also I think.

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?

herostrat commented 5 years ago

@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.

antoniovazquezblanco commented 5 years ago

@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.

https://bugs.launchpad.net/kicad/+bug/1803585

robkam commented 5 years ago

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.

robkam commented 5 years ago

Submitted as bug Submitting to libraries is not immediate enough

Closed as invalid.

herostrat commented 5 years ago

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.

KiCad / kicad-footprints

review day #1160