GSoC 2010 plan

From FedoraProject

Jump to: navigation, search

This document is the plan for project administrators and mentors to understand how the GSoC 2010 is working in the Fedora Project and JBoss.org.

Contents


Publicity plan

Being intentional about generating and directing interest between Fedora and JBoss.org sub-projects, contributors, and the Google Summer of Code project.

There are different audiences we need to speak with: students; mentors; sub-projects; upstreams; SoC program administrators.

Each audience needs to understand slightly different parts of the Fedora/JBoss.org GSoC effort. This publicity plan outlines what each audience needs to read. The actual publicity is put on the page GSoC 2010.

Advertise pre-proposal Timeline.

Students

This section is about what we are telling students and how we are telling it.

What

How


Mentors

This section is about what we are telling mentors and how we are telling it.

Mentors are the people who interact directly with the students, making evaluatations, and being responsible for helping with communication between the student and other parts of the project.

What

How

Sub-projects

This section is about what we are telling sub-projects and how we are telling it.

Sub-projects are the parts of Fedora and JBoss.org such as: packaging, infrastructure, Hibernate.

What

How

Upstreams

This section is about what we are telling upstreams and how we are telling it.

Upstreams are any project where the code/content output is integrated in the Fedora Project or JBoss.org. Student projects may draw upon or contribute to your code, through Fedora or JBoss.org.

What

How

Campus Ambassadors

Campus Ambassadors should work to guide new interests through this process. They should work in both generating interest in Summer of Code within the Fedora Community and also generating interest in Fedora within Summer of Code contributors.

Campus Ambassadors should then guide new contributors in helping them get set up with mentors and helping submit their GSoC proposal.

What

How

Workflow plan

  1. Mentors with ideas/problems link to use cases from designated area of wiki.
  2. Mentors and sub-projects who want students from GSoC.
  3. Student may have pre-proposal discussion in #fedora-gsoc and/or redhat-summer googlegroup.
    • Goal is to send students to individual sub-projects or mentors immediately
  4. Student submits proposal via Google proposal application "Melange".
    • Refer to Google-hosted GSoC FAQ for more information.
  5. Mentors sign-up for redhat-summer group, redhat-summer-mentors group, and as mentors in Melange.
  6. Mentor contacts student to conduct coding test.
  7. Students take coding test; passing is a requirement to have proposal considered.
  8. Mentors review proposals.
  9. Students iterate on proposals based on mentor input.
  10. Mentors have discussions in private mentor list to reach consensus on order of proposals
    • Order of proposals matter. Google makes a cutoff on student slot count, which we don't know until the final moment; mentors need to agree the culling order.
    • If mentors cannot reach consensus, admins make the final decision.
  11. Final proposal list order is made by mentors.
  12. Students whose proposals are accepted begin working with mentors.
  13. (Extrapolate out standard GSoC workflow from here.)

Documentation needs


Infrastructure needs