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

Thu Dec 18 12:13:08 UTC 2014

Hi Folks,

I agree with Shauna that mentorship can be taught/learned. And that mentoring is one of the very valuable things that OpenHatch can foster.
Go for it!
Heidi

From: OSCTC-planning [mailto:osctc-planning-bounces at lists.openhatch.org] On Behalf Of Shauna Gordon-McKeon
Sent: Wednesday, December 17, 2014 6:10 PM
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

My plan is to set up the mentorship program - whatever form it takes! - next week so we can start it with the new year.  Just to give a time frame for anyone who is planning to give feedback on this email.  :)

On Mon, Dec 15, 2014 at 11:13 AM, Shauna Gordon-McKeon <shaunagm at gmail.com<mailto:shaunagm at gmail.com>> wrote:
I've been doing a bit more thinking on this, since there's a temporary lull in events.  Heidi writes: "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?"

I would say that "mentor" is a thing you do, not a thing you are.  It's easy for some people to call themselves mentors and very hard for others but teaching and helping are things we all do in our lives as are learning and being helped.  I think it's key to help newcomers recognize what they already know and value it.  It's synergistic, too, because if newcomers mostly know stuff that gets taught to newcomers, then they can turn around and teach that, freeing up people who know newcomer stuff and more advanced stuff to teach the more advanced stuff, including to the newcomer-who-is-teaching.

I have four ideas for pushing newcomers into mentorship roles, which I know they may not be comfortable with:
- Newcomers whose history with the program includes peer pairing and mentorship could be given priority when matching with others.
- Newcomers who have been mentored on a specific task could be asked to peer pair or mentor on that task.
- I'd like to offer imposter syndrome training as one of the topics people can work on together, which would hopefully address fears of trying to teach/mentor head on.
- We can emphasize the "peer pairing" option for folks who are unsure about saying they can mentor a topic, until they're ready.

I've recently gotten into Django and I think it would be fairly straightforward for me to build a Django app that takes care of at least some aspects of this.  (In an ideal world, a pairing-scheduler would be built into it, but I'm not sure how that would work. It may make sense to just trust people who've signed up to accurately record whether they've paired or not.)  If there's anyone who wants to pair with me on building it, just let me know!  ;)  (I am not 100% on Django here, and it may be harder than I'm imagining, but I'm leaning strongly towards it.)

A few more structural thoughts:

* As I've mentioned before, there are three ways to participate: as Mentor, As Pair, As Mentee.
* When you sign up, you'll be given a list of common topics. For each, you select whether you'd like to participate as Mentor, Pair, or Mentee for each of them.  All that apply, not exclusive. There will also be a "None" option.  There will also be a freeform field to add new topics and an "up for anything!" tag which means you get matched for any topic.

* Potential feature: an "active" or "inactive" tag.  You can tell the program how many hours a month you want to spend (4, for instance) and when you've participated in 4 hours you won't be actively matched with people for the rest of the month.  There would also be an overriding field where you could set your activity to on or off.  This would hopefully help people from feeling overburdened by requests.

* Via email (or on their profile page) people are given a list of up to 3 matches in each of the three pairing types: Mentor, Mentee, Peer.  he matches are determined by:
     1) activity (only people who are "active" considered)
     2) activity tag (tag matches will be considered before "I'll do anything" matches) and
     3) mentorship score.  Mentoring another person is worth 3 points, peer pairing is worth 2 points, and being mentored is worth 1 point.  These are summed and divided by total number of pairings.  This incentivizes folks to do more mentoring!

What do folks think of this structure?  If there are no major reservations, I'm going to go ahead and try to implement this this week.

On Sat, Oct 11, 2014 at 11:59 AM, Heidi Ellis <ellis at wne.edu<mailto:ellis at wne.edu>> wrote:
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<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

_______________________________________________
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/20141218/b930ff3f/attachment-0001.html>