[Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Jason Cooper]

All,

During the proposal period for last year's KS, there was quite a bit of
talk regarding maintainer survivorship.  imho, the best solution
involves continuously bringing in new maintainers and developers as they
crop up.  Should we encounter the unfortunate situation of needing to
find a replacement, having plenty of pre-trained developers on hand
gives us more flexibility.

As a hobbyist, I of course think the answer is recruiting more hobbyists
into the ranks :)

Unfortunately, we ran out of time during the lightning round last year
for me to give a short presentation on the topic of hobbyist recruiting.

I'm not a fan of reaching out in the direct sense.  I much prefer to
keep my eye out for new comers who seek out the community and make sure
they don't get ignored.  I know a lot of us have pretty aggressive mail
filtering out of necessity.  For those interested in assisting me, I'd
like to discuss creating some basic resources to facilitate spotting new
comers and directing them as appropriate.

Something as simple as creating a separate mailbox and ruleset for
senders we haven't seen before (with a few keywords to filter out the
spam) would help greatly.

On a related topic, I've also started receiving patches from first time
contributors who are taking part in the Eudyptula Challenge [1].  No, I
hadn't heard of it either.  It's very similar to the Matasano Crypto
Challenge [2], except that it builds up to contributing patches to the
kernel.

If this topic is accepted, I'll give a status update on the hobbyists
I've seen since the last KS, what work they've done (hint: those
Chromecasts can boot mainline now ;-), I'll also compile some rough
stats on first-time posters to the most popular email lists.  eg was it
legit, did anyone respond, did the poster return?  Currently, I'm
thinking lkml and lakml would be most relevant.  There may be other
lists I'm not aware of.  Please let me know if that's the case.

If anyone is already doing work in this area, I'd be interested in
hearing from you as well.

Nominations:

Jason Cooper		(auto-nominated)
Andrew Lunn
Sebastian Hesselbarth	(auto-nominated)

thx,

Jason.

[1] http://eudyptula-challenge.org/
[2] http://www.matasano.com/articles/crypto-challenges/

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Sebastian Hesselbarth]

On 05/11/2014 07:30 AM, Jason Cooper wrote:
> During the proposal period for last year's KS, there was quite a bit of
> talk regarding maintainer survivorship.  imho, the best solution
> involves continuously bringing in new maintainers and developers as they
> crop up.  Should we encounter the unfortunate situation of needing to
> find a replacement, having plenty of pre-trained developers on hand
> gives us more flexibility.
> 
> As a hobbyist, I of course think the answer is recruiting more hobbyists
> into the ranks :)
> 
> Unfortunately, we ran out of time during the lightning round last year
> for me to give a short presentation on the topic of hobbyist recruiting.
> 
> I'm not a fan of reaching out in the direct sense.  I much prefer to
> keep my eye out for new comers who seek out the community and make sure
> they don't get ignored.  I know a lot of us have pretty aggressive mail
> filtering out of necessity.  For those interested in assisting me, I'd
> like to discuss creating some basic resources to facilitate spotting new
> comers and directing them as appropriate.
> 
> Something as simple as creating a separate mailbox and ruleset for
> senders we haven't seen before (with a few keywords to filter out the
> spam) would help greatly.
> 
> On a related topic, I've also started receiving patches from first time
> contributors who are taking part in the Eudyptula Challenge [1].  No, I
> hadn't heard of it either.  It's very similar to the Matasano Crypto
> Challenge [2], except that it builds up to contributing patches to the
> kernel.
> 
> If this topic is accepted, I'll give a status update on the hobbyists
> I've seen since the last KS, what work they've done (hint: those
> Chromecasts can boot mainline now ;-), I'll also compile some rough
> stats on first-time posters to the most popular email lists.  eg was it
> legit, did anyone respond, did the poster return?  Currently, I'm
> thinking lkml and lakml would be most relevant.  There may be other
> lists I'm not aware of.  Please let me know if that's the case.
> 
> If anyone is already doing work in this area, I'd be interested in
> hearing from you as well.

I copy Jason's proposal. Based on my last year's experience with the
hobbyist slot on ELC, I suggest to continue the effort. It was an
exciting experience and nice to see the people you know from the
mailing lists.

Although I think Ksummit would be more suited and more interesting
for Kernel hobbyists to attend than ELC was. The chance to meet known
people and participate in interesting topics is higher than on the
(IMHO) commercially orientated ELC.

Also, for the co-maintainer topic, I think some maintainers really
need some supporters reviewing the basic stuff already. There is
some maintainers who have people reducing the vast amount of patches,
but some others really need a helping hand.

IMHO, even hobbyists are suited for co-maintainership as it is a
good opportunity to get more insight into core kernel, common
mistakes, patch organization, and git workflow and we should
encourage promising recuitees early to constantly assist other
maintainers.

Sebastian

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Levente Kurusa]

[-- Attachment #1: Type: text/plain, Size: 4260 bytes --]

Hi,

On Sun, May 11, 2014 at 07:57:34PM +0200, Sebastian Hesselbarth wrote:
> On 05/11/2014 07:30 AM, Jason Cooper wrote:
> > During the proposal period for last year's KS, there was quite a bit of
> > talk regarding maintainer survivorship.  imho, the best solution
> > involves continuously bringing in new maintainers and developers as they
> > crop up.  Should we encounter the unfortunate situation of needing to
> > find a replacement, having plenty of pre-trained developers on hand
> > gives us more flexibility.
> > 
> > As a hobbyist, I of course think the answer is recruiting more hobbyists
> > into the ranks :)
> > 
> > Unfortunately, we ran out of time during the lightning round last year
> > for me to give a short presentation on the topic of hobbyist recruiting.
> > 
> > I'm not a fan of reaching out in the direct sense.  I much prefer to
> > keep my eye out for new comers who seek out the community and make sure
> > they don't get ignored.  I know a lot of us have pretty aggressive mail
> > filtering out of necessity.  For those interested in assisting me, I'd
> > like to discuss creating some basic resources to facilitate spotting new
> > comers and directing them as appropriate.
> > 
> > Something as simple as creating a separate mailbox and ruleset for
> > senders we haven't seen before (with a few keywords to filter out the
> > spam) would help greatly.
> > 
> > On a related topic, I've also started receiving patches from first time
> > contributors who are taking part in the Eudyptula Challenge [1].  No, I
> > hadn't heard of it either.  It's very similar to the Matasano Crypto
> > Challenge [2], except that it builds up to contributing patches to the
> > kernel.
> > 
> > If this topic is accepted, I'll give a status update on the hobbyists
> > I've seen since the last KS, what work they've done (hint: those
> > Chromecasts can boot mainline now ;-), I'll also compile some rough
> > stats on first-time posters to the most popular email lists.  eg was it
> > legit, did anyone respond, did the poster return?  Currently, I'm
> > thinking lkml and lakml would be most relevant.  There may be other
> > lists I'm not aware of.  Please let me know if that's the case.
> > 
> > If anyone is already doing work in this area, I'd be interested in
> > hearing from you as well.

For the past few months, I've been doing research on new contributors
and what I've found is there plenty of interest but people don't seem
to knwo where to start their journey. Another problem is that they
begin but fail to continue. They don't submit more than one patch.

Of course, the Eudyptula challenge did bring some new developers,
but as far as I see most of them posted only one patch/patchset.
Maybe, there is a way so that they will stay and work more?
Keep them somehow in the game, i.e. badges? Mozilla's Open Badges?

> 
> I copy Jason's proposal. Based on my last year's experience with the
> hobbyist slot on ELC, I suggest to continue the effort. It was an
> exciting experience and nice to see the people you know from the
> mailing lists.
> 
> Although I think Ksummit would be more suited and more interesting
> for Kernel hobbyists to attend than ELC was. The chance to meet known
> people and participate in interesting topics is higher than on the
> (IMHO) commercially orientated ELC.

Indeed, as a hobbyist I can second this!

And AFAIK last year the folks had some hobbyist spots.

> 
> Also, for the co-maintainer topic, I think some maintainers really
> need some supporters reviewing the basic stuff already. There is
> some maintainers who have people reducing the vast amount of patches,
> but some others really need a helping hand.
> 
> IMHO, even hobbyists are suited for co-maintainership as it is a
> good opportunity to get more insight into core kernel, common
> mistakes, patch organization, and git workflow and we should
> encourage promising recuitees early to constantly assist other
> maintainers.
> 
> Sebastian
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Greg KH]

On Sun, May 11, 2014 at 09:16:02PM +0200, Levente Kurusa wrote:
> Of course, the Eudyptula challenge did bring some new developers,
> but as far as I see most of them posted only one patch/patchset.

How do you know who is doing this challenge and who isn't?  I see a lot
of new people coming in with multiple sets of patches for cleanups and
good fixes over the past month or so.  Trying to track where they
actually come from is nothing I really care about, and is probably
impossible.

If you track the number of unique people I take patches from, it's
going up, as is our number of unique contributors to the kernel overall.
It's been constantly increasing for the past 8 years, ever since I
started tracking the kernel development statistics.

> Maybe, there is a way so that they will stay and work more?

I have loads of work for people to do if they want to do it:
	drivers/staging/*/TODO

> Keep them somehow in the game, i.e. badges? Mozilla's Open Badges?

Gamifaction?  Really?  No.

greg k-h

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Levente Kurusa]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

On Sun, May 11, 2014 at 09:26:30PM +0200, Greg KH wrote:
> On Sun, May 11, 2014 at 09:16:02PM +0200, Levente Kurusa wrote:
> > Of course, the Eudyptula challenge did bring some new developers,
> > but as far as I see most of them posted only one patch/patchset.
> 
> How do you know who is doing this challenge and who isn't?  I see a lot
> of new people coming in with multiple sets of patches for cleanups and
> good fixes over the past month or so.  Trying to track where they
> actually come from is nothing I really care about, and is probably
> impossible.

I've been thinking about the people who have said so in their
emails.

> 
> If you track the number of unique people I take patches from, it's
> going up, as is our number of unique contributors to the kernel overall.
> It's been constantly increasing for the past 8 years, ever since I
> started tracking the kernel development statistics.
> 
> > Maybe, there is a way so that they will stay and work more?
> 
> I have loads of work for people to do if they want to do it:
> 	drivers/staging/*/TODO
> 

I talk from my own experiences. I gave a talk recently and after the
talk people asked me how could they start. The problem, they say, is
that there really is no central TODO list. Maybe there could be a 
Documentation/NewcomersStartHere-like file that would list for
instance the TODO files in drivers/staging? It's nothing big, but
would certainly help people find their ways.

> > Keep them somehow in the game, i.e. badges? Mozilla's Open Badges?
> 
> Gamifaction?  Really?  No.
> 

Fedora is doing something like this as well.

Thanks,
    Levente Kurusa.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Hans Verkuil]

On 05/11/2014 09:50 PM, Levente Kurusa wrote:
> On Sun, May 11, 2014 at 09:26:30PM +0200, Greg KH wrote:
>> On Sun, May 11, 2014 at 09:16:02PM +0200, Levente Kurusa wrote:
>>> Of course, the Eudyptula challenge did bring some new developers,
>>> but as far as I see most of them posted only one patch/patchset.
>>
>> How do you know who is doing this challenge and who isn't?  I see a lot
>> of new people coming in with multiple sets of patches for cleanups and
>> good fixes over the past month or so.  Trying to track where they
>> actually come from is nothing I really care about, and is probably
>> impossible.
> 
> I've been thinking about the people who have said so in their
> emails.
> 
>>
>> If you track the number of unique people I take patches from, it's
>> going up, as is our number of unique contributors to the kernel overall.
>> It's been constantly increasing for the past 8 years, ever since I
>> started tracking the kernel development statistics.
>>
>>> Maybe, there is a way so that they will stay and work more?
>>
>> I have loads of work for people to do if they want to do it:
>> 	drivers/staging/*/TODO
>>
> 
> I talk from my own experiences. I gave a talk recently and after the
> talk people asked me how could they start. The problem, they say, is
> that there really is no central TODO list. Maybe there could be a 
> Documentation/NewcomersStartHere-like file that would list for
> instance the TODO files in drivers/staging? It's nothing big, but
> would certainly help people find their ways.

It certainly wouldn't hurt, but I'm not sure if this will really solve
much. In general all you have to do is find the subsystem mailinglist
(or email of the subsystem maintainer) you are interested in and post
an email offering to help. Generally there are always jobs available
that need doing.

My experience though is that there is a big gap between offering to do
some work and actually doing that, and at least as large a gap from
going from posting a single patch to becoming a regular contributor.

One issue might be that as a 'newbie' the problems you can work on
initially tend to be simple and often relatively boring ones (code cleanup,
sparse fixes, etc). Any work on core code often requires substantial
experience. And any work on specific drivers requires access to the right
hardware, which is often expensive to arrange or just plain hard to find.

I guess that this might be why most of the regular contributors started
out trying to support their own or their company's hardware. Which tends
to be a project at the right level: challenging yet typically not overly
difficult, and you learn a lot about the subsystem (software, process and
people).

In the media subsystem I work in there are enough drivers that need a lot
of TLC and would be an ideal starting point for a newbie. But how would
they obtain the hardware to test with and would they even be interested in
working on a driver for hardware that was already out of date 5 years ago,
let alone today?

I guess my point is that I wonder what the real problem is: are we driving
away newbies because of some bad practices on our side, or is it just
simply hard to find qualified and motivated developers?

Answers on a postcard...

Regards,

	Hans

>>> Keep them somehow in the game, i.e. badges? Mozilla's Open Badges?
>>
>> Gamifaction?  Really?  No.
>>
> 
> Fedora is doing something like this as well.
> 
> Thanks,
>     Levente Kurusa.
> 
> 
> 
> _______________________________________________
> Ksummit-discuss mailing list
> Ksummit-discuss@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/ksummit-discuss
> 

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Theodore Ts'o]

On Sun, May 11, 2014 at 10:33:21PM +0200, Hans Verkuil wrote:
> It certainly wouldn't hurt, but I'm not sure if this will really solve
> much. In general all you have to do is find the subsystem mailinglist
> (or email of the subsystem maintainer) you are interested in and post
> an email offering to help. Generally there are always jobs available
> that need doing.
> 
> My experience though is that there is a big gap between offering to do
> some work and actually doing that, and at least as large a gap from
> going from posting a single patch to becoming a regular contributor.

Perhaps something that's worth considering is the standard advice
given to people considering mentoring GSOC --- which is that you need
to spend at least 6-8 hours on your mentoring duties --- and after
doing that, about 25% of your mentees will end up hanging around
enough to contribute more to the project than the time invested in
said mentee; another 25% or so would more or less break even in terms
of time ROI, and then other 50% will end up being a net loss in terms
of time invested[1].  And that's for a student who is getting paid to
work full time for a few months.

[1] blogs.gnome.org/bolsh/2011/05/31/effective-mentoring-programs/

What this implies is that people who approach mentoring should do so
with some other goal than trying to get sh*t done.  A montor might be
trying to encourage more women to participate in open source, for
example.  And just as stock options in startup, if it pays off in
other ways, that's pure gravy --- but it's not anything should count
upon.

The same is true in many work environments, by the way.  In general, a
new employee needs at least 3 months, sometimes more, learning how to
use the build and debugging environent, before they can really be
counted upon to contribute in significant ways.  And that's for an
employee who is working full time!

The challenge with a hobbyist is from the perspective of the
maintainer, is that there is absolutely no guarantee that any
particular hobbyist is going to stick around.  And unlike a summer
intern or a new hire, the hobbist is in general not going to be
working full time.

As a result, it simply doesn't make any sense to expect most
maintainers to spend as much time as a intern mentor; since the
expected returns for a hobbyist showing up asking for help is most
likely going to be much less than for an summer intern.

> I guess my point is that I wonder what the real problem is: are we driving
> away newbies because of some bad practices on our side, or is it just
> simply hard to find qualified and motivated developers?

I'd say that it is extremely hard to find someone who is self-starting
enough who is able get started hacking on a subsystem or any open
source project on a part time basis, with minimal assistance from
maintainers who are, after all, trying to make sure they can scale
properly.

So some of this may be a matter of setting expectations.  I started
out as a hobbyist.  But I was spending at least 20+ hours/week of my
free time learning Linux on my free time --- 12 hours or so on the
weekends, plus 2-3 hours every evening or in the early mornings.  I
got essentially zero "support" from the project (which at the time,
was just Linus and a few other poeple like myself).  Linus did nothing
special to support me as a hobbyist, other than accepting patches if
they were good ones.  After all, he was a hobbyist himself at the time!  :-)

The one difference from the way things were in 1991 is that kernel has
gotten much more complicated, so it is true that it's a lot harder for
someone to get started from ground zero than I had.  (Although in my
case, it's true that also had several years of BSD 4.3 development
experience as a paid student systems programmer, had contributed
patches to perl and tcsh, and was the tech lead for Kerberos --- so as
far as an open source hobbyist was concerned, I was admittedly in a
fairly privileged position, even before I started working on Linux.)

However, the dynamic in terms of time and the return on investment
hasn't changed.  From a purely self-interested perspective, if you
have the choice of investing time bringing someone who has been
assigned to work full-time on your subsystem, perhaps at your company,
or perhaps at some other company, or taking that same time, and
investing it in a hobbyist --- what choice makes sense from a
rational, economically self-interested point of view?

							- Ted

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 573 bytes --]


> The one difference from the way things were in 1991 is that kernel has
> gotten much more complicated, so it is true that it's a lot harder for
> someone to get started from ground zero than I had.i

I tend to disagree partly. Sure, the the kernel core is much more
complicated these days. Still, if one likes playing with hardware, some
driver subsystems are still easy to get into, and most need help, too.
Stuff like I2C, SPI, 1wire and their slave devices, especially sensors.
Yes, it needs people with this amount of motivation to spend some time
and a few bucks.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 2396 bytes --]


> > that there really is no central TODO list. Maybe there could be a 
> > Documentation/NewcomersStartHere-like file that would list for
> > instance the TODO files in drivers/staging? It's nothing big, but
> > would certainly help people find their ways.

To be honest, I think it is something big. Keeping a file up-to-date
which has detailed information from various subsystems is quite some
task. More subsystem specific TODO files might be helpful, iff the
maintainer manages to keep it up to date. From a newbie, I'd expect to
find out how to find all TODO files in a kernel tree ;)

> It certainly wouldn't hurt, but I'm not sure if this will really solve
> much. In general all you have to do is find the subsystem mailinglist
> (or email of the subsystem maintainer) you are interested in and post
> an email offering to help. Generally there are always jobs available
> that need doing.

If you lurk around a mailing list of a subsystem (or read the gmane
archives), you will easily find out about its issues and shortcomings.

> My experience though is that there is a big gap between offering to do
> some work and actually doing that, and at least as large a gap from
> going from posting a single patch to becoming a regular contributor.

+1

> One issue might be that as a 'newbie' the problems you can work on
> initially tend to be simple and often relatively boring ones (code cleanup,
> sparse fixes, etc). Any work on core code often requires substantial
> experience.

For me, I am not so much short of patches, I am short of reviewers. And
that needs some time and good will of a new person to get into it.
Reading old reviews, playing with the subsystem ("why is it done this
way?"), digging through git history to understand the organic growth...

> I guess that this might be why most of the regular contributors started
> out trying to support their own or their company's hardware. Which tends
> to be a project at the right level: challenging yet typically not overly
> difficult, and you learn a lot about the subsystem (software, process and
> people).

Agree. That is why I point people to OpenWRT which has tons of hardware
support which is not mainline. And old routers can quite easily be
obtained. Yet, one must be willing enough to get support of a mostly
outdated HW into the kernel, just for the fun of it.


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Li Zefan]

On 2014/5/12 16:38, Wolfram Sang wrote:
> 
>>> that there really is no central TODO list. Maybe there could be a 
>>> Documentation/NewcomersStartHere-like file that would list for
>>> instance the TODO files in drivers/staging? It's nothing big, but
>>> would certainly help people find their ways.
> 
> To be honest, I think it is something big. Keeping a file up-to-date
> which has detailed information from various subsystems is quite some
> task. More subsystem specific TODO files might be helpful, iff the
> maintainer manages to keep it up to date. From a newbie, I'd expect to
> find out how to find all TODO files in a kernel tree ;)
> 

This was once discussed in Kernel Summit.

http://lwn.net/Articles/412639/

"Part of the problem, it seems, is that these lists tend not to be "sexy";
maintainers tend to keep the more interesting tasks for themselves."

Which I myself have to admit. :)

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Hans Verkuil]

On 05/12/2014 11:08 AM, Li Zefan wrote:
> On 2014/5/12 16:38, Wolfram Sang wrote:
>>
>>>> that there really is no central TODO list. Maybe there could be a 
>>>> Documentation/NewcomersStartHere-like file that would list for
>>>> instance the TODO files in drivers/staging? It's nothing big, but
>>>> would certainly help people find their ways.
>>
>> To be honest, I think it is something big. Keeping a file up-to-date
>> which has detailed information from various subsystems is quite some
>> task. More subsystem specific TODO files might be helpful, iff the
>> maintainer manages to keep it up to date. From a newbie, I'd expect to
>> find out how to find all TODO files in a kernel tree ;)
>>
> 
> This was once discussed in Kernel Summit.
> 
> http://lwn.net/Articles/412639/
> 
> "Part of the problem, it seems, is that these lists tend not to be "sexy";
> maintainers tend to keep the more interesting tasks for themselves."
> 
> Which I myself have to admit. :)
> 

But how many of those interesting tasks are suitable for beginners? If it is
interesting for a maintainer, then I think it is very unlikely to be suitable
for someone with little experience.

We are trying to find people who are good programmers, are motivated, have
the time to spend many hours per week *of their own time* on these projects
and are willing to do that unpaid (which is typical for a beginner). Rare as
hen's teeth.

If someone shows up on a mailinglist who demonstrates those qualities, then
I'm sure any self-respecting maintainer will go out of their way to help
them. I know I would.

My opinion is that there is nothing wrong with mentoring programs as such,
but don't do it with the expectation to get fresh kernel developer blood.

I've mentored a few summer interns doing open source work and in all cases
got more out of them then I put in, but none of them became regular
contributors (which is a shame, since some were really good).

I found it a useful method to get projects done for which I had no time,
for the interns to learn about the company and open source world, and I
actually enjoy mentoring. And with luck they might try to find a job at
the company after finishing their education.

But it's not a magic bullet that will suddenly give you a new crop of
active open source contributors, let alone new subsystem maintainers.

Those that are actually interested in doing that will find their way
regardless of any mentoring programs.

In my opinion it is similar to the current craze of teaching everyone to
code. I don't believe that will result in a single competent new programmer.
Those that are really interested and motivated in the topic will find their
own way, and helping those will be much more useful.

Regards,

	Hans

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 779 bytes --]


> >>> that there really is no central TODO list. Maybe there could be a 
> >>> Documentation/NewcomersStartHere-like file that would list for
> >>> instance the TODO files in drivers/staging? It's nothing big, but
> >>> would certainly help people find their ways.
> > 
> > To be honest, I think it is something big. Keeping a file up-to-date
> > which has detailed information from various subsystems is quite some
> > task. More subsystem specific TODO files might be helpful, iff the
> > maintainer manages to keep it up to date. From a newbie, I'd expect to
> > find out how to find all TODO files in a kernel tree ;)
> > 
> 
> This was once discussed in Kernel Summit.
> 
> http://lwn.net/Articles/412639/

Unsurprisingly, all that stands well today :)


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Andrew Lunn]

> Agree. That is why I point people to OpenWRT which has tons of hardware
> support which is not mainline. And old routers can quite easily be
> obtained. Yet, one must be willing enough to get support of a mostly
> outdated HW into the kernel, just for the fun of it.

I've had some success contacting the authors of kirkwood SoC based
board ports that are in OpenWRT and asking them to contribute there
patches to mainline. It has not been too much effort helping them
clean up the contribution to get the code in mainline. Nobody has made
the transition to a regular contributer, but they do tend to help with
testing when patches affect there board and you ask for tests.

arch/arm/boot/dts$ ls -1 *.dts | cut -f 1 -d - | sort | uniq -c| sort -rn

     57 kirkwood
     33 omap3
     19 imx6q
     18 imx28
     14 armada
     12 imx6dl
     10 tegra20
      9 ste
      9 imx53
      7 sun4i
      7 omap4
      6 am335x
      5 imx27
  
With the usual declaimer of lies, damn lies, and statistics, it looks
like we are doing something right. And kirkwood is mostly hobbyist
maintained.

     Andrew

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Stephen Hemminger]

My impression is that although a small number of new developers come from the hobbyist
ranks, the large majority come from companies that are developing products that use Linux.
As Greg says if the hobbyist contributes they get hired up by some company in today's market.

I would be interested in hearing success and failures of others in getting these corporate
developers to contribute and get involved upstream. It can be a management issue, it could
be personal fears or it could be cultural but in my experience many talented people still shy
away from contributing to any upstream project.

In my world, the problem isn't hobbyist recruiting but internal recruiting; and keeping the
good people contributing instead of going off to other projects.

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Jason Cooper]

On Sun, May 11, 2014 at 09:26:30PM +0200, Greg KH wrote:
> On Sun, May 11, 2014 at 09:16:02PM +0200, Levente Kurusa wrote:
> > Of course, the Eudyptula challenge did bring some new developers,
> > but as far as I see most of them posted only one patch/patchset.
> 
> How do you know who is doing this challenge and who isn't?  I see a lot
> of new people coming in with multiple sets of patches for cleanups and
> good fixes over the past month or so.

Is it mostly in the staging tree?  That's where I really got my feet wet
when I started.  Assisting with code cleanup isn't glamorous, but it's a
good place to learn the ropes.  And the staging tree is, imho, a more
receptive place for cleanup patches.  Since the code isn't kernel
qwality to begin with.

> Trying to track where they actually come from is nothing I really care
> about, and is probably impossible.

Agreed.

> If you track the number of unique people I take patches from, it's
> going up, as is our number of unique contributors to the kernel overall.
> It's been constantly increasing for the past 8 years, ever since I
> started tracking the kernel development statistics.

Cool, I didn't know you were actively tracking that.  Is the data
publicly hosted?  Is that based on merged patches, or posted emails?

> > Maybe, there is a way so that they will stay and work more?
> 
> I have loads of work for people to do if they want to do it:
> 	drivers/staging/*/TODO
> 
> > Keep them somehow in the game, i.e. badges? Mozilla's Open Badges?
> 
> Gamifaction?  Really?  No.

Pointing to the TODO lists is sufficient.  I don't think we would be
doing the community any favors by encouraging developers who want a
cookie for everything they did.

My primary goal is to draw attention to the issue of aggressive mail
filtering, new devs can pop up anywhere, and acknowledging them.  By
acknowledge, I mean answering the email, and treating them like everyone
else.  But we have to spot the emails first.

thx,

Jason.

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Greg KH]

On Mon, May 12, 2014 at 12:38:38PM -0400, Jason Cooper wrote:
> On Sun, May 11, 2014 at 09:26:30PM +0200, Greg KH wrote:
> > On Sun, May 11, 2014 at 09:16:02PM +0200, Levente Kurusa wrote:
> > > Of course, the Eudyptula challenge did bring some new developers,
> > > but as far as I see most of them posted only one patch/patchset.
> > 
> > How do you know who is doing this challenge and who isn't?  I see a lot
> > of new people coming in with multiple sets of patches for cleanups and
> > good fixes over the past month or so.
> 
> Is it mostly in the staging tree?  That's where I really got my feet wet
> when I started.  Assisting with code cleanup isn't glamorous, but it's a
> good place to learn the ropes.  And the staging tree is, imho, a more
> receptive place for cleanup patches.  Since the code isn't kernel
> qwality to begin with.

Most of the cleanup is in the staging tree that I see, given that I'm
the maintainer of it, and we need lots of cleanup there :)

> > If you track the number of unique people I take patches from, it's
> > going up, as is our number of unique contributors to the kernel overall.
> > It's been constantly increasing for the past 8 years, ever since I
> > started tracking the kernel development statistics.
> 
> Cool, I didn't know you were actively tracking that.  Is the data
> publicly hosted?  Is that based on merged patches, or posted emails?

It's based on merged patches, and can all be found at:
	https://github.com/gregkh/kernel-history
along with the scripts that generate the numbers.

> My primary goal is to draw attention to the issue of aggressive mail
> filtering, new devs can pop up anywhere, and acknowledging them.  By
> acknowledge, I mean answering the email, and treating them like everyone
> else.  But we have to spot the emails first.

Why would someone "new" be treated any differently?  Everyone should be
treated with the same response and respect.

greg k-h

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Jason Cooper]

On Tue, May 13, 2014 at 01:23:02AM +0200, Greg KH wrote:
> On Mon, May 12, 2014 at 12:38:38PM -0400, Jason Cooper wrote:
> > On Sun, May 11, 2014 at 09:26:30PM +0200, Greg KH wrote:
...
> > > If you track the number of unique people I take patches from, it's
> > > going up, as is our number of unique contributors to the kernel overall.
> > > It's been constantly increasing for the past 8 years, ever since I
> > > started tracking the kernel development statistics.
> > 
> > Cool, I didn't know you were actively tracking that.  Is the data
> > publicly hosted?  Is that based on merged patches, or posted emails?
> 
> It's based on merged patches, and can all be found at:
> 	https://github.com/gregkh/kernel-history
> along with the scripts that generate the numbers.

Great!  Thanks.

> > My primary goal is to draw attention to the issue of aggressive mail
> > filtering, new devs can pop up anywhere, and acknowledging them.  By
> > acknowledge, I mean answering the email, and treating them like everyone
> > else.  But we have to spot the emails first.
> 
> Why would someone "new" be treated any differently?  Everyone should be
> treated with the same response and respect.

I fully agree.  I'm concerned that my 'recruiting' mantra may be
mis-read as 'coddle the newbie and don't make any sudden movements'.
Which I am emphatically _not_ saying.  We are in complete agreement wrt
treating everyone exactly the same.

I'd like to quantify responses, or lack thereof, to first-timers on the
primary mailinglists.  From that data, determine *if* anything needs to
be tweaked.  For me personally, I'll explicitly add a mailfilter to catch
first-time posters so that I can advise/direct them appropriately.

If others are interested in assisting in that effort, I'll post any
needed bits I've generated that are easy to integrate into the numerous
email workflows we all have.

thx,

Jason.

Re: [Ksummit-discuss] [CORE TOPIC] hobbyist recruiting

[Dan Carpenter]

On Sun, May 11, 2014 at 09:50:11PM +0200, Levente Kurusa wrote:
> I gave a talk recently and after the talk people asked me how could
> they start. The problem, they say, is that there really is no central
> TODO list.

I have invented a new email tag for this.  When I think of something to
do then I put it my email:

TODO-list: 2014-05-21: lirc: LIRC_GET_FEATURES API is sometimes ulong and sometimes u32

Then I can `grep ^TODO-list: inbox` and create a TODO list automatically
and anyone else can send stuff as well.

regards,
dan carpenter