Contributor pathways, engagement points and bug mentoring

classic Classic list List threaded Threaded
59 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Contributor pathways, engagement points and bug mentoring

mhoye
Hi, everyone -

Like the title says, I've written up a couple of things about:

Code-specific contributor pathways:
https://wiki.mozilla.org/Contribute/Coding/Pathways

Engagement points: https://wiki.mozilla.org/Contribute/Coding/Engagement

and Mentoring / Good First Bugs:
https://wiki.mozilla.org/Contribute/Coding/Mentoring

... at some length, because I love me some big words and that's how I
roll. I'll spare you the details; they're there if you're interested. In
short:

- The Pathways doc outlines contribution tiers, how we're going to
measure engagement at every level, and some starting practices for
retention and reward. Most of it is generally of the form "We know it's
important to get back to new contributors promptly, so please let's do
that. When they finish a bug, thank them and suggest the next one."

- The Engagement  doc lists the various ways that various people can put
interesting stuff in front of interested peoples' eyes.  If I had to fit
this doc into a tweet, it would be "Choice paralysis is real, you don't
need to reinvent any wheels, we're here to help."

- The Mentoring doc spells out what makes a good first bug and a
well-functioning mentoring relationship. At the moment, most of our
good-first-bugs just aren't and a lot of contributors are getting
unintentionally pitched overboard -
  https://bugzilla.mozilla.org/show_bug.cgi?id=989476 aims to fix one
such example - so I intend make auditing and automating those processes
a q2 goal.

I'd like to get us to contributor parity - the same number of paid
engineers as volunteer contributors getting patches in every product
cycle - within the next four releases. So I'm going to try to make that
happen.

Thanks.

- mhoye




_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Nicholas Alexander
On 2014-03-30, 1:49 PM, Mike Hoye wrote:
> Hi, everyone -
>
> Like the title says, I've written up a couple of things about:

Just wanted to say that these are valuable (I specifically bookmarked
Pathways) and that they led me to all the curated content under
Contribute/.  Thanks for spending time to write down concrete best
practices for how to help grow our Mozilla community.

Best,
Nick
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Josh Matthews-4
In reply to this post by mhoye
On 03/30/2014 04:49 PM, Mike Hoye wrote:
> - The Pathways doc outlines contribution tiers, how we're going to
> measure engagement at every level, and some starting practices for
> retention and reward. Most of it is generally of the form "We know it's
> important to get back to new contributors promptly, so please let's do
> that. When they finish a bug, thank them and suggest the next one."

One strategy I've started suggesting to mentors is to _offer_ to suggest
a next bug to work on. This allows the mentor to acknowledge the success
immediately, while giving them time to prepare an appropriate followup
if necessary.

Cheers,
Josh
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Chris Peterson-12
In reply to this post by mhoye
On 3/30/14, 1:49 PM, Mike Hoye wrote:
> I'd like to get us to contributor parity - the same number of paid
> engineers as volunteer contributors getting patches in every product
> cycle - within the next four releases. So I'm going to try to make that
> happen.

This is an exciting plan! What is our current ratio of patches from
employee vs volunteer contributors? How do you determine whether a patch
is from Mozilla employee? Many employees' Bugzilla accounts and patches
use their personal email addresses instead of mozilla.com addresses.


chris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Josh Matthews-4
On 03/31/2014 01:15 AM, Chris Peterson wrote:

> On 3/30/14, 1:49 PM, Mike Hoye wrote:
>> I'd like to get us to contributor parity - the same number of paid
>> engineers as volunteer contributors getting patches in every product
>> cycle - within the next four releases. So I'm going to try to make that
>> happen.
>
> This is an exciting plan! What is our current ratio of patches from
> employee vs volunteer contributors? How do you determine whether a patch
> is from Mozilla employee? Many employees' Bugzilla accounts and patches
> use their personal email addresses instead of mozilla.com addresses.
>
>
> chris

Employee status is derived from the list of email addresses obtained via
https://github.com/jdm/outrider/blob/master/generate_emails.py , which
scrapes from all email fields in the internal phonebook. I am aware of
very few inaccuracies, since most employees have been happy to update
their entry with addresses they use.

Cheers,
Josh
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

mhoye
In reply to this post by Chris Peterson-12
On 2014-03-31, 1:15 AM, Chris Peterson wrote:
>
> This is an exciting plan! What is our current ratio of patches from
> employee vs volunteer contributors?
We're generally floating around 50% per rapid release now; I'll have
some better historical and trend data to share shortly.


- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

David Rajchenbach-Teller-2
In reply to this post by Josh Matthews-4
At some point, we should start thinking about a contributor dashboard,
which would handle both Bugs Ahoy and "Find a next bug".

On 3/31/14 4:03 AM, Josh Matthews wrote:

> One strategy I've started suggesting to mentors is to _offer_ to suggest
> a next bug to work on. This allows the mentor to acknowledge the success
> immediately, while giving them time to prepare an appropriate followup
> if necessary.
>
> Cheers,
> Josh
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning


--
David Rajchenbach-Teller, PhD
 Performance Team, Mozilla
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Gavin Sharp-3
In reply to this post by mhoye
Great stuff. A couple of points of feedback:

- https://wiki.mozilla.org/Contribute/Coding/Engagement#Mailing_lists

This should probably include firefox-dev?
(https://wiki.mozilla.org/Firefox/firefox-dev)

- https://wiki.mozilla.org/Contribute/Coding/Pathways

I think this is missing some important bug triage activities. Beyond
"filing" and "reproducing" and "creating a testcase", there's a lot of
value in "marking duplicates" or "confirming bugs" (and the
prerequisite step to those, "gaining editbugs privileges"). These are
how I got sucked in to Mozilla, and it's what eventually led me to
code contributions.

Gavin

On Sun, Mar 30, 2014 at 1:49 PM, Mike Hoye <[hidden email]> wrote:

> Hi, everyone -
>
> Like the title says, I've written up a couple of things about:
>
> Code-specific contributor pathways:
> https://wiki.mozilla.org/Contribute/Coding/Pathways
>
> Engagement points: https://wiki.mozilla.org/Contribute/Coding/Engagement
>
> and Mentoring / Good First Bugs:
> https://wiki.mozilla.org/Contribute/Coding/Mentoring
>
> ... at some length, because I love me some big words and that's how I roll.
> I'll spare you the details; they're there if you're interested. In short:
>
> - The Pathways doc outlines contribution tiers, how we're going to measure
> engagement at every level, and some starting practices for retention and
> reward. Most of it is generally of the form "We know it's important to get
> back to new contributors promptly, so please let's do that. When they finish
> a bug, thank them and suggest the next one."
>
> - The Engagement  doc lists the various ways that various people can put
> interesting stuff in front of interested peoples' eyes.  If I had to fit
> this doc into a tweet, it would be "Choice paralysis is real, you don't need
> to reinvent any wheels, we're here to help."
>
> - The Mentoring doc spells out what makes a good first bug and a
> well-functioning mentoring relationship. At the moment, most of our
> good-first-bugs just aren't and a lot of contributors are getting
> unintentionally pitched overboard -
>  https://bugzilla.mozilla.org/show_bug.cgi?id=989476 aims to fix one such
> example - so I intend make auditing and automating those processes a q2
> goal.
>
> I'd like to get us to contributor parity - the same number of paid engineers
> as volunteer contributors getting patches in every product cycle - within
> the next four releases. So I'm going to try to make that happen.
>
> Thanks.
>
> - mhoye
>
>
>
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

mhoye
On 2014-04-06, 3:32 PM, Gavin Sharp wrote:
> Great stuff. A couple of points of feedback:
>
> - https://wiki.mozilla.org/Contribute/Coding/Engagement#Mailing_lists
>
> This should probably include firefox-dev?
> (https://wiki.mozilla.org/Firefox/firefox-dev)
It should - there are a few missing fora that need to go in there,
including firefox-dev.
>
> - https://wiki.mozilla.org/Contribute/Coding/Pathways
>
> I think this is missing some important bug triage activities. Beyond
> "filing" and "reproducing" and "creating a testcase", there's a lot of
> value in "marking duplicates" or "confirming bugs" (and the
> prerequisite step to those, "gaining editbugs privileges"). These are
> how I got sucked in to Mozilla, and it's what eventually led me to
> code contributions.

A strong point, I'll add that.

- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

mhoye
In reply to this post by mhoye
On 2014-03-31, 11:25 AM, Mike Hoye wrote:
> On 2014-03-31, 1:15 AM, Chris Peterson wrote:
>>
>> This is an exciting plan! What is our current ratio of patches from
>> employee vs volunteer contributors?
> We're generally floating around 50% per rapid release now; I'll have
> some better historical and trend data to share shortly.

Ah, yeah - to clear this up, this really means "we have half as many
non-employees contributing as employees per rapid-release". And that's
people - as you might imagine, the ratio in terms of patches contributed
is much lower.

Some good news, following on from this last two weeks, is that uptake on
@startmozilla seems to be trending in the right direction and new people
are still showing up to work on stuff. "New contributors" and
"contributor retention" are only proxy measurements for the high-value,
long-term contributors we really want, obviously, but as metrics go
they're non-terrible and and it looks like we can move the needles on
those gauges meaningfully in the near term.

Some bad news is that the cultural impedance between our reliance on  
NeedInfo and new contributors arriving from "ask" cultures is worse than
I thought.

To sum up - by relying exclusively on needinfo to know what bugs to look
at, we're losing a lot of potential contributors who ask for permission
to participate in a bug comment, get a demoralizing silence in response
and leave. The forty or so instances of this I've found - and these are
just the ones I've found, mind you - all have that same pattern, and
possibly worse, they're almost all coming from markets - mostly India
and southeast Asia - where we really want to make a lot of new friends.

I've filed bug 989476 -
https://bugzilla.mozilla.org/show_bug.cgi?id=989476 - to mitigate
somewhat, the TL;DR being is that if you've agreed to be a mentor in a
bug, any comment from a "new to bugzilla" contributor will trip the
needinfo flag. If you've got strong feelings about that for or against,
that's where to register them.

- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Gavin Sharp-3
On Tue, Apr 15, 2014 at 6:54 AM, Mike Hoye <[hidden email]> wrote:

> Some bad news is that the cultural impedance between our reliance on
> NeedInfo and new contributors arriving from "ask" cultures is worse than I
> thought.
>
> To sum up - by relying exclusively on needinfo to know what bugs to look at,
> we're losing a lot of potential contributors who ask for permission to
> participate in a bug comment, get a demoralizing silence in response and
> leave. The forty or so instances of this I've found - and these are just the
> ones I've found, mind you - all have that same pattern, and possibly worse,
> they're almost all coming from markets - mostly India and southeast Asia -
> where we really want to make a lot of new friends.

Speaking based on personal experience, I think such comments tend to
be ignored because they very infrequently lead to a positive new
contributor interaction, and not because of any "reliance on
needinfo".

Feels like there's probably room to tackle this from the other angle -
i.e. teaching people they don't need to "ask first".

Gavin
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Gijs Kruitbosch ("Hannibal")
In reply to this post by mhoye
On 15/04/2014 22:29, Gavin Sharp wrote:
> Feels like there's probably room to tackle this from the other angle -
> i.e. teaching people they don't need to "ask first".

This.

And also, hard choices about what kind of engagement we do and how
selective we are about contributors that don't seem to "get" this or be
able to work without asking. And more asking. And more asking.

I've had a few experiences now where people responding to good first
bugs or mentored bugs had to be handheld to such a degree (ie,
essentially needed literal instructions along the line of "what exact,
character-by-character, code changes do I need to make to fix this
bug"), and even didn't manage to do what was asked ("please run these
tests with ./mach mochitest-browser foo" - "I've run them and they pass"
- push code, break tree because those exact tests fail).

This makes me reluctant to sign up to mentoring bugs, because this way,
bugs repeatedly take orders of magnitude more time from me than they
would have done if I'd fixed them myself, with no discernible advantage
to myself or the project (aforementioned types of contributors move on
to other bugs with the same method, taking just as much time from myself
or others, and/or disappear).

To be clear, I understand that we need to invest in enlarging the
community, and that this takes time and effort, and that it's expected
and OK that the first (few) bug(s) that someone fixes take more time
from the mentor than fixing it would have done had they done it
themselves, and that not everyone sticks around. And that's fine. But
the degree to which I've seen people's (not just my own) time being
eaten up by certain aspiring contributors was very demotivating, and I
wonder what, if anything, we can/are do(ing) to fix this.

~ Gijs
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Ehsan Akhgari
On 2014-04-15, 6:09 PM, Gijs Kruitbosch wrote:
> On 15/04/2014 22:29, Gavin Sharp wrote:
>> Feels like there's probably room to tackle this from the other angle -
>> i.e. teaching people they don't need to "ask first".
>
> This.
>
> And also, hard choices about what kind of engagement we do and how
> selective we are about contributors that don't seem to "get" this or be
> able to work without asking. And more asking. And more asking.

That is very unfair to people who are coming from cultures where jumping
in the middle of something without asking for permission first is
considered a very impolite thing to do.  We're not talking about typical
Western cultures that we mostly operate under.

> I've had a few experiences now where people responding to good first
> bugs or mentored bugs had to be handheld to such a degree (ie,
> essentially needed literal instructions along the line of "what exact,
> character-by-character, code changes do I need to make to fix this
> bug"), and even didn't manage to do what was asked ("please run these
> tests with ./mach mochitest-browser foo" - "I've run them and they pass"
> - push code, break tree because those exact tests fail).

I think this is a separate issue.  Not every contributor is going to be
as savvy as all others.

> This makes me reluctant to sign up to mentoring bugs, because this way,
> bugs repeatedly take orders of magnitude more time from me than they
> would have done if I'd fixed them myself, with no discernible advantage
> to myself or the project (aforementioned types of contributors move on
> to other bugs with the same method, taking just as much time from myself
> or others, and/or disappear).
>
> To be clear, I understand that we need to invest in enlarging the
> community, and that this takes time and effort, and that it's expected
> and OK that the first (few) bug(s) that someone fixes take more time
> from the mentor than fixing it would have done had they done it
> themselves, and that not everyone sticks around. And that's fine. But
> the degree to which I've seen people's (not just my own) time being
> eaten up by certain aspiring contributors was very demotivating, and I
> wonder what, if anything, we can/are do(ing) to fix this.

Speaking from my personal experience when I first started to contribute
to Mozilla, it took me a *month* to be able to build the code base
locally.  During that time a couple of individuals continued to try
their best to help me along the way.  And without that, I would have
never stuck around the project.

The goal of attracting new contributors is not to help our engineers get
stuff done faster.  It is to attract new talent to the project who can
help drive it forward in ways that no single contributor can.  It's OK
if someone doesn't have time to help with that (I rarely have enough
time for that these days myself) but let's not forget the bigger picture
here.

Cheers,
Ehsan

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

RE: Contributor pathways, engagement points and bug mentoring

Mike Connor-4
To add to this: a great many of us "didn't get it" early on.  Mozilla code
is hard and daunting at first, and there are many ways to get lost.  If I
didn't have bz/dwitte/timeless patiently answering questions, I'd have
bounced in 2003 without ever getting a build working, let alone
accomplishing anything I've done in the ensuing decade.  Without outing
people on this list, there are many established Firefox hackers who needed
a lot of support in the early days.  If we aren't providing that support
and guidance, we'll miss out.

Is it fun? Not always. Do we all have other things we could be doing?
Sure.  Is it an essential part of how we bring people in (and how we learn
to be better ourselves)? Absolutely.

-- Mike

-----Original Message-----
From: dev-planning
[mailto:dev-planning-bounces+mconnor=[hidden email]] On
Behalf Of Ehsan Akhgari
Sent: April 15, 2014 6:17 PM
To: Gijs Kruitbosch; [hidden email]
Subject: Re: Contributor pathways, engagement points and bug mentoring

[Mike Connor] <snip>

Speaking from my personal experience when I first started to contribute to
Mozilla, it took me a *month* to be able to build the code base locally.
During that time a couple of individuals continued to try their best to
help me along the way.  And without that, I would have never stuck around
the project.

The goal of attracting new contributors is not to help our engineers get
stuff done faster.  It is to attract new talent to the project who can
help drive it forward in ways that no single contributor can.  It's OK if
someone doesn't have time to help with that (I rarely have enough time for
that these days myself) but let's not forget the bigger picture here.

Cheers,
Ehsan

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Gijs Kruitbosch ("Hannibal")
In reply to this post by Ehsan Akhgari
It seems my message wasn't clear, although I sort of saw this response
coming and tried to pre-empt it - evidently I failed.

I'm not complaining about people generally needing, and asking for, help.

9-odd years ago, when I started to contribute as a volunteer, I also
needed a lot of help. Heck, to "out" myself here: I needed help
understanding some of the programming language at issue (nobody had ever
told me String.replace() could take a function as the second argument!
(and JS was different from VBScript (yes...) in surprising ways)).
If/when I fix the occasional C++/objc bug, I need help with some of our
internals (and sometimes the language - clang helped a lot because the
error messages are so much better), still.

But needing help and needing literally all the things handed to you on a
silver platter are not the same.

I actually think we should be spending more time than we are on engaging
with new contributors (and it's something I plan on doing now that
Australis is finally being released). However, I also think we should be
careful about where and how we spend our efforts.

The time all of us, collectively, can spend on helping new contributors
up to speed is a limited resource. It would be nice if we could optimize
its usage better than we currently do.

Perhaps I (and one or two other people who mentored similar contributors
and with whom I've discussed this when these particular contributors
were active) were the only people affected, and the issue I'm bringing
up is such a minority case we don't need to worry about it. I hope so!
But if not, we should figure out how/where to draw a line.

It's never felt right to me to say "no" to someone who wants to own a
bug, but if previous evidence strongly suggests they don't stand a
chance of fixing them and will "occupy" the mentored bug when we only
have a limited number of them (seriously,
http://www.joshmatthews.net/bugsahoy/?ff=1&unowned=1 has very few bugs
that have never been (unsuccessfully) owned, so bugs with the right
difficulty level for first contributors are clearly hard to come by**),
then I would love to have a better way to respond than letting the
inevitable happen when I do assign them the bug.

~ Gijs

** which probably means we should also think harder on the fx desktop
team about which bugs could be such bugs, and how to make more of them!
Many of those bugs are devtools bugs, and there doesn't appear to be a
way to filter those as compared to the rest of Fx desktop; Without data,
I do believe the devtools team has been doing a better job in terms of
mentored bugs than we have.

On 15/04/2014 23:36, Mike Connor wrote:

> To add to this: a great many of us "didn't get it" early on.  Mozilla code
> is hard and daunting at first, and there are many ways to get lost.  If I
> didn't have bz/dwitte/timeless patiently answering questions, I'd have
> bounced in 2003 without ever getting a build working, let alone
> accomplishing anything I've done in the ensuing decade.  Without outing
> people on this list, there are many established Firefox hackers who needed
> a lot of support in the early days.  If we aren't providing that support
> and guidance, we'll miss out.
>
> Is it fun? Not always. Do we all have other things we could be doing?
> Sure.  Is it an essential part of how we bring people in (and how we learn
> to be better ourselves)? Absolutely.
>
> -- Mike
>
> -----Original Message-----
> From: dev-planning
> [mailto:dev-planning-bounces+mconnor=[hidden email]] On
> Behalf Of Ehsan Akhgari
> Sent: April 15, 2014 6:17 PM
> To: Gijs Kruitbosch; [hidden email]
> Subject: Re: Contributor pathways, engagement points and bug mentoring
>
> [Mike Connor] <snip>
>
> Speaking from my personal experience when I first started to contribute to
> Mozilla, it took me a *month* to be able to build the code base locally.
> During that time a couple of individuals continued to try their best to
> help me along the way.  And without that, I would have never stuck around
> the project.
>
> The goal of attracting new contributors is not to help our engineers get
> stuff done faster.  It is to attract new talent to the project who can
> help drive it forward in ways that no single contributor can.  It's OK if
> someone doesn't have time to help with that (I rarely have enough time for
> that these days myself) but let's not forget the bigger picture here.
>
> Cheers,
> Ehsan
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Gavin Sharp-3
In reply to this post by Mike Connor-4
Straw man alert: No one is arguing for "not providing support and guidance".

Nor did I intend to suggest that "teaching people not to ask" is the
only option - I very explicitly mentioned that this should be tackled
from both angles.

My point (and I think Gijs' as well)  is just that not all people who
express a desire to contribute can be successful in doing so, for
various reasons, and "respond more to people's comments" on its own is
unlikely to be a cost-effective or scalable solution. We need to have
systematic solutions for avoiding expending large amounts of effort
for minimal return, and efficient ways to direct potential
contributors to the right opportunities.

I know mhoye has given those problems lots of thought, so this isn't
news to him, but it felt worth clarifying in the context of this
thread.

Gavin

On Tue, Apr 15, 2014 at 3:36 PM, Mike Connor <[hidden email]> wrote:

> To add to this: a great many of us "didn't get it" early on.  Mozilla code
> is hard and daunting at first, and there are many ways to get lost.  If I
> didn't have bz/dwitte/timeless patiently answering questions, I'd have
> bounced in 2003 without ever getting a build working, let alone
> accomplishing anything I've done in the ensuing decade.  Without outing
> people on this list, there are many established Firefox hackers who needed
> a lot of support in the early days.  If we aren't providing that support
> and guidance, we'll miss out.
>
> Is it fun? Not always. Do we all have other things we could be doing?
> Sure.  Is it an essential part of how we bring people in (and how we learn
> to be better ourselves)? Absolutely.
>
> -- Mike
>
> -----Original Message-----
> From: dev-planning
> [mailto:dev-planning-bounces+mconnor=[hidden email]] On
> Behalf Of Ehsan Akhgari
> Sent: April 15, 2014 6:17 PM
> To: Gijs Kruitbosch; [hidden email]
> Subject: Re: Contributor pathways, engagement points and bug mentoring
>
> [Mike Connor] <snip>
>
> Speaking from my personal experience when I first started to contribute to
> Mozilla, it took me a *month* to be able to build the code base locally.
> During that time a couple of individuals continued to try their best to
> help me along the way.  And without that, I would have never stuck around
> the project.
>
> The goal of attracting new contributors is not to help our engineers get
> stuff done faster.  It is to attract new talent to the project who can
> help drive it forward in ways that no single contributor can.  It's OK if
> someone doesn't have time to help with that (I rarely have enough time for
> that these days myself) but let's not forget the bigger picture here.
>
> Cheers,
> Ehsan
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Trevor Saunders
In reply to this post by Gijs Kruitbosch ("Hannibal")
On Tue, Apr 15, 2014 at 11:58:32PM +0100, Gijs Kruitbosch wrote:

> It seems my message wasn't clear, although I sort of saw this response
> coming and tried to pre-empt it - evidently I failed.
>
> I'm not complaining about people generally needing, and asking for, help.
>
> 9-odd years ago, when I started to contribute as a volunteer, I also needed
> a lot of help. Heck, to "out" myself here: I needed help understanding some
> of the programming language at issue (nobody had ever told me
> String.replace() could take a function as the second argument! (and JS was
> different from VBScript (yes...) in surprising ways)). If/when I fix the
> occasional C++/objc bug, I need help with some of our internals (and
> sometimes the language - clang helped a lot because the error messages are
> so much better), still.
>
> But needing help and needing literally all the things handed to you on a
> silver platter are not the same.
yes, this

> I actually think we should be spending more time than we are on engaging
> with new contributors (and it's something I plan on doing now that Australis
> is finally being released). However, I also think we should be careful about
> where and how we spend our efforts.
>
> The time all of us, collectively, can spend on helping new contributors up
> to speed is a limited resource. It would be nice if we could optimize its
> usage better than we currently do.
>
> Perhaps I (and one or two other people who mentored similar contributors and
> with whom I've discussed this when these particular contributors were
> active) were the only people affected, and the issue I'm bringing up is such
> a minority case we don't need to worry about it. I hope so! But if not, we
> should figure out how/where to draw a line.
I've certainly seen this type of person too.

> It's never felt right to me to say "no" to someone who wants to own a bug,
> but if previous evidence strongly suggests they don't stand a chance of
> fixing them and will "occupy" the mentored bug when we only have a limited
> number of them (seriously,
> http://www.joshmatthews.net/bugsahoy/?ff=1&unowned=1 has very few bugs that
> have never been (unsuccessfully) owned, so bugs with the right difficulty
> level for first contributors are clearly hard to come by**), then I would
> love to have a better way to respond than letting the inevitable happen when
> I do assign them the bug.

yes please.  Also if we do better at sending contributors who have no
hope of fixing the bug someplace else I hope we'll spend more time
helping people who are or at least will be useful in the future, and be
less frustrated while we do it.

Trev

>
> ~ Gijs
>
> ** which probably means we should also think harder on the fx desktop team
> about which bugs could be such bugs, and how to make more of them! Many of
> those bugs are devtools bugs, and there doesn't appear to be a way to filter
> those as compared to the rest of Fx desktop; Without data, I do believe the
> devtools team has been doing a better job in terms of mentored bugs than we
> have.
>
> On 15/04/2014 23:36, Mike Connor wrote:
> >To add to this: a great many of us "didn't get it" early on.  Mozilla code
> >is hard and daunting at first, and there are many ways to get lost.  If I
> >didn't have bz/dwitte/timeless patiently answering questions, I'd have
> >bounced in 2003 without ever getting a build working, let alone
> >accomplishing anything I've done in the ensuing decade.  Without outing
> >people on this list, there are many established Firefox hackers who needed
> >a lot of support in the early days.  If we aren't providing that support
> >and guidance, we'll miss out.
> >
> >Is it fun? Not always. Do we all have other things we could be doing?
> >Sure.  Is it an essential part of how we bring people in (and how we learn
> >to be better ourselves)? Absolutely.
> >
> >-- Mike
> >
> >-----Original Message-----
> >From: dev-planning
> >[mailto:dev-planning-bounces+mconnor=[hidden email]] On
> >Behalf Of Ehsan Akhgari
> >Sent: April 15, 2014 6:17 PM
> >To: Gijs Kruitbosch; [hidden email]
> >Subject: Re: Contributor pathways, engagement points and bug mentoring
> >
> >[Mike Connor] <snip>
> >
> >Speaking from my personal experience when I first started to contribute to
> >Mozilla, it took me a *month* to be able to build the code base locally.
> >During that time a couple of individuals continued to try their best to
> >help me along the way.  And without that, I would have never stuck around
> >the project.
> >
> >The goal of attracting new contributors is not to help our engineers get
> >stuff done faster.  It is to attract new talent to the project who can
> >help drive it forward in ways that no single contributor can.  It's OK if
> >someone doesn't have time to help with that (I rarely have enough time for
> >that these days myself) but let's not forget the bigger picture here.
> >
> >Cheers,
> >Ehsan
> >
> >_______________________________________________
> >dev-planning mailing list
> >[hidden email]
> >https://lists.mozilla.org/listinfo/dev-planning
> >
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Ehsan Akhgari
It seems we're mostly in violent agreement!

On 2014-04-15, 7:08 PM, Trevor Saunders wrote:

> On Tue, Apr 15, 2014 at 11:58:32PM +0100, Gijs Kruitbosch wrote:
>> It seems my message wasn't clear, although I sort of saw this response
>> coming and tried to pre-empt it - evidently I failed.
>>
>> I'm not complaining about people generally needing, and asking for, help.
>>
>> 9-odd years ago, when I started to contribute as a volunteer, I also needed
>> a lot of help. Heck, to "out" myself here: I needed help understanding some
>> of the programming language at issue (nobody had ever told me
>> String.replace() could take a function as the second argument! (and JS was
>> different from VBScript (yes...) in surprising ways)). If/when I fix the
>> occasional C++/objc bug, I need help with some of our internals (and
>> sometimes the language - clang helped a lot because the error messages are
>> so much better), still.
>>
>> But needing help and needing literally all the things handed to you on a
>> silver platter are not the same.
>
> yes, this
>
>> I actually think we should be spending more time than we are on engaging
>> with new contributors (and it's something I plan on doing now that Australis
>> is finally being released). However, I also think we should be careful about
>> where and how we spend our efforts.
>>
>> The time all of us, collectively, can spend on helping new contributors up
>> to speed is a limited resource. It would be nice if we could optimize its
>> usage better than we currently do.
>>
>> Perhaps I (and one or two other people who mentored similar contributors and
>> with whom I've discussed this when these particular contributors were
>> active) were the only people affected, and the issue I'm bringing up is such
>> a minority case we don't need to worry about it. I hope so! But if not, we
>> should figure out how/where to draw a line.
>
> I've certainly seen this type of person too.
>
>> It's never felt right to me to say "no" to someone who wants to own a bug,
>> but if previous evidence strongly suggests they don't stand a chance of
>> fixing them and will "occupy" the mentored bug when we only have a limited
>> number of them (seriously,
>> http://www.joshmatthews.net/bugsahoy/?ff=1&unowned=1 has very few bugs that
>> have never been (unsuccessfully) owned, so bugs with the right difficulty
>> level for first contributors are clearly hard to come by**), then I would
>> love to have a better way to respond than letting the inevitable happen when
>> I do assign them the bug.
>
> yes please.  Also if we do better at sending contributors who have no
> hope of fixing the bug someplace else I hope we'll spend more time
> helping people who are or at least will be useful in the future, and be
> less frustrated while we do it.

Yeah agreed.  I think it's totally OK to suggest different things for
those types of contributors to spend their time on if you believe their
contribution won't get anywhere based on past experience.  We have quite
a bit of non-technical ways of contributing!
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

mhoye
In reply to this post by Gavin Sharp-3
On 2014-04-15, 6:59 PM, Gavin Sharp wrote:

>
> My point (and I think Gijs' as well)  is just that not all people who
> express a desire to contribute can be successful in doing so, for
> various reasons, and "respond more to people's comments" on its own is
> unlikely to be a cost-effective or scalable solution. We need to have
> systematic solutions for avoiding expending large amounts of effort
> for minimal return, and efficient ways to direct potential
> contributors to the right opportunities.
>
> I know mhoye has given those problems lots of thought, so this isn't
> news to him, but it felt worth clarifying in the context of this
> thread.
There's a lot to unpack here.

There's no question that there will be some people who will not be
effective contributors after any amount of effort by any number of
established Mozillians. It's unfortunate, but those people exist and
nobody who takes on a mentoring role should feel bad or hesitate for a
second to say somebody isn't ready, or needs to show some work or
acquire some more basic skills before they can proceed. Mentoring isn't
doing the work for someone, and if that's what it's turning into,
absolutely try to direct that contributor to somewhere they might be
more successful. We have some great introductory and non-code
contribution channels now - #introduction, SuMo, QA, Localization, the
Reps, a bunch of others; the systematic solution I'm hoping we can adopt
in the near term is "know the other engagement pathways and send people
to them as soon as it occurs to you that you should."

Nevertheless, I don't think that the possibility that somebody _might_
be a time-sink means we can leave them hanging,

I'm making a very narrow claim, here. All the data I've got says that
these are not people who are expressing a desire to contribute and then
failing to deliver; these are people who are expressing a desire to
contribute and then inadvertently being ignored. I know the solution
I've proposed isn't all that pretty, but I'm looking at a set of
mismatched expectations between how people interact with a service we
own and control outright and how people interact with other people in
about three-fifths of the entire world. In that context an inelegant
solution we can push to production over the weekend looks like a pretty
sweet deal.

I agree that responding to more people's comments on its own isn't
cost-effective or scaleable, but getting new contributors to the point
where they can mentor the next generation of contributors themselves,
that scales like crazy. In fact, until late in the industrial
revolution, that was _the only thing that had ever_ scaled. And I don't
see a way to get from here to a million Mozillians that doesn't involve
both talking to lots of new people and leveling up the people we have.

If we get to the point that just talking to the number of new
contributors who want to fix bugs becomes an unsupportable burden for
Mozilla's engineers we will absolutely have to figure out how to address
that, but from up here in the cheap seats I bet that looks an awful lot
like winning.


- mhoye
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Contributor pathways, engagement points and bug mentoring

Ehsan Akhgari
On Tue, Apr 15, 2014 at 10:18 PM, Mike Hoye <[hidden email]> wrote:

> I'm making a very narrow claim, here. All the data I've got says that
> these are not people who are expressing a desire to contribute and then
> failing to deliver; these are people who are expressing a desire to
> contribute and then inadvertently being ignored. I know the solution I've
> proposed isn't all that pretty, but I'm looking at a set of mismatched
> expectations between how people interact with a service we own and control
> outright and how people interact with other people in about three-fifths of
> the entire world. In that context an inelegant solution we can push to
> production over the weekend looks like a pretty sweet deal.
>
> I agree that responding to more people's comments on its own isn't
> cost-effective or scaleable, but getting new contributors to the point
> where they can mentor the next generation of contributors themselves, that
> scales like crazy. In fact, until late in the industrial revolution, that
> was _the only thing that had ever_ scaled. And I don't see a way to get
> from here to a million Mozillians that doesn't involve both talking to lots
> of new people and leveling up the people we have.
>

To get back to the original purpose of this thread, I actually question
Gavin's assertion about the cost effectiveness and scalability of answering
"yes please, you can work on this bug".  As someone who has worked in two
very different cultures, I think it's very easy to dismiss these types of
asks before working on a bug as an indicator that the requestor is not
serious etc but that is far from the truth, they are just trying to be
polite within the cultural norms that they are used to.


> If we get to the point that just talking to the number of new contributors
> who want to fix bugs becomes an unsupportable burden for Mozilla's
> engineers we will absolutely have to figure out how to address that, but
> from up here in the cheap seats I bet that looks an awful lot like winning.
>

 That is a great problem to have, and we are *far* from it.

--
Ehsan
<http://ehsanakhgari.org/>
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123