Today it has been confirmed officially (mailing list) that 2020, Google Summer of Code (GSoC) will exist again! :tada: A student will be "around 30+ hours a week working on [LMMS] during the 3 month coding period". A maximum of 2 students is recommended for the first GSoC year of an organization.
I think this is a great opportunity for us to get some things done. However, we need to decide what topics we offer for the GSoC (deadline is February 5).
I'd like to propose "Make the LMMS core realtime safe". This will be a medium-difficult topic with a lot of core refactoring, where a student can learn a lot. Maybe 3 months are not even enough for it, but I hope it will be to at least fix the most realtime problems. I also propose mentoring this topic, though I'll be happy (even more happy?) if someone else wants to mentor it.
If we take that topic, we still have place for a second topic, If not, we have even two. Who has a good topic, and/or would like to mentor (Google claims it's ~5 hours per week)?
Well, I don't know if it's a good idea, but from my user point of view I propose the theme: ''Recording after rebase to master'' and everything related to audio recording in LMMS. since this topic is one of the most demanded by LMMS users. I do not know if it is possible to implement this in the established time, but it would be a great advance to add this feature to LMMS.
I now set up a wiki page with ideas for Google Summer of Code 2020. Everyone can add proposals there. Deadline is February 5, where we'd need to submit our ideas to Google.
At all active developers, please read the following two points (and sorry for tagging you!):
If you're interested in GSoC 2020, consider adding a topic on the wiki page (or saying you want to mentor but don't have a topic). It's a unique chance where you work 5 hours a week and the result is a student working full time for the project! (Plus, being a GSoC mentor can look nice on your next job application)
I do not have the C++ experience to mentor.
If you don't have a topic/don't want to mentor: There needs to be at least 2 organization administrators for LMMS. They mostly just supervise the mentors (there is a task list, point 5 on this web page), but as every mentor can be admin, it's more formal, you won't have much to do. If I do mentor + admin, we at least need a second admin for LMMS.
I may be able to help administer if no one else is available.
I can participate as a mentor. I don't have a specific topic now, but I will add one if I find a suitable one.
I'd like to add that some people tend to focus on stuff like separating UI and core, realtime safety, but there's also quite a bit of very basic needs that have been asked over and over based on popularity that may be a smaller learning curve and more immediate value to end-users such as the laundry list of workflow items, especially those with many duplicate bug reports #4877.
User defined keybindings would be a nice addition. I think the work needed would be an appropriate size for GSoC too.
I'm currently creating a dashboard for our organization. Anyone who wants to admin, PM me on discord and give me your mail address. I'd enter it, and google would know your address then.
OK, I filled out most of the application text fields in the dashboard (only visible for admins), a few remain.
Also, everyone, keep in mind: Deadline is February 5.
From the workflow meta issue #4877, I found that there are many issues regarding the FX mixer. Improving FX mixer looks like a good topic, too.
There are some other possible topics like plugin development and THE audio recording(~@Reflexe 馃槄~)as well.
In terms of "user wants" audio & sample recording was at first place.
23 hours left.
We still have only one topic, which is OK, but not much. If anyone wants to add a topic it must be done in the next 23 hours.
LMMS was unfortunately not accepted for 2020 馃槥
Most helpful comment
I'd like to add that some people tend to focus on stuff like separating UI and core, realtime safety, but there's also quite a bit of very basic needs that have been asked over and over based on popularity that may be a smaller learning curve and more immediate value to end-users such as the laundry list of workflow items, especially those with many duplicate bug reports #4877.