Thoughts and Goals

Karsten Wade kwade at redhat.com
Tue Mar 2 23:01:22 UTC 2010


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 


More information about the summer-coding mailing list