On Tue, Feb 23, 2010 at 05:47:38PM -0600, Patrick W. Barnes wrote: Although I'm in violent agreement with Patrick here, there is one part where I want to offer some additional thinking. > * Engaging students for long-term participation in FOSS > I would much rather introduce someone new to FOSS and endear our ways to them > than pad the wallet of an experienced contributor. That is the purpose of the > GSoC, and of my participation. If anyone gets a job or finds a way to profit > from their participation, that is awesome, but it is not the driving goal. I agree that getting students participating in FOSS and learning how to work in large codebases with a larger team was the specific Google goal from the start, and it remains an important part. There has been some evolution, though, on the part of Google and of participating organizations. Google never forbade students already working within a project from participating in GSoC with that project, so although not encouraged it is allowed. Over the last few years, I feel there has been a shift where it is recognized that it is useful and possibly important to have some portion of the students be existing in the community. To some degree, it is now encouraged. For example, I've been hearing from other mentors e.g. at the Mentor Summit that there are several reasons for working with existing community members who are students. I heard back from Toshio and Yaakov this last time, and it sounded as if the same sentiments were held by the umbrella communities they spoke with. * Students who are in the community but on the periphery and who haven't found a way to make a solid contribution are using GSoC as their bridge. The standard way of contributing by figuring things out for one's self is an actual barrier for many people, who spend some time at the fringes or go away and never return. GSoC gives these folks a visible pathway to follow to participate in the project, where the project's pathways hadn't been working (or found.) * Projects from people who are already familiar with the community are more successful, having greater impact for the wider project. This is partially because these students know from the inside what the mentoring project needs. For Fedora in particular, where there is an ongoing need for contributor-focused applications, it's very hard for an outside person to figure out and navigate these needs. * Students who are already experienced in the community or were previously in GSoC are helpful to other students, both in attracting them to make proposals, and in working with them afterward. They are useful ambassadors to find, engage with totally new students, and bring them to both GSoC and the project overall. Students use their peer community to navigate the projects, and when all students are new to the project, that peer community is less able to help itself. Some topics will only be discussed amongst peers, such as how the project is treating the students. A lesser peer community means there is some content that never gets addressed. For some students, this could be the simple difference between success and failure. There are always people at different levels in a community. Having a group that is all new and no experience striations is not typical of the real world outside of academia, and I think frankly hasn't worked out as well in GSoC because of that. It was a flaw in the original design - a student group can't all be 100% new, even if you have 3 mentors to assigned to each student. In other words, the "pure student vessel waiting to be filled with our good community knowledge" is nice in the individual, but not as great in the aggregate. I think the GSoC model was made to break up the aggregate to gain access to that individual -- it's part of why students are not allowed to work with other students on projects. We should take care not to recreate the aggregate by insisting that the student population fit a newbie-only model. My take away from this is that we need to: 1. Do more to reach out to existing community members who are students and let them know they can participate in GSoC; encouage them to use it as a chance to resolve a big problem or implement a new feature for the project. 2. Make sure that we maintain a strong balance of totally new students; maybe 70% is a good target not to fall under? 3. Don't make hard and fast rules around this; we need to give mentors and admins the flexibility to get students who are going to do stuff with the time mentors give them. (Gaining participation experience is a top priority, but as a project we cannot have that be the sole outcome of all of our efforts. I can take the same time I put in to one student and split it amongst 25 random people and get a lot more new participants in FOSS.) 4. Don't play up the money aspect for any students; that's not the goal of the effort, it's just a means to the goal. If a student is focused on the money, they are probably the wrong student for working in a community FOSS project. How does that sound? - Karsten -- name: Karsten 'quaid' Wade, Sr. Community Gardener team: Red Hat Community Architecture uri: http://TheOpenSourceWay.org/wiki gpg: AD0E0C41 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.fedoraproject.org/pipermail/summer-coding/attachments/20100302/b81f26a0/attachment.bin
