I am generally pleased with the progress that's been made on the ideas list. There might be some more things we can do, including possibly ordering the list with the "best" projects at the top.
By best I don't necessarily mean the ones that provide the most gain for NEdit, but instead those that are most likely to provide a good experience for both a student who takes them on as well as us in learning how to be a mentoring organization for GSoC. However, I'm still wrestling with whether to submit our application, for various reasons: * So far we have one volunteer for mentoring (Bert Wesarg), and one volunteer to serve as administrator (me). Somewhere (in the last document from which I've copied snippets), it suggests that a mentor should be prepared to spend 30 to 60 minutes per day dealing with his student, plus several extra hours a week. They also suggest that we should have a backup mentor, just in case (of whatever). * So far, the only backup mentoring plan I've come up with is to take that on myself, but I lack the real knowledge and expertise to do it, so would anticipate taking questions to the devel mailing list for discussion. (Discussion of some or all of the mentoring questions on a mailing list could be a good thing in any case, both to develop possibly better answers as well as to develop experience so that next year we might have more volunteer mentors.) * ATM, I'm spending more time than I can afford on this effort--hopefully sometime about 2 months from now I should be able to spend more time. I don't think we're in a position to handle more than one student at this point (especially not this year, and especially with only one volunteer mentor). On the other hand, accepting one student this year (and doing a good job for all concerned, that is, the student, Google, and NEdit) might put us in a better position next year to get and handle more students. However, if we don't think we can do a stellar job for all concerned, I think we would be better off to put our application off a year. If we do submit an application, I'll probably tell Google that we only want (can only handle) one student this year. Here are selected quotes from various GSoC related links that, I think, are appropriate to review before making a decision. (Actually, some of this became sort of a miscellany of things I thought we should try to remember or keep in mind, but I didn't capture everything of that nature.) * Snippets from the [[http://code.google.com/soc/2008/faqs.html][FAQ]]: ' 2. What are the goals of this program? Google Summer of Code has several goals: * Get more open source code created and released for the benefit of all; * Inspire young developers to begin participating in open source development; * Help open source projects identify and bring in new developers and committers; * Provide students in Computer Science and related fields the opportunity to do work related to their academic pursuits during the summer (think "flip bits, not burgers"); * Give students more exposure to real-world software development scenarios (e.g., distributed development, software licensing questions, mailing-list etiquette). ' ' 7. How does the program work? Here are the steps: 1. Open source projects who'd like to participate in Google Summer of Code in 2008 should choose an organization administrator(s) to represent them; 2. Organization administrators will submit the project's application for participation online; 3. Google will notify the organization administrators of acceptance, and an account for the organization will be created in the Google Summer of Code web app; 4. Students submit project proposals online to work with particular mentoring organizations; 5. Mentoring organizations rank student proposals and perform any other due diligence on their potential mentees; student proposals are matched with a mentor; 6. Google allocates a particular number of student slots to each organization; 7. Students are notified of acceptance; 8. Students begin learning more about their mentoring organization and its community before coding work starts; 9. Students begin coding work at the official start of the program, provided they've interacted well with their community up until the program start date; 10. Mentors and students provide mid-term progress evaluations; 11. Mentors provide a final evaluation of student progress at close of program; students submit a final review of their mentor and the program; 12. Student uploads completed code to code.google.com/hosting. ' ' 8. How do evaluations work? Google will pre-publish the evaluation questions for both students and mentors. Mentors will fill out mid-term and final evaluations for their students using the Google Summer of Code web app. These evaluations will be visible in the system to the mentor and the mentoring organization's administrator(s). Students will fill out a mid-term and final evaluation of their mentors online as well, and their evaluations will only be visible in the system to the mentoring organization's administrator(s). Program administrators from Google will have access to all evaluation data. In almost all cases, students will never see their mentor's evaluation of their progress, nor will a mentor see a student's evaluation of her/his mentorship. However, in the case where the mentoring organization's administrator and a student's mentor are one and the same, the student's evaluation will be shared with the mentor. Organization administrators are expected to review mid-term and final evaluations and to provide course corrections where necessary. In some cases, Google's program administrators may need to share the results of evaluations with the student and mentor, such as to arbitrate when payment should not be made; should this need arise, all parties will be notified in advance. ' ' 3. What is an "Ideas" list? An "Ideas" list should be a list of suggested student projects. This list is meant to introduce contributors to your project's needs and to provide inspiration to would-be student applicants. It is useful to classify each idea as specifically as possible, e.g. "must know Python" or "easier project; good for a student with more limited experience with C++." If your organization plans to provide an application template, it would be good to include it on your Ideas list. Keep in mind that your Ideas list should be a starting point for student applications; we've heard from past mentoring organization participants that some of their best student projects are those that greatly expanded on a proposed idea or were blue-sky proposals not mentioned on the Ideas list at all. ' ' 9. Can a student work on more than one project? No, each participant is only eligible for one stipend. 10. Can a group apply for and work on a single proposal? No, only an individual may work on a given project. Of course, students should feel free to collaborate with others to accomplish their project goals. 11. What happens if two students are accepted to work on the same project, e.g. from an organization's "Ideas" list? That's fine, a little duplication is par for the course in open source. ' ' 2. What is the role of a mentoring organization? Each mentoring organization is expected to provide: 1. A pool of project ideas for students to choose from, publicly published by the mentoring organization as an "Ideas" list; 2. An organization administrator to act as the project's main point of contact for Google; 3. A person or group responsible for review and ranking of student applications, both those proposals which tie into the organization's "Ideas" list and "blue-sky" proposals; 4. A person or group of people responsible for monitoring the progress of each accepted student and to mentor her/him as the project progresses; 5. A person or group responsible for taking over for a student's assigned mentor in the event they are unable to continue mentoring, e.g. take a vacation, have a family emergency; 6. A written evaluation of each student participant, including how s/he worked with the group, whether s/he should be invited back should we do another Google Summer of Code, etc. In addition to these responsibilities, a mentoring organization should actively encourage each student developer to participate in the project's community in whichever way makes the most sense for the project, be it development mailing lists, idling in the project's IRC channel, participating in the project's forum, etc. A truly successful mentoring organization will work diligently to ensure that as many of their students as possible remain active project participants long after the conclusion of the program. ' ' 4. Can a mentoring organization have more than one administrator? Yes, but it's not strictly necessary. It's good to have a backup administrator identified who can cover for your administrator should s/he go out of town, etc. If your backup administrator becomes the primary administrator, make sure to notify Google's program administrators. 5. What kind of mentoring organizations should apply? As you can see from the lists of our mentoring organizations for 2005, 2006 and 2007 many different types of open source projects participate in Google Summer of Code. As long as your project can provide mentors and is releasing code under an Open Source Initiative approved license, you are welcome and encouraged to apply. Unfortunately, there are far more great open source projects than we can work with, so if your project is highly niche or has very few users, chances are that your application will not be accepted. You may also find our [[http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-organization-selection-criteria] [Notes on Organization Selection Criteria]] helpful. ' Some schedule information (ignoring the applications and evaluation processes): ' April 14: * accepted student proposals announced at code.google.com/soc/ (~12 noon PDT/19:00 UTC). Community Bonding Period: students get to know mentors, read documentation, get up to speed to begin working on their projects. <rhk: probably while still attending classes and preparing for final exams> May 26: * Students begin coding for their GSoC projects; * Google begins issuing initial student payments provided tax forms are on file and students are in good standing with their communities. Interim Period: Mentors give students a helping hand and guidance on their projects. July 7: * Mentors and students can begin submitting mid-term evaluations (~12 noon PDT/19:00 UTC). July 14: * Mid-term evaluations deadline at 12 noon PDT/19:00 UTC; * Google begins issuing mid-term student payments provided passing student survey is on file. Interim Period: Mentors give students a helping hand and guidance on their projects. August 11: * Suggested 'pencils down' date. Take a week to scrub code, write tests, improve documentation, etc. August 18: * Firm 'pencils down' date. Mentors, students and organization administrators can being submitting final evaluations to Google (~12 noon PDT/19:00 UTC). September 1: * Final evaluation deadline 12 noon PDT/19:00 UTC; * Google begins issuing student and mentoring organization payments provided forms and evaluations are on file. September 3: * Students can begin submitting required code samples to Google ' * Snippets from [[http://groups.google.com/group/google-summer-of-code-announce/web/notes-on-organization-selection-criteria] [Notes on Organizations Selection Criteria]] ' We don't have any hard and fast rules for selecting organizations - there are many organizations that apply and many more than apply who we'd like to help with their open source efforts. In the end, we have to make many tough decisions about which organizations to accept. Here's a bit about our thought process: ... 2) Do the projects on your ideas list look feasible for student developers? Is your ideas list thorough and well-organized? Your ideas list is the first place that student participants are going to look to get information on participating in GSoC, so putting a lot of effort into this list is a good thing(tm). One thing we noticed and really appreciated this year was how some organizations classified their ideas by easy, medium and difficult, and specifically listed the skills and background required to complete a given task. It might also be cool to expand on each idea with some places to get started research-wise (pointers to documentation or specific bugs), as well as the impact finishing a given idea will have for the organization. 3) Did it look like you spent a decent amount of time on your application? Do we have a good sense of who you are and what you intend to accomplish in GSoC after reading it? Just as with an organization reviewing student applications, a thorough and well-written org application piques our interest. If it looks like you only spent ten minutes on the application, er, not so much. Particularly when the application questions were published weeks in advance of the application period. ... A final note, an organization may fulfill some (or all?) of these criteria and still not be accepted. We simply can't accept every organization that applies. ' * Snippets from [[http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-mentors-and-organization-administrators] [Guide to the Google Summer of CodeTM Web App for Mentors and Organization Administrators]] <later--more relevant if we apply and get accepted as a mentoring organization> * Snippets from [[http://code.google.com/p/google-summer-of-code/wiki/WikiStart][Welcome to the GSoC Knowledge Base Wiki]] <later, maybe> * Snippets from [[http://code.google.com/p/google-summer-of-code/wiki/AdviceforMentors] [Welcome to the Advice for GSoC Mentors Page]] Good stuff--anybody interested in mentoring should read this page, but note also this: ' For this benefit to be fully realised it is important to ensure that your whole project community are on board with the mentoring task. Just because an individual is named as the mentor, it doesn't mean that they are the only one who deals with the mentees issues. The mentee is just a member of the community, like any other. Of course the mentor has a few added responsibilities. It is them who has to ensure that the mentee is comfortable and that they are able to get the most from the community. ' There was another good page I found on mentoring, but I've misplaced that at the moment. Oh, wait, here are links to some from the page above: ' More Resources Federico Mena-Quintero, GNOME mentor for GSoC 2006, has posted a great [[http://primates.ximian.com/~federico/docs/summer-of-code-mentoring-howto/index.html] [mentoring how-to document]]. Sean Morrison, BZFlag mentor and org admin for GSoC 2007, has posted an [[http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf][overview of their participation in the program]]. Good reading for first time mentors. Warning: huge PDF, ~ 15 MB. You can also check out more notes on their [[http://my.bzflag.org/w/Google_Summer_of_Code/][project's wiki]]. Jan Schauman, mentor and org admin for mutiple GSoCs with the NetBSD project, did an [[http://arstechnica.com/articles/culture/netbsd4-interview.ars/8] [interview with Ars Technica on NetBSD's repeat performances in Summer of Code]], amongst other topics. ' * Snippets from [[http://www.gnome.org/~federico/docs/summer-of-code-mentoring-howto/index.html] [Summer of Code Mentoring HOWTO]] ' First, you need time. Be prepared to dedicate at least 30 to 60 minutes every day to your mentoring. There will be exceptions, such as days when your student is not online. But in general, you need to be able to dedicate a relatively large amount of time to your student. You will be communicating with her, clarifying doubts, making plans, checking her work, reviewing patches, communicating to other people about your student's work, or just chit-chatting. Second, you need to dedicate a good extra two hours every week to test your student's code or otherwise evaluate her work. Nothing is more demoralizing than a mentor who talks to you but doesn't actually see the fruit of your work in front of him. Third, you'll be mentoring on behalf of a project, or part of a project ("the file manager in GNOME"). You must know the code for this project or sub-project really well. Your student has probably never had to do anything with that code. You are the person who will answer her questions about where in the code something happens, or how the code is supposed to work in the grand scheme of things. Remember the first time you had to modify a big program: that's exactly how your student will feel, so you have to be prepared to answer questions about the actual code. Fourth, you must have a clear vision of what your student wants to accomplish. If you cannot see the finished "product" in your mind, you won't be able to communicate clearly with your student. This automatically rules out projects that are too experimental or imagined by architecture astronauts. ... Keeping yourself and your student organized You have your daily work, hobbies, and personal things to do. On top of that, now you have to coordinate and manage another person: your student. What do you do? Keep a journal or log of what your student does and of what you ask him to do. You don't need anything fancy to do this: maintaining a text file, ~/summer-of-code/student.txt is enough. The following is an actual sample of the log I kept for one of my students: ---< example log entries >---- Care and feeding of students IRC and IM are fine for day-to-day chatting with your student. In this modern age you may even be able to set up Ekiga or some other VOIP software — but don't waste too much time setting it up if it doesn't work at first. See the section called “Starting the project” below for how to pick a good time to chat with your student. Use email for detailed technical explanations; it is much better for that than IRC/IM, and it will be much easier for both you and your student to keep those emails around for reference. Your student knows few people in your project's community, and she is not used to all the informal or formal processes which that community has defined. You must take care of all the bureaucratic little details for your student. For example, if your project requires your student to wait for a sysadmin to create a CVS or Subversion account for her, then you should ask the sysadmin to do so as soon as possible. In general, help your student so she doesn't have to waste time waiting for administrative things to happen. Guide your student through the code. You have been working with it for years, while your student is probably looking at the code for the first time. Teach her all the little debugging tricks that you have amassed over the years. Your student wants and deserves recognition. Advertise your student's work far and wide! Every time she reaches an important milestone, do whatever it will take for people to notice: blog about it, send a screenshot to your project's mailing list, etc. People will get interested and they will contact your student; your student will feel appreciated as a result. Make sure your student uses a revision control system for the code. CVS/Subversion/Git are all fine. Also, teach your student the basics of Bugzilla or your project's bug tracking system if appropriate. Very important: if your project uses a nontrivial build system, a sandbox environment, or anything similar (for example, jhbuild for the GNOME project), teach your student how to use it and make sure she can get the code compiled and running very early in the project. This is in the same spirit as helping your student with silly administrative details: you don't want your student to waste time getting the code to compile; help her out! When your student gets stuck, help her to think laterally. Why do you think the problem is happening? Can you solve it in a non-traditional way? Tell her key places in the code to put debugging printf()s. Tell her the little tricks you use in your debugger. Only if she gets *really* stuck, solve that little part of the problem for her, but in general try to help your student solve the problem herself. ---< lots more good stuff--every potential mentor should read this >--- ' Randy Kramer -- NEdit Develop mailing list - [email protected] http://www.nedit.org/mailman/listinfo/develop
