Summer Coding 2010 step-by-step for mentors

From FedoraProject

Jump to: navigation, search
  1. You either have one or more ideas, or you want to assist generally with mentoring students.
    1. If you are generally interested, join the discussion list, introduce yourself, and offer to mentor. You have to decide if you want to be a full-time mentor for a student, a back-up mentor role, or one of the part-time presiding mentors who read applications, guide students and other mentors, and so forth.
  2. If you have an idea, you need to make an idea page for it following the directions from How to create an idea page for Summer Coding.
    1. When thinking about your idea, consider how to get the student personally invested -- the more they can make the ideas their own, the more they tend to get and give to the project. Compare this with an approach of coding to a hard specification.
  3. Once an idea page is up, including being part of Summer Coding 2010 ideas and you joining the discussion list, there are several directions you can go.
    1. You can sit with the idea and respond to queries on list or in IRC.
    2. You can do some publicity about your idea - blog post, FWN post, email to various lists, talk to students, IRC, etc.
    3. You can go all the way and help organize publicity - via universities, posters, etc. Fedora Marketing may be interested in helping.
  4. When questions come up, try to direct the questioner, questions, and answers to the list, and answer them there. The idea is to be transparent and reduce duplicate work.
  5. Add to the Summer Coding FAQ as often as you need. Use it as a reference even more often.
  6. Work with students on their proposals. Use the How to comment on Summer Coding 2010 proposals procedure and invite other mentors (via the mentors private discussion list) to discuss the proposal on it's talk page.
    1. The goal is to help the student do the best proposal they can; this is an exploration and research phase; conduct a code test and see how the personality fit works. Be sure to offer code tests and get-to-know-the-community sessions equally and fairly to all who want to propose.
    2. If possible, the proposal that is turned in should not need any further work from that due date.
    3. It is possible that while mentors discuss proposals after 20 May, they may want to request changes or ask questions of the proposals. Use How to comment on Summer Coding 2010 proposals for directions on reviewing proposals..
  7. If you have questions about any of the step so far, bring the questions to the discussion list. If it is a private matter, reach out to any of the experienced mentors.
  8. When all proposals are turned in, the mentors private discussion list is populated with all the mentors who are proposed and not yet on that list, then discussions ensue.
    1. Mentors decide which proposals get funded.
    2. Admin team does tie-break where there is no consensus.
    3. Ideally, mentors argue successfully on the merits of the proposal; all sub-projects are treated as equal.
    4. However, some funds may be earmarked for specific groups.