This site is an archive; learn more about 8 years of OpenHatch.

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

Shauna Gordon-McKeon shaunagm at gmail.com
Wed Dec 17 23:10:06 UTC 2014 

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>
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> 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/20141217/d9372182/attachment-0001.html>

More information about the OSCTC-planning mailing list