> The set of people in that set, who are also willing to do the
> thankless scut work involved in fixing PRs is very, very small,
> especially when presented with the opportunity to do more
> 'interesting' things.
> 
> It's human nature to want to work on 'sexy' things.  ...

I think there's more to it than that. Another property of "scut" work
is that people tend to label it as "trivial" or "obvious". This is
dangerous because it means that new folks, who often have no clue
about the established precedents for getting things done, are thought
to need no training (or worse, they are labeled incompetent if they
turn out to need any training) so that when they _do_ need training,
it's essentially a "sink or swim" situation.

Either they build a list of kindly mentors and lean heavily on those
folks for help, or they flail and get washed out somehow. I've seen
this happen at commercial software places and felt its effect in
plenty of my own "scut" work assignments.

With "sexy" work however, training is generally more readily available
because the job is not considered to be "trivial" or "obvious" since no
one knows exactly how hard it is going to be yet! Also, people are much
more willing to strike out on their own and risk committing heresy
against tradition, because they know that when new code talks, tradition
sometimes has to walk.

But "scut" work has no such built-in optimism for a better tomorrow.
People are more inclined to avoid it if they don't have a very clear
idea how to accomplish it without getting flak from someone. This
effect is very well documented in Dilbert cartoons everywhere.

What I am getting at is that HowTo's for contributing to a project's
"scut" work are the single best way to encourage more volunteers for
that work. It reduces the perceived risk of flamage and miscellaneous
grief in the mind of the potential volunteer, and also increases the
likelihood that he won't need to have everything explained to him
more than once. Keep accumulating people's questions into the HowTo,
and over time it becomes a "bible" of how things have been done
successfully in the past. All successful religions and bureaucracies
(and corporate franchises) are built on top of some variant of this
idea.

The trick, of course, is to never let the "bible" become more important
than any of the goals it was created to support. I see no threat of this
happening in the case of a NetBSD "bible"; core is just way too competent.

Hence, my recent idea of a "how to contribute to NetBSD" web page.
If Perry will let me quote him, I can use a few of his past posts
as the first draft.

Todd Whitesel
toddpw @ best.com