Dear Julius,
Am Montag, den 27.02.2017, 13:32 -0800 schrieb Julius Werner:
I don't think it's helpful to single out "corporate developers" as the black sheep that submit all the style violations. Every contributor, paid or hobby, new or long-time, needs to pay attention to the project guidelines equally. Everyone overlooks stuff some time, and it's normal especially for new contributors to not be quite that familiar with everything yet.
I certainly didn’t mean it that way. I didn’t want to single out anyone as the black sheep. I apologize, if I offended anyone. I totally agree with your view.
My focus on corporate developers was motivate by the following two things.
1. Corporate developers certainly contribute most of the commits and code. 2. I believe and assume corporations have *additional* ways to reach “their” developers.
Its our responsibility as reviewers (especially those of us with +2 rights) to educate them and make sure the rules are followed before a patch can get submitted.
That said, I do agree that we have a lot of potential in making this easier and more consistent for everyone involved. I think the best tool for that is more automated checking... like that recent idea to make Jenkins add the checkpatch result visibly to its Verified+1 message.
I'm not sure if the "where" of the guidelines really makes much of a difference... maybe we should just make them more discoverable either way? Could we put a big orange "please ensure that this patch conforms to the style guidelines at ..." banner in Gerrit somewhere near the submit button?
Most people push the commits from the command line I guess, so that – especially in the beginning – they won’t even access the Web interface?
For corporations the following ideas came to my mind. The assumption is that in corporations people are higher to see the colleagues in person or to be in the same building.
1. In each division there is some kind of QA person “holding the hands” for the first commit. 2. Before somebody starts working on coreboot there is a small introduction by a colleague already familiar with the guidelines. 3. Do for example Intel, Google or Siemens have documents (tutorials, videos, presentations) they could share? Would it make sense to create those?
[…]
Regarding improving the documentation, I guess everyone agrees (and nobody wants/likes to do it). In my opinion the easiest way would be to copy as much as possible from other project (like the Linux kernel). Though that should be discussed separately.
Thanks,
Paul