On Sun, Nov 16, 2025 at 9:49 PM Jason Moore <[email protected]> wrote: > > Dear all, > > In the past, it seemed our approach was to try to take the best students > regardless of what they proposed (whether their own idea or one extracted > from our list). We would then accept as many as we could mentor. But this > approach is often awkward, or has gotten more so over the years, because it > doesn't align with the mentorship resources (quantity and desire). > > I would support an approach where we first start with a number of mentors, > then determine the number of projects, and those mentors draft the N ideas > for that year that can be applied for. We don't even have to consider any > other ideas.
I agree. I always try to do this but it's hard because we always seem to end up with more people we want to accept than mentors. It's also not as easy as just saying we have N mentors because different people can mentor different things. I cannot mentor people on mechanics projects, for instance (except as a backup mentor), so if we get only students applying for mechanics projects then I cannot really help even if I am able to mentor. > > It is also true that we get more applicants for some projects than others. If > we take the best applicant for that project, then we aren't necessarily > taking the best applications from the whole pool. Should we accept the best > applicants and assign them the projects or select the best per project? I think we should just continue to accept the best per project. The application process is semi-open so people should be aware if they are applying to a more "competitive" idea or not. People have to apply to what they think they will be able to do, and what they are interested in (and anyways, GSoC rules don't allow us to just completely change people's project from what they applied for). However, we should be more open about how many mentors we have for each type of project. I guess one issue is that the potential mentors list has a lot more people than actually mentor, and they aren't split by project type https://github.com/sympy/sympy/wiki/GSoC-Ideas#potential-mentors. We should fix that. If we only have, say, 4 people who are able to mentor mechanics projects, then ideally students should be aware going in that we will only be able to accept 2 (or at most 3) projects. It's challenging because some people will mentor any project to help out with mentoring, but a lot of people aren't fully committed to mentoring, or will only mentor a project if it's one they are interested in. I think a simple thing we can do is to replace that list on the ideas page with a table, with "name", "email", "types of projects willing to mentor", "can be primary mentor or just backup mentor" (anything else?). That would be more informative to the students and it would also help me as org admin a lot too. Aaron Meurer > > The LLM written proposals will grow again. I'm not sure what should be done > about that. > > Jason > moorepants.info > +01 530-601-9791 > > > On Sun, Nov 16, 2025 at 11:36 PM Oscar Benjamin <[email protected]> > wrote: >> >> Hi all, >> >> We are at the time of year where it seems that candidates are >> interested in GSOC. Every year the same list of projects is rolled >> over and I think that needs to change. Most of the ideas in the list >> are effectively impossible for GSOC or don't have anyone who would >> mentor them. Most of the ideas are not described in enough up to date >> detail to be implementable even if they are otherwise suitable. >> >> This year we should not carry over any project ideas from previous >> years and make a completely new GSOC ideas page with only ideas that >> are fresh this year or that someone confirmed that they would at least >> potentially be interested in supervising this year. Each idea should >> clearly describe the current state and what the most immediate work to >> be done is. >> >> Oscar >> >> -- >> You received this message because you are subscribed to the Google Groups >> "sympy" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion visit >> https://groups.google.com/d/msgid/sympy/CAHVvXxTwk%3DY0H02agwu6CN1PEzzC_uNm%3DJ2a%2BBH1QBs1Tk3F%3DQ%40mail.gmail.com. > > -- > You received this message because you are subscribed to the Google Groups > "sympy" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/d/msgid/sympy/CAP7f1AhzW7Wcht7Ydh2O6eM_qoFYcfo8Ly_mAjaum7usq7tDmQ%40mail.gmail.com. -- You received this message because you are subscribed to the Google Groups "sympy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6JtzfKXiPxVz55fMDTC5Yy-KCFvLBQ80_wj16YeNHe7ig%40mail.gmail.com.
