Re: [Ksummit-discuss] [CORE TOPIC] Recruitment (Reviewers, Testers, Maintainers, Hobbyists)

[Darren Hart <dvhart@infradead.org>]

On Sat, Jul 11, 2015 at 08:04:37AM -0700, Greg KH wrote:
> On Fri, Jul 10, 2015 at 07:39:46PM -0700, Darren Hart wrote:
> > OK, all good points. It looks as though I can step up my own tooling some to
> > make the email-to-compilation step faster so I don't spend as much time on
> > patches with compiler warnings, that don't apply, etc. Dan C. said something
> > similar.
> 
> I think I mentioned it before, but Wolfram has a set of scripts that
> does this really well.  I don't know if they are published anywhere, but
> that would be a good place to start with.  I think Sara Sharp also had a
> bunch that she used to make life easier, you might want to ask her the
> next time you see her in the office.

Will do. I think Jani sent me a set of scripts I need to review too.

Actually, in this sense, I'm the newbie maintainer who's spending time writing
up scripts, tools, and mutt macros to handle a process that 970 other people
have probably already written. I'll do so in a subtly different way of course,
and this will add ever so slightly to the variation in expectations and
behaviors of the Linux maintainers.

Maybe patchwork will be an improvement for tracking. Maybe not. While I do enjoy
writing up these scripts and tools to automate my job as a maintainer.... my
ability - or maybe willingness - to do so, shouldn't be what qualifies me for
the job. More tooling that standardized the process and makes the code review
more accessible to people less interested in writing mutt macros, might expand
our pool of candidates.

> > The "one hour class" thing makes it sound like it takes "one hour" - but I find
> > I have to revisit this stuff fairly regularly, and those hours add up.
> 
> Really?  Why?  Once you learn the workflow, what keeps changing that
> breaks things?  External stuff (like corporate email servers), or things
> in our workflow/tools?

In my experience it's just more new people with the same questions. Once they're
up and running, it's minimal effort to keep going. It's the initial ramp up that
gets repeated. So it's not the "one hour" adding up for the newbie, it's that
"one hour" adding up for me as the instructor :-) I'd love to help reduce the
effort it takes to bring new people up (yup - totally selfish motivation here).

This is especially true when the new people don't stick around. I really don't
want to invest an hour in someone that has 3 patches to send and will never
return.

It can be more trying when someone is doing this for a job and not because they
are interested in becoming a regular contributor. Each step is another barrier
they'd just assume avoid. If they're new, they also don't understand the
workflow or how maintainers scale, so they push against things that don't make
sense for sending 1 patch - but are necessary for processing 1000. Many of these
training sessions involve a certain amount of "why can't we just ..." or "you
don't have gerrit setup?" or ... etc. Ultimately, it's just another barrier to
recruitment.

We can say we don't want people like that contributing anyway, but the end
result of that is less hardware supported, or even more burnt out senior Linux
kernel developers who pick up the load because it's easier than training new
people.

-- 
Darren Hart
Intel Open Source Technology Center