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
|

Re: Contributor pathways, engagement points and bug mentoring

Gavin Sharp-3
On Mon, Apr 21, 2014 at 5:34 PM, Karl Dubost <[hidden email]> wrote:

>
> Le 22 avr. 2014 à 05:02, Gavin Sharp <[hidden email]> a écrit :
> > expecting a 100% "success" rate - but there's no getting around the fact
> that a 100% (or 90%) "failure" rate is going to have an impact on your
> future efforts.
>
> That would mean you have been able in advance to define what is "success"
> and what is "failure".
>

No, I think the point I'm making is independent of whatever definitions you
use for those words (as long as you recognize that both are possible
outcomes). I agree with you that "success" can mean many different things,
and we shouldn't define it too narrowly.

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

Ehsan Akhgari
In reply to this post by Gavin Sharp-3
On 2014-04-21, 4:02 PM, Gavin Sharp wrote:
> You can't see how mentors might be reluctant to invest time in helping
> contributors if a high percentage of the their past efforts have not been
> successful in any form? This seems fairly obvious to me. No one is
> expecting a 100% "success" rate - but there's no getting around the fact
> that a 100% (or 90%) "failure" rate is going to have an impact on your
> future efforts.

Yeah, I see this problem.  But can't we try to address this by educating
the mentors about this?

FWIW I'd be curious to see if we can gather data about the experiences
of the people who have mentored new contributors in the past.  That way
we can approach this problem with some concrete data.

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

Re: How to best engage with and invest time in new/beginning contributors

Ehsan Akhgari
In reply to this post by Mike Connor-4
On 2014-04-21, 6:42 PM, Michael Connor wrote:
>> 2) How can we reduce the number of false negatives? This is intended as a genuine question - I would love to be able to help in that department. Could we try to e.g. get team members to identify five mentored bugs a week or something? Send swag to people for fixing mentored bugs? Invite them for work weeks? Organize "fix mentored bugs" competitions/days? Make it easier for people to fix bugs by improving the "effort curve" for contributing? Something else? Do we (does Mike) have data on some of this?
>
> Having done this a lot, the following three things, in order, are pretty key to encouraging and including talented people:
>
> * Review turnaround.
>
> If we can tag individuals as “in mentoring” (basically “newbie who’s cleared the #introduction steps”) and then prioritize responses to bugs/patches for that group, we’re winning.  Think about how hard it is when reviews get delayed and you have to work on other things, and then come back and fix stuff.  Now imagine if the context you’re swapping in is “all of Mozilla tech” and you’ve got a day job or school.  Reviews and feedback requests from people in mentoring should trump everyone else short of a chemspill.

This.  I'd actually go as far as saying that as far as a potential
future contributor is concerned, the review turn-around time is a sign
of respect for their contribution from the project's part.

As a personal rule, if I think that I won't be able to handle my review
in a given day, I always prioritize review requests from people I don't
know.  Many of them turn out to be new contributors (whether paid or not.)

> I’d suggest “time from taking bug to bug landed and in Nightly” is the key pseudo-metric here.  Everyone wants that sense of accomplishment, and we should help them get it quickly.

Yes, delayed gratification rarely wins.

> * Integration into the group.
>
> Get them on IRC, get them interacting with the rest of the team so they feel like they’re part of the project, not outsiders.  Have conversations, even somewhat crunchy ones, somewhere they can be a part of it.

I'd like to add a related entry:

* Help them make progress.

Often after I help someone lands his first patch at Mozilla, I politely
indicate to them that I'd be available to help the take on a second bug
if they're interested.  If they say they are, I'll usually suggest some
other bugs to them to look at, and also try to make it clear that if
they have their own idea of what they would want to work on next that's
OK too.

> * Show them the love.
>
> Swag, work week invites, delivery of tasty things, summits and MozCamps.  These are all ways we should people they’re appreciated and important.
>
> These are all hard, and require effort and diligence to get right.

There's also some psychology involved, watch this video for example
<https://www.youtube.com/watch?v=u6XAPnuFjJc> which summarizes a lot of
good points about how to motivate people.

Cheers,
Ehsan


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

Re: How to best engage with and invest time in new/beginning contributors

mhoye
On 2014-04-21, 11:09 PM, Ehsan Akhgari wrote:

>
> This.  I'd actually go as far as saying that as far as a potential
> future contributor is concerned, the review turn-around time is a sign
> of respect for their contribution from the project's part.
>
> As a personal rule, if I think that I won't be able to handle my
> review in a given day, I always prioritize review requests from people
> I don't know.  Many of them turn out to be new contributors (whether
> paid or not.)
>

This is a measurably important thing; we learned last year at MSR2013
that speed of response time to a patch is strongly correlated to
retention. If we turn around a review in the first day, we're quite
likely to see a second patch from that contributor. If we wait a week,
that contributor is very likely to move on.


- 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

Mike Connor-4
In reply to this post by Gavin Sharp-3
On Apr 21, 2014, at 4:02 PM, Gavin Sharp <[hidden email]> wrote:

> You can't see how mentors might be reluctant to invest time in helping contributors if a high percentage of the their past efforts have not been successful in any form? This seems fairly obvious to me. No one is expecting a 100% "success" rate - but there's no getting around the fact that a 100% (or 90%) "failure" rate is going to have an impact on your future efforts.

If we're seeing a 100% failure rate (or even 90%), we should be doing some sort of group post-mortem to understand why it’s that bad.  That’s not a number I’ve heard previously.  If it’s just some people, that would suggest the mentors need help and coaching.  If it’s everyone, we’ve probably got deeper issues than how we identify and classify good bugs.

> I fully support encouraging people to invest more in mentoring, and it makes sense to bias our cost/benefit analysis to the longer term rather than focusing on short term returns. But you can't boil this down to just "pick one direction to fail in", because failing too much in the "false positive" case makes you fail more in the "false negative" case too.

It’d be absurd to take this to extremes, and that’s not my argument.  My point is that in deciding how far we turn the dial on “effort we expend to get a contributor up to speed” we’re either going to over-invest in people who aren’t worth it, or under-invest in people who are worth it.  Do we want more useful contributors, at the expense of more wasted time, or should we run leaner and only invest time in the obviously awesome people?  How do we measure and optimize our returns here?

— Mike
_______________________________________________
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 Ehsan Akhgari
On 2014-04-21, 10:55 PM, Ehsan Akhgari wrote:

> On 2014-04-21, 4:02 PM, Gavin Sharp wrote:
>> You can't see how mentors might be reluctant to invest time in helping
>> contributors if a high percentage of the their past efforts have not
>> been
>> successful in any form? This seems fairly obvious to me. No one is
>> expecting a 100% "success" rate - but there's no getting around the fact
>> that a 100% (or 90%) "failure" rate is going to have an impact on your
>> future efforts.
>
> Yeah, I see this problem.  But can't we try to address this by
> educating the mentors about this?
>
> FWIW I'd be curious to see if we can gather data about the experiences
> of the people who have mentored new contributors in the past.  That
> way we can approach this problem with some concrete data.

I interviewed a dozen or so engineers last year; not a huge sample, but
I for the few common points among them I think  reasonably representative.

The highlights - lowlights, really? - of that process were that everyone
agrees that helping new contributors grow is important and wants to do
more, but developers generally feel equally bad about three things:
     - cutting off aspiring contributors when it becomes clear they're
thrashing/out of their depth/getting nowhere etc.
     - having their mentoring relationship drag on unproductively at
painful length, and
     - not having a clear sense of where mentoring falls onto their list
of priorities and quarterly goals.

Everyone I spoke to made some variation of these three points as being
the most difficult things about mentoring contributors, so my hope for
addressing them is:

- To make it clear to new contributors, per-bug, what Mozilla's
expectations are as far as readiness and experience are, and what we
think will make for a successful contribution
- To set out some guidelines for mentors (check in every week, show some
prior work, etc...) about how to make that relationship work and how to
positively direct a contributor towards a better fit when it's not
working, and
- To advocate that engineers be given quarterly goals around engagement
and the time to pursue them successfully.

That last thing I'm beating the drums for is basically "one mentored bug
in-progress per product cycle per engineer",  which I think given some
better context - clear next steps for both parties, good alternative
plans and a clear sense that even with the best resources and intentions
sometimes it won't work and that's fine, it should be a better and more
productive experience for all concerned.


- 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

Boris Zbarsky
In reply to this post by Gavin Sharp-3
On 4/22/14, 10:59 AM, Michael Connor wrote:
> If we're seeing a 100% failure rate (or even 90%), we should be doing some sort of group post-mortem to understand why it’s that bad.

Anecdote, not data: a lot of people I've dealt with recently seem to be
showing up trying to contribute because they're university students with
a "contribute a patch to an open-source project" homework assignment.
This is becoming reasonably common in some countries (just like the
"report a bug in bugzilla" homework assignment that causes useless bug
reports).

This tends to not work all that great even for the first patch, and
tends to have near-0 post-first-patch retention....

-Boris
_______________________________________________
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 Hofmann-2
On 4/22/14 8:51 AM, Boris Zbarsky wrote:

> On 4/22/14, 10:59 AM, Michael Connor wrote:
>> If we're seeing a 100% failure rate (or even 90%), we should be doing
>> some sort of group post-mortem to understand why it’s that bad.
>
> Anecdote, not data: a lot of people I've dealt with recently seem to
> be showing up trying to contribute because they're university students
> with a "contribute a patch to an open-source project" homework
> assignment. This is becoming reasonably common in some countries (just
> like the "report a bug in bugzilla" homework assignment that causes
> useless bug reports).
>
> This tends to not work all that great even for the first patch, and
> tends to have near-0 post-first-patch retention....
>
> -Boris

It makes sense to have a different path and different set of success
metrics for these kind of contributors.

First thing might be to try and trace back to the institutions that are
encouraging/requiring this kind of work.  Having a list of contacts
there could help to improve the communication and make these limited
contributions more successful.

Building a set of Teaching Assistants within those organizations or
within Mozilla could keep the regular contributors/mentors building new
contributors that plan to stick around for more than just one "assignment."

Again, its my experience that the ratio's look something like this.

Talk to 1000 people.  Nine or Ten show some interest in contributing.  
One or two actually contribute something.  After awhile this feels like
100% failure rate, but those 1 or 2 are critical to building and
sustaining the project going forward.  The lessons here are about
setting the right expectations.  Mentoring and expanding the project
with more contributors is really hard work.  That doesn't mean we should
not do it.

-chofmann
_______________________________________________
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

Valentin Gosu
On 22 April 2014 19:15, Chris Hofmann <[hidden email]> wrote:

> On 4/22/14 8:51 AM, Boris Zbarsky wrote:
>
>> On 4/22/14, 10:59 AM, Michael Connor wrote:
>>
>>> If we're seeing a 100% failure rate (or even 90%), we should be doing
>>> some sort of group post-mortem to understand why it’s that bad.
>>>
>>
>> Anecdote, not data: a lot of people I've dealt with recently seem to be
>> showing up trying to contribute because they're university students with a
>> "contribute a patch to an open-source project" homework assignment. This is
>> becoming reasonably common in some countries (just like the "report a bug
>> in bugzilla" homework assignment that causes useless bug reports).
>>
>> This tends to not work all that great even for the first patch, and tends
>> to have near-0 post-first-patch retention....
>>
>> -Boris
>>
>
> It makes sense to have a different path and different set of success
> metrics for these kind of contributors.
>
> First thing might be to try and trace back to the institutions that are
> encouraging/requiring this kind of work.  Having a list of contacts there
> could help to improve the communication and make these limited
> contributions more successful.
>
> Building a set of Teaching Assistants within those organizations or within
> Mozilla could keep the regular contributors/mentors building new
> contributors that plan to stick around for more than just one "assignment."
>
> Again, its my experience that the ratio's look something like this.
>
> Talk to 1000 people.  Nine or Ten show some interest in contributing.
> One or two actually contribute something.  After awhile this feels like
> 100% failure rate, but those 1 or 2 are critical to building and sustaining
> the project going forward.  The lessons here are about setting the right
> expectations.  Mentoring and expanding the project with more contributors
> is really hard work.  That doesn't mean we should not do it.
>

As someone who suggested open-source contributions as bonus assignments to
students, I can confirm that doing so in bulk resulted in a very low
percentage of a second patch (less than 5%). However, with two of the ones
that contributed one initial patch, I was able to get in touch with, and
mentor for an entire summer. This resulted in several good and useful
patches, increased involvement, and one intern for the upcoming summer.

Some of the things I noted:
- contributor involvement is directly proportionate with the time you put
in mentoring
- reviews that take more than 3 days are a huge turn-off (especially for
new contributors, since they're doing one bug at a time)
- in-person meetings are really productive, and video meetings are better
that IRC
- new contributors aren't used to asking questions. Very often they get
stuck on something, and then they go away.
- challenging bugs are usually more engaging than simple bugs, if there is
good mentor to point them in the right direction.

While I agree that 1 or 2 people out of 10 who show an interest is fine, I
think we could do better. If we could set up a small group (reps maybe?)
tasked with reaching out to new contributors and helping them to get
started, I think our success rate would be much higher.
_______________________________________________
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 Hofmann-2
On 2014-04-22, 12:15 PM, Chris Hofmann wrote:

> On 4/22/14 8:51 AM, Boris Zbarsky wrote:
>>
>> Anecdote, not data: a lot of people I've dealt with recently seem to
>> be showing up trying to contribute because they're university
>> students with a "contribute a patch to an open-source project"
>> homework assignment. This is becoming reasonably common in some
>> countries (just like the "report a bug in bugzilla" homework
>> assignment that causes useless bug reports).
>>
>> This tends to not work all that great even for the first patch, and
>> tends to have near-0 post-first-patch retention....
>>
>> -Boris
>
> It makes sense to have a different path and different set of success
> metrics for these kind of contributors.

We're not really equipped to treat these contributors differently at
this point, and I don't think that it would be a positive step if we
were. There's not a lot we can do about ill-considered curriculum
decisions that want to use us as free instructional labor by the time
the curriculum's been decided. What we really need is a way to be in the
room when those decisions are getting made.

I think that we need to engage with the institutions pursuing these
initiatives, rather than the individuals doing the filing. Right now we
don't really have a setup that's compatible with student projects -
single-contributor focus and two- or six-week cycles vs. small teams and
term-based cycles - and making new Dave Humphreys doesn't seem to be in
the cards.

If a prof or institution is ready to collaborate with us, we should be
able - and in many cases already can - connect them with a reasonable
set of bugs, projects or goals, maybe even regionally relevant goals
with the Reps involvement. But I think that this is the responsibility
of the larger Engagement team, but that beyond having a short list of
nice-to-have speculative-but-not-priority features, I don't think core
engineering specifically needs to invest a lot of effort into to this.


- 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
In reply to this post by mhoye
On Tue, Apr 22, 2014 at 8:01 AM, Mike Hoye <[hidden email]> wrote:

> Everyone I spoke to made some variation of these three points as being the
> most difficult things about mentoring contributors, so my hope for
> addressing them is:
>
> - To make it clear to new contributors, per-bug, what Mozilla's expectations
> are as far as readiness and experience are, and what we think will make for
> a successful contribution
> - To set out some guidelines for mentors (check in every week, show some
> prior work, etc...) about how to make that relationship work and how to
> positively direct a contributor towards a better fit when it's not working,
> and
> - To advocate that engineers be given quarterly goals around engagement and
> the time to pursue them successfully.

This sounds great.

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

Brandon Benvie-2
In reply to this post by mhoye
Sounds like we need a Mozilla school. Then we'd be in the room when the decisions were made.

> On Apr 22, 2014, at 11:17 AM, Mike Hoye <[hidden email]> wrote:
>
>> On 2014-04-22, 12:15 PM, Chris Hofmann wrote:
>>> On 4/22/14 8:51 AM, Boris Zbarsky wrote:
>>>
>>> Anecdote, not data: a lot of people I've dealt with recently seem to be showing up trying to contribute because they're university students with a "contribute a patch to an open-source project" homework assignment. This is becoming reasonably common in some countries (just like the "report a bug in bugzilla" homework assignment that causes useless bug reports).
>>>
>>> This tends to not work all that great even for the first patch, and tends to have near-0 post-first-patch retention....
>>>
>>> -Boris
>>
>> It makes sense to have a different path and different set of success metrics for these kind of contributors.
>
> We're not really equipped to treat these contributors differently at this point, and I don't think that it would be a positive step if we were. There's not a lot we can do about ill-considered curriculum decisions that want to use us as free instructional labor by the time the curriculum's been decided. What we really need is a way to be in the room when those decisions are getting made.
>
> I think that we need to engage with the institutions pursuing these initiatives, rather than the individuals doing the filing. Right now we don't really have a setup that's compatible with student projects - single-contributor focus and two- or six-week cycles vs. small teams and term-based cycles - and making new Dave Humphreys doesn't seem to be in the cards.
>
> If a prof or institution is ready to collaborate with us, we should be able - and in many cases already can - connect them with a reasonable set of bugs, projects or goals, maybe even regionally relevant goals with the Reps involvement. But I think that this is the responsibility of the larger Engagement team, but that beyond having a short list of nice-to-have speculative-but-not-priority features, I don't think core engineering specifically needs to invest a lot of effort into to this.
>
>
> - 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

nhirata_bz
That sounds like a really cool notion.  Should we explore it?

On Apr 22, 2014, at 12:15 PM, Brandon Benvie <[hidden email]> wrote:

> Sounds like we need a Mozilla school. Then we'd be in the room when the decisions were made.
>
>> On Apr 22, 2014, at 11:17 AM, Mike Hoye <[hidden email]> wrote:
>>
>>> On 2014-04-22, 12:15 PM, Chris Hofmann wrote:
>>>> On 4/22/14 8:51 AM, Boris Zbarsky wrote:
>>>>
>>>> Anecdote, not data: a lot of people I've dealt with recently seem to be showing up trying to contribute because they're university students with a "contribute a patch to an open-source project" homework assignment. This is becoming reasonably common in some countries (just like the "report a bug in bugzilla" homework assignment that causes useless bug reports).
>>>>
>>>> This tends to not work all that great even for the first patch, and tends to have near-0 post-first-patch retention....
>>>>
>>>> -Boris
>>>
>>> It makes sense to have a different path and different set of success metrics for these kind of contributors.
>>
>> We're not really equipped to treat these contributors differently at this point, and I don't think that it would be a positive step if we were. There's not a lot we can do about ill-considered curriculum decisions that want to use us as free instructional labor by the time the curriculum's been decided. What we really need is a way to be in the room when those decisions are getting made.
>>
>> I think that we need to engage with the institutions pursuing these initiatives, rather than the individuals doing the filing. Right now we don't really have a setup that's compatible with student projects - single-contributor focus and two- or six-week cycles vs. small teams and term-based cycles - and making new Dave Humphreys doesn't seem to be in the cards.
>>
>> If a prof or institution is ready to collaborate with us, we should be able - and in many cases already can - connect them with a reasonable set of bugs, projects or goals, maybe even regionally relevant goals with the Reps involvement. But I think that this is the responsibility of the larger Engagement team, but that beyond having a short list of nice-to-have speculative-but-not-priority features, I don't think core engineering specifically needs to invest a lot of effort into to this.
>>
>>
>> - 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

_______________________________________________
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-22, 3:20 PM, Naoki Hirata wrote:
> That sounds like a really cool notion.  Should we explore it?
>

Right now - right this week, in fact! -  the engagement team is
developing a set of Mozcamp sessions to teach mentoring and
domain-specific advocacy and recruitment skills, with the goal of
levelling up contributors to mentors and evangelists.

We'll have more to report on that in a few days, so stay tuned!

- 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

Chris Hofmann-2
In reply to this post by Brandon Benvie-2

>> On Apr 22, 2014, at 11:17 AM, Mike Hoye <[hidden email]> wrote:
>>
>>> On 2014-04-22, 12:15 PM, Chris Hofmann wrote:
>>>> On 4/22/14 8:51 AM, Boris Zbarsky wrote:
>>>>
>>>> Anecdote, not data: a lot of people I've dealt with recently seem to be showing up trying to contribute because they're university students with a "contribute a patch to an open-source project" homework assignment. This is becoming reasonably common in some countries (just like the "report a bug in bugzilla" homework assignment that causes useless bug reports).
>>>>
>>>> This tends to not work all that great even for the first patch, and tends to have near-0 post-first-patch retention....
>>>>
>>>> -Boris
>>> It makes sense to have a different path and different set of success metrics for these kind of contributors.
>> We're not really equipped to treat these contributors differently at this point, and I don't think that it would be a positive step if we were.
If we don't figure out a plan for these kind of contributions we are
setting ourselves up for one class of mentoring failures.

Mentor spends lots of time and effort helping a student along, then
student disappears after one bug.  Mentor seeks ways to avoid that
including not doing the mentoring or fast reviews....

>>   There's not a lot we can do about ill-considered curriculum decisions that want to use us as free instructional labor by the time the curriculum's been decided.

Yep, your right.  That's one of the wonders of open source/free software
projects...

So we should look for easy ways to get in tune with what's going on.  
Seems like asking a few new contributors where they are coming from,
what's there motivation, and if student what
institution-class-instructor sent them our way up front, instead of
after is an easy way to get a ahead of this a bit.

>>   What we really need is a way to be in the room when those decisions are getting made.
or just try and circulate some information (wiki page) about how to make
these kinds of contributions and participation more successful.   Get
the instructors/professors to share their thoughts there...
>> I think that we need to engage with the institutions pursuing these initiatives, rather than the individuals doing the filing. Right now we don't really have a setup that's compatible with student projects - single-contributor focus and two- or six-week cycles vs. small teams and term-based cycles - and making new Dave Humphreys doesn't seem to be in the cards.

agree that that "high touch" kind of effort is not in the cards. I'm
suggesting "lower touch" ways of communicating and guiding these kinds
of efforts.
>> If a prof or institution is ready to collaborate with us, we should be able - and in many cases already can - connect them with a reasonable set of bugs, projects or goals, maybe even regionally relevant goals with the Reps involvement.
but that's not happening.  do reps really know what to tell the profs?
could they know and understand what to tell them?

-chofmann
>>   But I think that this is the responsibility of the larger Engagement team, but that beyond having a short list of nice-to-have speculative-but-not-priority features, I don't think core engineering specifically needs to invest a lot of effort into to this.
>>
>>
>> - 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
On 2014-04-22, 4:01 PM, Chris Hofmann wrote:

>
>>> On Apr 22, 2014, at 11:17 AM, Mike Hoye <[hidden email]> wrote:
>>> We're not really equipped to treat these contributors differently at
>>> this point, and I don't think that it would be a positive step if we
>>> were.
> If we don't figure out a plan for these kind of contributions we are
> setting ourselves up for one class of mentoring failures.
>
> Mentor spends lots of time and effort helping a student along, then
> student disappears after one bug.  Mentor seeks ways to avoid that
> including not doing the mentoring or fast reviews....
A contributor that completes one bug without coming back is not the best
possible outcome, but it is certainly not a failure.

But I stand by my claim: by the time we discern (if we manage to do that
at all) that this is a thing, it's too late to change the curriculum or
the assignments.

We can't make this engineering's problem; kids who've been set up to
fail by an instructor who didn't realize what they were asking for are
out of any scope we want to be a part of, and trying to address that
problem will be just  heartbreak like turtles, all the way down.

  The only current-term reaction that makes sense is what we're already
doing for individuals. The long game after that is for the engagement
team to reach out to the institution to try to help create an
achievable, relevant curriculum for the next wave of students.


- 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

Florian Quèze
In reply to this post by mhoye
On Sun, Mar 30, 2014 at 10:49 PM, Mike Hoye <[hidden email]> wrote:

> - The Mentoring doc spells out what makes a good first bug and a
> well-functioning mentoring relationship.

I wrote down my thoughts about mentoring Google Summer of Code students:
http://blog.queze.net/post/2014/04/22/Thoughts-about-mentoring-Summer-of-Code-students

I think GSoC is an excellent opportunity to get new long term
contributors, but it requires good mentoring.

One of the key difference between what's already been discussed here
and the GSoC situation is that you don't have to worry about whether
the student will submit a second patch after the first one is
finished; but you instead need to motivate the student to stay around
and continue to contribute after the final payment is received.

Florian

--
Florian Quèze
_______________________________________________
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-04-21, 8:04 PM, Chris Peterson wrote:

> On 4/21/14, 3:45 PM, Michael Connor wrote:
>>> >Can you give some bugs as examples? How recent was this? I didn't
>>> find anything with the bugsahoy whiteboard tags in bugzilla (for
>>> "mconnor") so I'm wondering if we're just seeing very different
>>> types of contributors now than we have in the past, and so perhaps
>>> it's an experiences rather than expectations issue. :-)
>> I’ve been inactive in mainline dev for a fair while.  (I keep filing
>> the points on my head away, but they grow back.)  Largely I’m
>> thinking 2005-2010 timeframe.  I’m also including things like
>> ‘interns’ in this count.  Not every intern is a rock star, even
>> perfect GPA kids from top schools.  It happens, and it’s hard to
>> accurately predict.
>
> Mike, do we have statistics on how contributors find us? For example,
> how many come through Bugs Ahoy, school projects, or fixing a bug that
> they reported?
Not yet. We've got a project underway called Baloo:

https://wiki.mozilla.org/Baloo

... with that as its goal, and we're connecting as many sites as we can
into Google Analytics, but we haven't tied the whole picture together yet.

I actually wrote "tied the whole picture together" there, like that's a
coherent sentence that will evoke a clear, comprehensible picture in
your imagination. Brain, what good are you, why are you even here.

Our data is incomplete but growing fast, and I'll have more to say about
that soon.


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

Re: How to best engage with and invest time in new/beginning contributors

mhoye
In reply to this post by Mike Connor-4
On 2014-04-21, 6:53 PM, Michael Connor wrote:
> On Apr 21, 2014, at 12:27 PM, Benjamin Kerensa <[hidden email]> wrote:
>
>> Is there any current policies in place in how you work with
>> contributors and at what point you stop investing time into a
>> contributor or group of contributors?
> I think this is a judgement call, for the most part.  It’s probably worth checking
I've written up some best-practices - some even data-driven! - here:

https://wiki.mozilla.org/Contribute/Coding/Mentoring#Good_Mentored_Bugs

But in short, contributors:
  - Must have their dev environment set up and building successfully
before they take on a mentored bug,
  - Might be asked to show some prior work or a tentative first run at a
patch before they can take the bug,
  - Should check in once a week, so everyone can see things are
progressing, and
  - Must respect their mentor's guidance with respect to patch
submission, review and direction towards a better-fitting opportunity if
progress stalls.

Mentors, in turn:
  - Should be judicious about who you agree to mentor,
  - Must get back to mentorees' inquiries within 24 hours, and
  - Should regularly evaluate if progress is being made, and redirect
the contributor to another opportunity if they've stalled out, and
  - Should promptly deassign the bug as soon as they feel the
contributor has lost interest/disappeared.

"Radio silent for two weeks" is a pretty reasonable threshold for
pulling the trigger on that last part, I think, but as always these are
guidelines, not policies. No rule will ever be more important than the
mentor's best judgement.

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