Skip to content

GSoC proposal phase session minutes

Note, fidelity of these notes is low. Copy-pasted from another attendee’s notes. Written collaboratively by multiple attendee’s during the session.

mailed to Stephanie as copy and link 11:55, 2023-10-24,

10:30-11:25, room Token Ring

Participants:

  • Arman Bilge (Scala Center) (AB)
  • Dominyjas Mosauskis (Mathesar) (DM)
  • Reimar Bauer (Python Software Foundation) (RB)
  • Eugene Sandulenko (ScummVM) (ES)
  • Alya Allen (Zulip) (AA)
  • Time Allen (Zulip) (TA)
  • Nir Krakauer (GNU Octave) (NK)
  • William Allen (Submitty) (WA)
  • Razvan Deaconescu (Unikraft) (RD)
  • Gabriel Henrique () (GH)
  • Wilhelm (CCExtractor Development) (W)
  • Punit Lodha (CCExtractor Development) (PL)
  • Benjamin Pross (52°North) (GE)

DM: Proposal phase was a lot of work for us (Mathesar). At the end, we were asking: is it worth it? The coding phase was awesome.

AB: We had really good applicants. How to navigate on really cool people.

RB: People joining very late don’t have time write a good proposal. It’s good to start early with testing, solving bugs, understanding how the process works.

RB: The invitation must be much earlier than the official start.

ScummVM project, our 15th application. ES: We made the project the application more complicated. They show several important skills. Make them set up environment, navigate code base, find out what questions they ask.

Our yield is about 30%-50% pass. The chances of people joining early is higher.

RocketChat: We are now starting the cycle for GSoC’24. We have a dashboard, and the communication starts early, very early. 60 applicant, 18 selected, 10 got approved

AB: How do you handle the beginners? ES: We don’t really care about them. They have 3 months to work, the need to pull it off without very much hand holding.

RB: You have to have good first issues. You need to define issues on the way to get to a solution.

We have only been considering people with considerable contributions. What about people who haven’t heard of GSoC and may be good.

AB: My concern is about people who feel intimated by the effort.

DM: This year he had very good candidates applying for the same project.

AA: We have tons and tons of documentation. If you’re not successful in the pre-GSoC period, you won’t be successful afterwards.

NK: We have a similar approach. People who we do select, do very well. Getting more applicants would be great.

RD: My concern is the spirit of the program, that is targeted towards newcomers to open source and to the project. I’m doing personal mentorship and those who pass a 6 months work time in the community, I don’t consider eligible for GSoC, as they are already experienced.

RB: For us, we have knowledge requirements that revolve in science.

AB: How do you do open proposals?

AA/TA: We are advising them to not write proposals 2 weeks before that. And we advise them to post the proposals publicly and ask for feedback.

RD: I am concerned about the spirit of the program. The focus is mentoring and not getting stellar candidates. Some of the filtering was if someone is already involved with the project for 6+ months should not be eligible because the spirit of the project is to get new comers. A possible idea to fix the hand holding problem is to start early.

GH: Opening communication is the way to go. We create a channel for each topic and encourage discussions.

RB: If we have students with the same idea, we create separate channels.

DM: We have a full time team, so we need to carefully carve out some projects for GSoC that won’t slow down the team.

TA: Ideally you would have a lot of items that are non-critical.

WA: We have a backlock of many issues. The GSoC team jumps to actual development.

AA / TA: We had someone who work on our development tool. It doesn’t have to be UI or a user interface. It could be something that is easy to review.

WA: These are more mature projects.

RB: A refactoring project may not be the best project for a GSoC project, due to its difficulty. Students learn how to write tests during the project.

AA / TA: We had a good experience with students working on refactoring projects. And we have students who were excited about them and get prepared for a professional portfolio.

W (CCExtractor): We are looking for technical projects.

GE: Balancing an expert vs getting someone to learn. Balancing the level of maturity is the problem.

RB: We had in the past three evaluations. And we can adjust the size, duration and the dates are variable. The proposal must be good enough to start, and belief that the student can do what is on the proposal. Then the goals can be adjusted.

RD: The problem at us (with Unikraft) was a noise problem and a selection problem. A bunch of applicants tried stuff and then disappeared. And then the selection resulted in some not-so-good students.

NK: We are concerned with

AB: How do you increase the reach?

ES: We post announcements on our website.

RD: I’m also in the university and I advertise it there. But mostly it’s with the keywords on GSoC website.

ES: We use the blog of our students to advertise projects. Potential contributors use knowledge from previous students.

RD: For us as well, a participant from last year created documentation and processes for the current year. Building on top of previous work helps new applicants.

GH: A video in a consumable format is useful.

AB: I will probably get in touch with professor that teach Scala. Getting part of a functional programming community is how I got involved.