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

[Sumana Harihareswara]

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!

"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?

"Mentored Pairs, where one collaborator is a mentor and the other is
being mentored" I might use "teacher" and "learner".

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.

"Here are some common goals people might have." I like it! It helps
people see what's possible! Yay discoverability.

"Please briefly talk about your past experiences with open source."  A
suggested wordcount will probably help people (e.g.
http://hackerschool.com/apply has one I think) do this "briefly" without
worrying as much.

I like how you did the demographic questions.

best,
Sumana



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
>