A key activity for org admins is setting up and supervising the process by which student proposals are prioritized and matched with mentors. There are many good ways to do this. There are also a few common ways to proceed that are not so good. In any case, understanding how organizations commonly approach student and mentor selection can help to ensure a better outcome from this critical step.
Conceptually, the process of selecting students and mentors is simple. In practice, the process of prioritizing proposals and assigning mentors can be difficult and contentious.
During the student application period, organizations prioritize the student proposals, discard proposals unworthy of consideration and investigate proposals further. At some point, Google tells the organization how many "slots" the organization will be allowed to fund. The highest-priority projects at the close of the application period will be funded ("slotted") by Google. If something causes a student to drop out later on, the organization's priority list is used to fill in a replacement. Mentors must be assigned to all projects that the organization wants considered for slotting, preferably as early in the process as possible.
Proposal volumes tend to be high, and the nature of the activity can lead to disagreements and bruised egos. Make the process for deciding on projects clear early, and be consistent.
Google asks your organization how many slots you want twice during the selection process; once when your organization is accepted, and again shortly before slot allocation. The actual number of slots you receive is mostly a function of the number of reasonable-quality applications your organization receives during the proposal period, but there are limits.
Every accepted organization is allocated at least one slot. First-year organizations rarely get more than five slots. No organization ever get more slots than they asked for.
There is no net advantage to getting as many slots as possible. Sure, more students get paid, and the org gets paid a little more. However, accepting less-than-great applications has a huge cost in time and grief. Google's process for choosing organizations includes the pass/fail ratio. Poor ratios may endanger future participation in GSoC. If you must pad slot requests, pad them only slightly, and be prepared to return slots to Google or to sister organizations when you find you have extras.
If you discover that you haven't gotten the number of slots you were hoping for, Google's program administrators will start a waiting list to move slots around amongst the organizations.
Students are allowed to submit proposals to many organizations each year. When organizations have slotted their desired students, it is inevitably the case that a few students are sought by more than one organization. Ideally, selecting a fit for these "duplicate" students will happen before the end of the proposal period. At the end of this period, any remaining duplicates are resolved online in a large IRC "deduplication" meeting. A representative of each organization with a slotted duplicate student must attend the deduplication meeting; otherwise they will lose that student.
The deduplication process involves interaction with peer open source organizations. It is critically important that you are polite and cordial, and put the needs of the student first. Whenever possible, student preferences should be honored. Keep in mind that you may have to work with these organizations outside GSoC; generating ill will here is not worth it. Also keep in mind that Google's program admins emphatically do not want to have to deal with hostility and conflict here. Don't endanger your future participation in GSoC just because some other organization wants some student as much as you do. Be nice and get out of the way.
Most organizations use the Google-sponsored open source Melange web tool to manage their student selection and mentor matching. This software is the result of a complicated evolutionary process, and has it's idiosyncracies.
Melange supports the basic activities of prioritizing applications and adjusting those priorities, of assigning mentors to projects, and of collecting comments and ratings. Since Google uses Melange for slot allocation, slotting and deduplication, all organizations need to interact with Melange to some degree. It is a good idea to get things set up there early, so that issues that arise with the software can be dealt with in a timely fashion.
Building a mentor pool and matching mentors with projects and students is one of the most challenging tasks for the org admin. For many organizations, the mentor will be selected by project when the ideas page is constructed. For others, mentors will be assigned once students have been selected and matched to projects.
Look critically at mentor volunteers. Wanting the job is not a sufficient qualification. The mentor should be well-known to the community, and known to be someone reasonable and collegial. The best technical person is not necessarily the best mentor; look for teaching and...well..mentoring skills.
Do not be afraid to reach out to folks in the organization who have not volunteered. The ideal mentor for a project may not have heard of GSoC, or may not have considered herself a candidate for mentoring. She may be flattered to be asked.
Make sure you have enough mentors, including quite a few spares. Folks who would be capable of mentoring a variety of projects are especially welcome. Strongly consider having enough backup or secondary mentors that every project has an alternate of some sort.
If you (or the mentor) are insecure about their qualifications having them join the project as a back-up mentor is a great strategy to encourage future participation.
Use Melange's "ignore" feature to avoid spending time on proposals that were not tailored to your project.
Occasionally a student does not understand the importance of attribution when drawing on material from outside sources. Make sure she understands, early on, that plagiarism is not tolerated. In blatant cases, a good response is to reject the proposal and consider informing the administration at the academic institution the student is affiliated with. The article http://tesl-ej.org/ej10/a2.html has some context to avoid surprises.
Probably the best that can be done in suggesting selection strategies is to provide a few simple ideas that organizations have used effectively in the past. Your organization will build its own selection process over time; these ideas are just a starting point:
Get outsider help. Having a perspective from outside the "GSoC bubble" may help you see student proposals in a new light. Sometimes, even folks from outside your organization can provide useful review, especially if they have relevant technical expertise.
Use your mentors wisely. The mentors are in the best position to select students and proposals for themselves. After all, it is they who will have to work with these students. Be careful, though, of mentors who may be less experienced in the ways that GSoC students and projects can go wrong. A few well-chosen war stories can be helpful in this situation.
Interact with the students during the proposal period. There should be no remaining questions by the time students are slotted. Finding out that a student will not interact, or cannot interact well, is absolutely crucial.
Don't be afraid to take charge. At the end of the day, the org admin is responsible for the student and mentor selection decisions. If your org doesn't give you full veto power, or gives you grief about executive decisions, consider stepping down. Sometimes somebody has to make the final decision.
There has been error in communication with Booktype server. Not sure right now where is the problem.
You should refresh this page.