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

[Shauna Gordon-McKeon]

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> 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]
> *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>
> 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>
> > 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
> >>> http://lists.openhatch.org/mailman/listinfo/osctc-planning
> >>>
> >>>
> >>
> >
> >
> >
> > _______________________________________________
> > OSCTC-planning mailing list
> > OSCTC-planning at lists.openhatch.org
> > http://lists.openhatch.org/mailman/listinfo/osctc-planning
> >
>
> _______________________________________________
> OSCTC-planning mailing list
> OSCTC-planning at lists.openhatch.org
> http://lists.openhatch.org/mailman/listinfo/osctc-planning
>
>
>
> _______________________________________________
> OSCTC-planning mailing list
> 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/20141215/996edcac/attachment-0001.html>