2022 GSoC Project Ideas Planning

[kandersolar]

The 2022 season for Google Summer of Code is approaching. Here's the full timeline: https://developers.google.com/open-source/gsoc/timeline

First, note that they've made some changes starting in 2022, including different project lengths and applicants no longer needing to be students. See here: https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html

Assuming we want to participate again this year (I do!), I thought we should start getting our list of project ideas in order. Last year I came away with the impression that our 2021 list of ideas wasn't very well-suited for GSoC. And recall that the project we ended up pursuing wasn't even on our list :) Here's the list for 2021 (see previous link for details):

• Create usage examples
• Overhaul documentation
• Benchmarking and Profiling
• Accelerate package using Numba/Cython
• Add type annotations and static code analysis

GSoC is intended to help people new to open source start contributing to open source projects. With that in mind, I think many of these ideas are too advanced to be good GSoC projects. I imagine most newcomers to open source will be rather new to coding in general, or at least new to coding beyond the basics. Are there many people that are effective with Numba/Cython but need help getting started in open source? I bet not... Writing good documentation requires good knowledge of the package, which doesn't necessarily seem reasonable for a new contributor.

So I'm hoping we as a group can come up with some new ideas for this year. Input from all, not just @pvlib/pvlib-maintainer, is of course welcome :)

[AdamRJensen]

As a previous pvlib Google Summer of Code participant, I can only applaud this initiative. It was a phenomenal learning experience and I believe it was also of value to pvlib. So for any potential participant reading this, I can only encourage you to apply - you can read about my experience here.

I think the biggest flaw with the suggested projects in the past has been that they are very intangible and broad - for example, "overhaul documentation" or "create usage examples" could literally be anything and doesn't really have a well-defined scope.

I suggest we instead come up with two to four relatively well-defined projects that focus on a subsection of the library. A fictive example could be, "implementation of four mismatch and soiling models and adding usage examples".

[mikofski]

Thanks for kicking this off Kevin! I have a few thoughts:

1. I would like to target recruitment to folks in PV programs, internships at national labs, etc., so that we can get some applicants who have some PV background. To that end, I think we should reach out to professors, startups, NREL, Sandia NL, Lawrence Berkeley Labs, SLAC etc. Can we start a list of recruiters who can spread the word to their students, interns, and junior analysts?

2. I'll put this out there, I'd like to see a load/no-load transformer model in pvlib (see: Transformers #1269) as well as curtailment.

3. I'd also like to see a pvlib validation study against operational data like this paper "PHOTOVOLTAIC SYSTEM MODELLING USING PVLIB-PYTHON"

[cwhanse]

Maybe too big of a project: create an independent repository to host the module parameter extraction code, which is currently run by a manual process to produce files for SAM. Ideally, the repository would have a weekly job to fetch the latest CEC list and produce an up-to-date parameter file. The SAM developers have agreed in principle that this a good idea. Probably has a relatively high risk of unforeseen issues.

[AdamRJensen]

Note that the GSoC concept will change slightly in 2022 - your project idea could potentially fall under the "large projects".

This year we introduced the concept of a medium sized project in response to the many distractions folks were dealing with during the pandemic. This adjustment was beneficial for many participants and organizations but we also heard feedback that the larger, more complex projects were a better fit for others. In the spirit of flexibility, we are going to support both medium sized projects (~175 hours) and large projects (~350 hours) in 2022. - Google

[kandersolar]

Time flies... NumFOCUS needs to apply by the 21st (preferably sooner, I'm told), and we need to submit at least a preliminary project ideas list before then. Here's a draft page updated from our 2021: https://github.com/pvlib/pvlib-python/wiki/GSoC-2022-Projects

I've left @mikofski and myself as mentors -- Mark, of course feel free to remove yourself if you're too busy this year. And of course others are welcome to join if they're not busy this year :)

Next step is to submit a PR to the NumFOCUS GSoC repo like we did last year (numfocus/gsoc#360). If the rules are the same as last year, we can update the ideas page later on once NumFOCUS is approved to participate in GSoC, so I don't think there's any need to completely nail down the project ideas just yet. Barring any major objections, I'll submit that PR tomorrow so that we don't get left off the list. Edit: it is done (numfocus/gsoc#384)

[mikofski]

Thanks Kevin. I'm happy to mentor :)