How to encourage students
From Google Summer of Code Mentor Wiki
Notes from Anthony Borrow, SJ (anthony@moodle.org) Actually I called this presentation Encouraging tomorrow's developers or developing developers. Below are my notes from that:
GSOC 2008 - Mentor Summit - Developing Developers
- Attracting
- motivations
- interest in particular issue/bug
- community-social exercise
- sense of accomplishment
- feelings of idealism/belief in FOSS
- fun - love of coding; working with good community, smart programmers; work on something that was not awful
- resume building/recognition
- ohloh
- work
- exposing the project in
- high schools
- GHOP
- smaller projects
- universities
- high schools
- motivations
- Screening
- Proposal
- student driven vs. problem driven (community vs. developers)
- challenge of finding qualified mentor for some projects
- Force students to use tracker, submit patch
- same requirements as expected of developers
- level of competence and confidence of mentor influenced privileges granted to student
- Proposal
- Maintaining
- Manage project
- blurb in open repositories, expose your code
- regular releases, encourage folks to release often
- willingness to make mistakes, teaching them to receive criticism/corrections
- mail patches/suggestions rather than modifying a student's code
- Keeping folks involved
- money?
- Relationship with others beside the mentor (broader is better)
- Work to ensure some type of feeling of success
- it may be better to start small
- escalating privileges as a way of demonstrating success
- formal expectations to help student progress
- building a micro-community of student developers
- worked well when students were geographically close to one another
- pair programming - help keep each other from getting stuck, they learn to talk through the code and explain things
- How to deal with feelings of frustration, hurt feelings, "failure", taking things personally?
- an ounce of prevention is worth a pound of cure
- try to re-focus to something positive
- if student does not want to be involved, they will not be involved - it cannot be forced and it may be better to simply move on by possibly modifying the project
- encourage them to get involved in other areas
- not everyone has to be a committing developer to be valuable to the community
- Manage project
There is apparently a mix of students taking listed projects and proposing their own.
There is a large discrepancy in the number of applicants.
A lot of students don't realize what skills they would need to be successful in a project.
It's not often clear for a mentor what skills students have.
Barrier to entry is different for different projects.
What are the "ramp points" for student entry into a project?
Project proposals: self-interest, community interest, project developer project. Emphasis on the student's interest could produce higher success rate, though proposals could be so specialized that there wouldn't be a mentor for it.
Interaction of students in communication forums of an org helps motivate students and crate a connection between the community and the student.
Students often don't even realize what OSS is about. They place much emphasis on monetary return since they might be able to discern the other qualities of the OSS. Projects must put more emphasis on the meaning of OSS and on those latter qualities that would keep people interested in contributing to OSS.
Find what motivates people. Find what motivates ourselves, so we could provide those entry points for the students.
Motivations: fun of it, looks good on the resume for later carreer development, desire to work on something that's "not awful" - creativity, social exercise - community, finding alike people, like minds.
Using mentors who are not a part of the core team works and might bring new people in from the student pool and from new mentors.
Make sure to have a RCS branch(es) available to student(s), so commits can be made and tracked.
How can the students be put into a "commit early and often" mode?
How can you encourage students to commit code often?
As a mentor what feedback should you give to the student early on to prevent any psychological blocks raising in their minds?
Get more people then just mentors to look at students' code.
If the code is very modular then giving trunk commit access could be very motivating.
Should changes be made to student's code or patches mailed to them or what?
How to prepare students for the gsoc - exercizes, etc.
Flexibility in the reporting and communication methods between students and mentors.
Is it important to model soc experience for students after your org's model or set up a different workflow?
Engage students for a smooth transition from their soc project to working on something they are interested in.
Make sure the students have a sense of involvement and completion.
Guidelines for submitting, sharing, reviewing code, bts tracker.
Peer programming could be a good option to introduce a new student to the process.
Quality code over quantity of code expectation is stimulating for students.
Pair programming helps keep students from getting stuck.
Self-filter - soc as a method of inviting new developers in.
Being "ridiculously positive" could be a double-edged sword in interacting with students.
Have a mentor to transition a student from soc to a direct committer.
Make sure to have an amicable open person who the students can talk to - a person that "nobody can make angry".
[edit] Feedback
I don't know if this is the right place for feedback. If there's a better place, please move it: It's the first year for Zikula being part of the GSoC and we didn't really know what'd expect us. We learned something in the process and a lot at the Mentor Summit. It's great that you guys only give a frame for the projects and don't demand specific forms of communication or such thing: just the evaluations. That gives everybody the space to work the way you work best. But there's a lot of experience in the community from people who took part for several year with a lot of projects and students. As we are all strewn across the globe it's not possible to arrange a kick-off meeting with everyone who's applying for mentoring. But maybe you could invite over 2 or 3 people from bigger projects with experience (KDE or the like) and have a talk with them that is being videoed and uploaded at video.google.com for everyone to see, who's interested in GSoC. --Steffen, Steering Committee of Zikula Foundation
