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

[Shauna Gordon-McKeon]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openhatch.org/pipermail/osctc-planning/attachments/20141010/22d4fdc7/attachment-0001.html>