[OSCTC-planning] mentorship and other ways to follow up with Open Source Comes to Campus attendees

Sat Oct 11 15:59:13 UTC 2014

Hi Folks,

I like this idea very much. And I think that the proposed structure (mentor/mentee queues, discrete tasks, etc.).   I really like the idea of pairing mentees as this will both help grow community and also provide mentees with a feeling that they’re not alone in asking questions.

My one thought is what is the path for mentees to become mentors. Do we have a way to grow mentors?  For mentees to mentor in the future? Not that this is a requirement, but that some mentees may want to mentor when they get up to speed.

Just my 2 cents.
Heidi

From: OSCTC-planning [mailto:osctc-planning-bounces at lists.openhatch.org] On Behalf Of Shauna Gordon-McKeon
Sent: Friday, October 10, 2014 11:57 AM
To: Planning for Open Source Comes to Campus
Subject: Re: [OSCTC-planning] mentorship and other ways to follow up with Open Source Comes to Campus attendees

On Fri, Oct 10, 2014 at 8:38 AM, Sumana Harihareswara <sumanah at panix.com<mailto:sumanah at panix.com>> wrote:
Sorry for the delayed response, and for a fairly critical tone I'm about
to take. I want Pairs to be as appealing as possible!

Thanks for the feedback!  If I don't respond inline, it's because my response was "oh of course Sumana is right, I'll change that".

"Pairs is a new mentoring program run by OpenHatch." -- could we use a
word less overloaded than "program", that does not imply that it's
primarily software?

Good point.  What about "a new mentoring community"?

Can you talk a little about "For any of the above options you did not
check, please explain why you are not interested in them."? This feels a
little interrogate-y -- maybe this is a question we should ask only
person-to-person, once we have been able to start building a
relationship with the participant.

In order to not overload the experienced mentors and to be able to grow the community, I want to prioritize including newcomers who are comfortable with the idea of learning through pairing with a peer and/or being a mentor themselves relatively soon.  Some might not click "I want to be a mentor" because they feel like they don't have enough to offer, while others might not like mentoring.  The former I'm very happy to work with and help them get to the point where they feel confident teaching others.  The latter I think are just not a good fit for Pairs.

On 10/01/2014 04:44 PM, Shauna Gordon-McKeon wrote:
> Pushing this forward: I think I'd like to do a small pilot program with the
> "short pairing meetings" model.  I've drawn up an application form here and
> would appreciate feedback:
>
> https://docs.google.com/forms/d/1qLNLnWW_TshbJYD8idWA4qxmuHr8WY9-EJukHgF5LCg/viewform
>
> On Mon, Aug 11, 2014 at 1:45 PM, Shauna Gordon-McKeon <shaunagm at gmail.com<mailto:shaunagm at gmail.com>>
> wrote:
>
>>
>>>>
>>> My brief experience with online mentorship efforts suggests they benefit
>>> from as many of the following as are possible:
>>>
>>> * The mentee has specific work that a mentor should provide comment on.
>>> (For pairing, the mentor can provide this, or the mentee can.)
>>>
>>
>> I think the proposed structure, where mentees pick a specific task/goal,
>> should address this.  Note that this requires mentees to have a sense of
>> what kind of tasks are possible, but I plan to have a set of tasks to
>> choose from (finding a project, reproducing a bug, learning about the OPW
>> or GSoC application process, etc) with the option to define your own task.
>>
>>
>>> * The mentor and mentee form a bond and get to know each other. (This is
>>> possible on a big mailing list and also possible through off-list
>>> communication.) (I think pairing is great for this.)
>>>
>>> Agreed.
>>
>>
>>
>>> * We should avoid standard failures on the mentors' sides, like having
>>> too many people who they kind of want to mentor but haven't picked any one
>>> person in particular and therefore become overwhelmed and stop finding our
>>> system a useful way to find mentees. This is basically a failure mode that
>>> the debian-mentors email list suffers from frequently.
>>>
>>
>> So my proposed structure has a mentor and mentee pairing for one session
>> at a time, with no commitment on either end to pair another session
>> (although that would certainly be possible).  This allows mentors to commit
>> time as they have it, and gives mentees the chance to meet multiple
>> potential mentors.  Of course, there are downsides to this model as well.
>>
>>
>>
>>>
>>> * We should avoid standard failures from the mentee sides, like having
>>> mentors that enthusiastically sign up but then fail to actually meet with
>>> the mentee. This is a failure mode that many one-on-one mentorship efforts
>>> suffer from.
>>>
>>
>> Ideally when they sign up to mentor someone they're committing to a
>> specific time and date.  Ideally there is also a way for us to keep track
>> of things like no-shows so we can ask the mentor to step back from the
>> program.  We'll want to make sure we have the ability to deal with CoC
>> violations, so we'll be doing the work there anyway.
>>
>>
>>
>>>
>>> A question is, how will we connect those who want mentorship with those
>>> who are plausible mentees? To avoid having too much demand on one side or
>>> the other, I'd recommend thinking of it as a queue and not as a mailing
>>> list, where you can periodically say things like "We're not taking new
>>> mentees right now" because there isn't the mentorship resource available.
>>> That way, people who participate don't have a bad experience.
>>>
>>>
>> I agree, although potentially there could be a waiting list.
>>
>>
>>
>>> That's my take!
>>>
>>> _______________________________________________
>>> OSCTC-planning mailing list
>>> OSCTC-planning at lists.openhatch.org<mailto:OSCTC-planning at lists.openhatch.org>
>>> http://lists.openhatch.org/mailman/listinfo/osctc-planning
>>>
>>>
>>
>
>
>
> _______________________________________________
> OSCTC-planning mailing list
> OSCTC-planning at lists.openhatch.org<mailto:OSCTC-planning at lists.openhatch.org>
> http://lists.openhatch.org/mailman/listinfo/osctc-planning
>

_______________________________________________
OSCTC-planning mailing list
OSCTC-planning at lists.openhatch.org<mailto:OSCTC-planning at lists.openhatch.org>
http://lists.openhatch.org/mailman/listinfo/osctc-planning

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20141011/10a20d94/attachment.html>