Communication Problems
Flowed into DevEnvironments
Meeting Notes
Mentors not responding to emails
How do we assert more power/control over the mentors and students?
Student would communicate "just enough". Pulling teeth. Four or five emails to get one response.
Time zone issues:
- - hard to be online at the same time for irc/im
Only have leverage over students. We're not going to pay you.
Email doesn't work for all students. i.e. one would only communicate over irc. compromise im.
blog entries:
- - worked for some projects - not for others
how do you make things requirements?
should you declare things up front:
- - i.e. you will be expected to do .... i.e. weekly report to mailing list, blog post, attend irc meeting, communicate on public mailing list, send patches to list, - seemed to help to predeclare - set up expectations on "ideas"/org info pages.
common problem:
- too much happening between student and mentor, not enough with community. one ex: 90% 1:1, 10% community.
weekly reports considered good.
students less likely to admit failure in public. people terrified of community.
need to foster relationship. expectations: first get comfortable with mentor, then get them comfortable with the community. open source is an agressive culture. (no women.) need to "ease the entrance" to get the first patch out. build tiered system?
communication with community can have high S/N ratio, which can sometimes get in the way of work.
hard to get people to send to mailing lists.
mentor-only mailing list good to have.
many orgs had experience where mentors would good silent where you had to assume things were going ok. (from what the student said.)
should setup mentor communication expectations too.
roadblocks that students have, are likely problems that other community members have.
some projects had a "backup mentor" (python, freebsd). one project had 4:1. generally 2:1. (potential issues with this, too many cooks, different directions.) suggested to formalize this.
should there be a carrot (beyond t-shirts) for mentors? to make it more like "work" to keep it as a priority?
"mentors are event driven, but if the students stop doing work, no events"
split "mentor" and "tech lead/boss" position (like google) to ease "employee employer" relationship. so the "mentor" can be a "friend".
more people had passive students than highly motivated aggressive students. (and often this didn't match with the applications.)
some administrators were hands off. expected mentors to do whatever they wanted. would step in when there was problems. so admin only knew what was going on for problems, but overall didn't really have big picture.
microcommunities?
meeting was: ~50% admin/50% mentor
a lot of people don't realize that they didn't have to use a gmail address to read things.
communication problems with google:
- - dates badly defined - not enough confirmation emails - mentors didn't know when they were allowed to talk initially to students - slipping dates meant some students couldn't do it, because they took another job
- - suggestion: ramp up working slowly before school year ends
Summarys:
- - weekly probably right time for short updates
- - set communication expectations before the students are picked (i.e. so they know when they're submitting the project) how they'll have to communicate. "more structure needs to be in place for communication before things start" (doesn't have to be mentor driven - probably shouldn't be.)
- mentor<->student communication tended to be ok
- mentor<->admin communication was a common problem
- - new projects didn't know how GSoc worked, didn't know general expectations
- - setup students-only mailing lists
- - how do you make mentors do things? (no good answer. reputation? hold money for orgs?)
- - should get more "public scrutiny" on mentors, which should trickle down.
- - "fear" is problem.
Flowed into DevEnvironments