Kernel developers spend most of their time reading other people’s code – and that’s a very important part of the community. OTOH, publicly making fun of people will scare them away. Contributors have double pressure of upstream and of their management.
Why do people contribute?
- Learn from it.
- Altruism – not the main reason to start contributing, but it reinforces what you do.
- Fun – it’s a hobby.
- Fame and fortune (few people). But Open Source is one way that you can get out of the box, which is difficult when you’re working for an employer.
- Solve problems.
The upstreaming process as maintainers claim it works, is not how developers perceive it. Developers (think that) they have to send a lot of mails to the list, and they get flamed, and then somehow magically it sometimes does appears upstream.
What works for contributors:
- Encouragement and feedback. Stephen started kernel development by ripping out brlocks, which were written by David Miller, and he got positive feedback about it from David. This would typically not work in a company environment, where individuals “own” pieces of the code.
- Learning how the internals work
- Have fun: follow the rules, understand the feedback, negotiate the results.
From patchwork data it turns out that the ratio of accepted patches does depend on size, but not much.
Arrogance in the contributor tends to scare maintainers away.
Toastmasters international is an organization that allows people to train their public speaking skills. It’s similar to the open source community, but an important element that the OS community doesn’t have is a procedure for how to de evaluation. [Unfortunately I couldn’t follow the explanation of this procedure.] Lessons learnt from this:
- Reward taking the risk (i.e. voicing a new idea), even if it is a mistake.
It would be useful to break the review into different aspects, e.g. coding style, locking issues, API consistency, …
Mentoring: encourage a new contributor, answer their questions, …. Find a mentor locally, in your company, or on a kernel mentors mailing list. An important role of mentoring is cheerleading, i.e. saying “you can do it”.
- Document how to review patches
- get_reviewers.pl, for maintainer to know who should review it
- document how to do things, like Paul wrote for RCU.
Documentation/ReviewingPatches.txt will come!
What is missing in SubmittingPatches is an explanation of what the commit message should look like.