From Fedora Project Wiki

(Import first draft)
Line 29: Line 29:
We have not had more than one student dropout or failure in any of the years we participated in the GSoC program.
We have not had more than one student dropout or failure in any of the years we participated in the GSoC program.
2005: 8/8
* 2005: 8/8
2006: 5/5
* 2006: 5/5
2007: 5/5
* 2007: 5/5
2008: 9/10
* 2008: 9/10
2009: 8/9
* 2009: 8/9
=== Add a Comment (optional) ===
=== Add a Comment (optional) ===

Revision as of 14:53, 11 March 2010


Organization Name

The Fedora Project & (Red Hat)


The Fedora Project is an open community effort to rapidly advance free and open source software and content; one of its outputs is a Linux distribution showcasing the latest and best in free and open source software. is a community endeavour to produce an open source Java-based middleware stack.

Home page

Main Organization License

GNU General Public License (GPL)

Why is your organization applying to participate in GSoC 2010? What do you hope to gain by participating?

Our participation in all of the past GSoC programs has helped us to bring in new Free and Open Source Software contributors and has led to the creation or growth of several valuable projects. We hope to continue and expand upon that tradition again this year.

Did your organization participate in past GSoCs? If so, please summarize your involvement and the successes and challenges of your participation.

We have participated in every GSoC since the beginning and have maintained a steady growth level since then. Most student projects end successfully, although we've had some difficulties with getting the work integrated and maintained beyond the summer. In the past few years, we've had some challenge working as a joint mentoring organization since and Fedora are very different communities, but this year we have been working on solving those problems and gaining strength from the relationship.

If your organization participated in past GSoCs, please let us know the ratio of students passing to students allocated, e.g. 2006: 3/6 for 3 out of 6 students passed in 2006.

We have not had more than one student dropout or failure in any of the years we participated in the GSoC program.

  • 2005: 8/8
  • 2006: 5/5
  • 2007: 5/5
  • 2008: 9/10
  • 2009: 8/9

Add a Comment (optional)

If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)?

not applicable

What is the URL for your ideas page?

What is the main development mailing list for your organization? This question will be shown to students who would like to get more information about applying to your organization for GSoC 2010. If your organization uses more than one list, please make sure to include a description of the list so students know which to use. is the main Fedora Project development list. has the best ways to communicate with the myriad upstreams within the community

What is the main IRC channel for your organization?

  1. fedora-devel or #fedora-gsoc on

Add a Comment (optional) doesn't have an aggregate channel in the same way Fedora does; the joint GSoC channel #fedora-gsoc is a substitute there.

What criteria did you use to select the individuals who will act as mentors for your organization? Please be as specific as possible.

Historically, we have two levels of mentors, with different requirements. We invite any project members to be part of the mentoring oversight group, whose main role is to help with the student proposal vetting. From within that group, individuals stand-up to volunteer to work with each student. This year we are adding some additional requirements. We are requiring mentors to provide early and clear commitment, including pledging to kick any relevant upstreams or sub-projects in to action for the student. We are requiring sub-projects that provide a mentor and have a student working with them to also make a commitment as a group in advance. Our goal is to improve communications, including our ability to help students learn _how_ to communicate in FLOSS projects.

What is your plan for dealing with disappearing students?

We are taking several approaches. Students are going to be required to blog their work, with mentors being responsible for making sure that relevant sub-projects are included in the communication. This is crucial because sometimes students are working on an upstream, so are very busy but not visibly to our mentoring organization or relevant sub-project.

The mentor focus is on the first half of the summer program to work on communication with the student. For any students who don't take smoothly to the communication regime, the mentor needs to work with them one-on-one to solve whatever problems are interfering with proper communication.

If it is clear by the midterm review session that a student is disappeared or too absent and uncommunicative, the student will receive a negative review and leave the GSoC mid-year. If that happens, a team of admins and mentors will collaborate on how to handle the student. Our goal is to help the student salvage value from the experience, even if they could not complete.

What is your plan for dealing with disappearing mentors?

We pair students with a backup mentor in addition to their primary mentor. Should a mentor need to bow out, the backup mentor can work with the student until we can increase the mentor count to two people. In addition, if the student's project involves working with an active sub-project, the goal is to have that sub-project help smooth any bumps that might happen with the mentor.

What steps will you take to encourage students to interact with your project's community before, during and after the program?

This year we are making our plans and requirements a bit more stringent. For example, students were encouraged to blog in the past; this year it is a requirement. One way we'll encourage this is to create a blog planet that is a feed of just the students - one stop shop for a full view on the student work. We'll also put the student blogs on the regular project blog planet.

From the first day, we are encouraging students to talk with potential mentors and sub-projects immediately. That is clear in our messaging to students, and at each turn we'll be pointing students at where and how to have the public discourse.

This year we created an IRC channel (irc:// just for students and mentors (and interested parties), so the students have a room of their own (with the mentors) for bonding, networking, problem solving, joint learning, etc. We are using this semi-private space as a way for group mentoring (students, mentors, interested parties) to work out how to approach more public IRC, mailing list, and blog work. For example, some students progress better when they feel officially sanctioned; the IRC channel helps provide that feeling while helping the student learn how much can be done without asking permission.

At the end of the summer, we are going to distribute communication responsibility where it has laid all summer -- in the sub-projects and associated mentor. These are the folks with the experience of the student and project to know how to continue interaction. Our projects are highly focused on contributors, so it is very easy to convert a temporary community member in to a more permanent one.

What will you do to ensure that your accepted students stick with the project after GSoC concludes?

With the caveat that we can't be sure yet what projects will require sticking-with or hand-off

Is there anything else you would like to tell the Google Summer of Code program administration team?

Add a Comment (optional)