Karsten, what I really wanted to ask is how the CentOS community wants to handle 7, assuming there are always too many GSoC applicants. All the other steps are understood. What I did in the past was to organize 1-3 private meetings with mentors to come up with a shortlist and figure out how many slots to allocate. The scoring mechanism is OK, but people tend to give their proposals often a higher score than they should and mentors have different expectations. Coming up with a shortlist (or ordered list of applicants) can be a bit of a chore for larger projects and there could be disagreements between mentors of course. And from past experience I found that it is better to focus on the best students and the ones who engage with the mailing list very publicly straight from the beginning. Those who don't rarely tend to engage more during the program. With Easter being pretty soon and many Europeans being on vacation, it may make sense to start planning 7 soon. The slot application deadline is 2 weeks after the application deadline and then there is a bit more than a week after that to make a selection. * 27 March: 19:00 UTC - Student application deadline. * Interim Period: Mentoring organizations review and rank student proposals; where necessary, mentoring organizations may request further proposal detail from the student applicant. * 13 April: Mentoring organizations should have requested slots via their profile in Melange by this point. * 15 April: Slot allocations published to mentoring organizations. * 21 April: Chose the students we want to take (with 1 or two back-ups in case they applied for other orgs too) Regards Lars > On 23 Mar 2015, at 15:57, Karsten Wade <kwade at redhat.com> wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 03/23/2015 04:45 AM, Lars Kurth wrote: >> Hi all, do you have a process in mind for selecting GSoC >> applicants? > > I don't think the process varies by that much project to project, this > is what I've used and seen in the past: > > 1. Mentors work directly in public to answer all questions in advance > and during the proposal process. Any new info can be carried in to the > relevant Idea page. > > 2. Students begin writing application proposals in the Melange tool. > > 3. /All/ mentors read through at least the proposals related to the > idea they are mentoring for, and are encouraged to read through all > the proposals in general. > > 4. Before the application deadline, mentors make suggestions and > requests of students to improve the application proposal. > > 5. After the application deadline, mentors continue to work with > students to improve and polish the application. > > 6. During that process it often becomes obvious which students have a > chance of doing the work. The proposal process is a miniature > experience similar to the whole GSoC process -- students have to learn > to ask smart questions, turn those in to a work product, and interact > positively with the mentors. > > 7. There is a step in the timeline where the mentors will deliberate > on the proposals in private. Part of that work is to rank the > proposals in an honest way, which is more important than fighting to > get our own personal proposal to be ranked higher just because we want > it to be accepted. > > Our exact end-game process will happen during the last step, with some > of the process creation happening as we go through the earlier steps. > > - - Karsten > > >> Regards Lars >> >>> On 10 Mar 2015, at 23:28, Karsten Wade <kwade at redhat.com> wrote: >>> >> On 03/10/2015 05:32 AM, Karanbir Singh wrote: >>>>> Hi, >>>>> >>>>> On 03/09/2015 10:22 PM, Karsten Wade wrote: >>>>>> KB: >>>>>> >>>>>> Can you look at the excerpt below and let me know what you >>>>>> think? >>>>>> >>>>>> tl;dnr - I'd like to get consensus right away on where >>>>>> we'll be having the technical part of the student/mentor >>>>>> discussions. Some cases it will be in the upstream project >>>>>> space, but I think best practice especially during the >>>>>> coding time of the Summer is to use "the usual channels", >>>>>> i.e. centos-devel and #centos-devel. >>>>> >>>>> Thought we already closed on this, I agree : tech content, >>>>> about the distro - #centos-devel( irc+list) gsoc specific / >>>>> admin specific - #gsoc (irc+list) >>>>> >>>>> Having worked with the ideas in prep for this, everyone of >>>>> the efforts is going to have integration points with other >>>>> efforts, and in many cases with ongoing centos development >>>>> activities ( either in infra/ cbs / ci / release stuff ), so >>>>> keeping those conversations to #centos-devel makes the most >>>>> sense. >> >> Thanks, I wasn't clear on the answer, just wanted to make sure >> before telling all the mentors and students. >> >> - Karsten >>> _______________________________________________ CentOS-devel >>> mailing list CentOS-devel at centos.org >>> http://lists.centos.org/mailman/listinfo/centos-devel >> >> _______________________________________________ CentOS-devel >> mailing list CentOS-devel at centos.org >> http://lists.centos.org/mailman/listinfo/centos-devel >> > > - -- > Karsten 'quaid' Wade .^\ CentOS Doer of Stuff > http://TheOpenSourceWay.org \ http://community.redhat.com > @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iEYEARECAAYFAlUQN+8ACgkQ2ZIOBq0ODEHo7QCcCMdJL9lJJPCzdJMOWTg72lGE > g5kAni9Tcydq3Hw2asJ5rrll6flnx2Vq > =to4P > -----END PGP SIGNATURE----- > _______________________________________________ > CentOS-devel mailing list > CentOS-devel at centos.org > http://lists.centos.org/mailman/listinfo/centos-devel