On 24/01/18 05:24, mollydb wrote: > >> While I've personally proposed more than one idea, there are several >> co-mentors I'm speaking to for each of them. As long as each one has >> sufficient co-mentors and at least one motivated applicant why shouldn't >> we request slots for all of them? >> >> Personally, I'm not going to commit myself to more than one project this >> year. Deciding which project I will personally be mentoring will depend >> on the level of interest from co-mentors and students for each of the ideas. > I spoke with some people from the Google Open Source team who suggested > that, while we can have as many proposals as we'd like, we highlight the > top five we're most excited about. This helps them during the review > process. While we can have more listed overall, it was > requested/suggested we prioritize our top five.
OK, if this is just for the review process then it is probably good to focus on 5 of the projects that already have more than one mentor and from those, picking 3-4 with really clear goals and maybe 1-2 that are more flexible (like the PGP clean room, it is quite big and a student could choose to focus on any part of it). Aiming for different themes and programming languages could be useful too (e.g. one security, one development tools, one web project, ...) Later on, I'm concerned about putting effort into promoting the program if we are not going to have a similar probability of getting slots as we had in the past. If we build up 25 really good applications like we did in 2016 and Google only funds 5 of them then the mentors working on the other 20 have lost a lot of time. Will you be at FOSDEM next week and will you have time to discuss this more in person? >>> 2) I don't think an onboarding wizard is really an appropriate position >>> for a student/participant. It's outside the scope of GSoC (unless >>> they're developing technical tools for Debian). As for Outreachy, I, in >>> general, believe the funding would be better used on other projects. >>> >> Can you please tell me why you feel it is outside the scope of GSoC? >> Google's only rules are that they have to be students and they have to >> write code. > Okay. I misunderstood that you were looking to design a tool for Debian > to use for onboarding participants. > > I spoke with Sage (from Outreachy). They're redoing their application > and own onboarding process. I think any Debian focused project on this > front ought to wait until that's done. > >From the discussions with Sage on the mentors mailing list, I had the impression that involves the stuff the interns fill in on the web site about their project (e.g. their profile, skills, goals, project plan). Right now it is all one big text document and they are making it more structured which is great. This onboarding wizard is for the stuff the interns do on their own computer: development tools, communication tools, etc. It is not just for Outreachy or GSoC though: it could be for anybody who wants to become a contributor for the first time. Maybe a university will offer their students a course on contributing to free software, they would run through this wizard in the first lesson/workshop. I go through similar steps with people when I run meetings or events. > Do mentors find the process of helping applicants with GPG and blogs > onerous? It's the kind of thing I'd like to make sure of before putting > resources into it. > For over half of them, this is the first time they publish a patch or a blog publicly. Anything we can do to get them to that small success more quickly, using this wizard, may increase the percentage of people who achieve that. If they get there more quickly, some are also more likely to repeat that sharing process too. As a mentor, I'm the one volunteering to put my time/resources into it so I don't understand the level of concern. One of the things I like about this program is that Google gives mentors and interns a lot of flexibility to try new things. I've been mentoring in these programs for 5 years now and I've never found an applicant who has everything listed in the description[1] of this wizard. The best applicants usually have over half of those things but need to be prompted for at least one of them. As an example, it is very easy for a script to check if they have ~/.ssh and if not, run ssh-keygen. If they do have ~/.ssh, the script can check the key length and tell them if it meets Debian's expectations. Next it can check for ~/.gnupg, repeating similar checks. Out of 75 applications in 2016, imagine each one and their prospective mentor spent some time on all these little things. This can't be done through Outreachy's web application process either: it is all on the local machine. The application process is also a learning opportunity for many people. For some of them, they have experience in Python or Java but they haven't used Debian or Linux before. They install Debian for the first time during the application process or shortly after being selected and most of that is automated if they choose the quick install. This wizard will let them maintain the momentum from the installer, right up to the point where they can be a contributor and not just a user. I would estimate that I typically spend at least an hour with each applicant (even those who are not selected) so over the last 5 years, this tool would have saved me 100 hours and probably would have increased the number of applicants who completed a full application to GSoC or started making contributions in some other way. Regards, Daniel 1. https://wiki.debian.org/SummerOfCode2018/Projects/WizardForStudentsAndNewInterns
