> The goal is to encourage, in a management-friendly way, companies to > allow their engineers to contribute with the upstream Linux Kernel > development community, so we can grow the "talent pipeline" for > contributors to become respected leaders, and eventually kernel > maintainers. These are noble goals. Also the bullet list is short, formal, and to the point. This is nice. I kind of side with Michael Tsirkin's point that quantitative measures of performance can be harmful or give a false impression of control. Consider this example: linux$ git log --oneline --author=Walleij |wc -l 4301 linux$ git log --oneline --author=McKenney |wc -l 3346 There is something about some code in the kernel being more "core" than others that needs to be taken into account, albeit it is maybe an elusive concept. There is a hierarchy from contributing syntactic changes to coding style to contributing and maintaining say RCU. That can be judged by peers and is addressed in other points in the document so what about just dropping this paragraph? Then there is this: > +* Software Engineers are encouraged to spend a portion of their work > + time focused on Upstream Work, which is defined as reviewing patches > + or papers, Papers! If we are linking ourselves to the Scientific Community (and I see that as a good thing) we should certainly drop a few words about it. It's a place of (ideally) meritocracy and formal review of contributions. Here is a real nice paper: https://kernel.dk/systor13-final18.pdf as a community we should probably produce more like this. Or maybe you meant to say "mails". I don't know. On a side note I would say that this document creates a really serious cognitive dissonance with the document Documentation/process/management-style.rst so just for the fun of it I think this document should reference that latter document as a guideline for how Software Engineers will be evaluated in the community when they take on . It is a nice nod to the nature of conflicting interests and worldviews we need to deal with. Yours, Linus Walleij
