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 organization administrator will select the org's choices on the program site at the close of the student selection period and they will be funded ("slotted") by Google. 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 slighty before slot allocation, after you have had time to review the student proposals that your organization received. The organization administrator is asked to enter both a minimum number of slots requested and a maximum number of slots requested. When deciding on your top proposals you should also be sure there is at least one mentor that has committed to mentor that project.
The actual number of slots Google assigns to each organization depends on the number of organizations and the number of students Google is going to fund that year. Then the slots are distributed amongst the accepted organizations by Google. Every accepted organization is allocated at least one slot. First-year organizations rarely get more than two slots. No organization ever receives 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. And if you request more slots than you need you are essentially taking those slots away from other organizations who could have used them for some of the excellent student proposals they received.
If you discover that you haven't received the number of slots you were hoping for then choose the best proposals to match the number of slots you have been given. And be sure to do a great job with those students so that in the next year of GSoC Google may be able to give you a couple more slots the next time around.
If you ask for a certain number of slots and are given that number but then realize you don't have enough mentors to cover all of the projects you have essentially wasted that slot and taken it out of the hands of another organization that didn't receive the number of slots they requested relative to their excellent proposals. There is no way to trade unused slots with other organizations.
Students are allowed to submit up to 5 proposals each year, and they can be to multiple organizations. When organizations have chosen their desired students based on the number of slots they were given, it is inevitably the case that a few students are sought by more than one organization. Starting in 2016, when an organization chooses their student that another organization has already chosen, the second organization's administrators will receive the contact information for the Organization Administrator with the first organization that chose the student. Then if they wish to plead their case for the first organization to release the student so the second organization can have them for a very important project they can. Ultimately it is up to the first organization that chose the student to decide if they want to release that student and let the second organization have that student. If the first organization releases that student they then can choose another student to fill that slot.
This 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.
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.
Avoid spending time on proposals that were not tailored to your project by using the "ignore" feature for student proposals.
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.