GSoC Proposals - musescore/MuseScore GitHub Wiki
This page describes how to write a proposal for Google Summer of Code (GSoC).
These steps apply regardless of whether you are proposing your own idea or one of our approved project ideas.
-
Write your proposal in Google Docs.
- This makes it easy for mentors to leave comments and suggestions.
-
Use proper text styles for titles and headings, etc.
- Headings help break the document down into manageable chunks so the reader isn't presented with a massive wall of text.
- You can customize the styles if you want, but you won't gain/lose any marks for doing so as long as the writing is legible.
-
Say the minimum you need to say in order to get the point across.
- You don't gain extra marks for waffle, but you don't lose marks either, so don't spend ages padding out the proposal or cutting it down. Once the proposal meets the requirements, you're better off investing your time in pull requests.
-
Include screenshots, mock-ups, or diagrams.
- These are great for demonstrating that you really understood the problem.
- A picture tells a thousand words, and we'd much rather look at a picture!
If you would like feedback before the deadline:
- Write your draft proposal in Google Docs.
- Set the sharing permission to "Anyone with the link can comment".
- Check you can comment on it from an incognito tab / private browsing window.
- Share the link with team-members Peter or Casper via private message in Discord.
Remember that the draft proposal link does not count as a final submission.
Download the Google Doc as a PDF and upload it to the GSoC Dashboard before the deadline.
Google allows you to remove and re-upload the PDF as many times as you want until the deadline passes, so it's best to submit early and amend later if you can.
Please provide your full name and email address.
If you frequent our Discord Server please let us know what your nick is. If you don't, you'd better connect and introduce yourself!
Please link to these profiles. To save us time, you should also link to your GitHub pull requests for MuseScore. For example:
| MuseScore.org profile | https://musescore.org/en/user/57401 (shoogle) |
| GitHub profile | https://github.com/shoogle |
| MuseScore PRs | https://github.com/musescore/MuseScore/pulls/shoogle |
To find your musescore.org profile, visit musescore.org/user and copy the URL this page redirects to (if you are logged in).
Important: We need your musescore.ORG profile link, not your musescore.COM profile link. They are not the same!
If you have any web pages you'd like us to know about, please include links to them. These could be:
- A website, blog, or YouTube channel that you run
- A repository on GitHub that you own or manage
- An impressive pull request that you submitted to us or another open source project
- An interesting music/programming/design discussion thread that you participated in
Don't worry if you feel you have nothing to show here. The main things we are looking for is at least one non-trivial pull request on MuseScore's repository and some activity in the Discord Server.
Remember, to be eligible to participate you must be a student or a beginner. If you're not a student, and you already make non-trivial open source contributions on a regular basis, this would make you ineligible to participate as a GSoC contributor.
Tell us a bit about you, such as:
- What are you studying and where, or if you are in work what is your job?
- What activities do you enjoy?
- What is your experience with MuseScore or other music notation software?
- What code development projects have realized, music or otherwise?
- Are you a musician? Which instrument(s) do you play or vocal parts do you sing?
A short description of the project.
Do you consider the project to be Small (~90 hours), Medium (~175 hours), or Large (~350 hours) in size? We may ask you to change this if we disagree.
Please note that the project size cannot be changed after the proposal submission deadline. We will not select your project if we feel the requested size is inaccurate.
Do you expect to complete the project within the standard 12 week coding period or do you anticipate needing extra time?
Google allows projects to be extended by up to 10 weeks beyond the normal 12 week period. The extension can be granted during the project if necessary, but we want to know in advance wherever possible. Please state your reasons briefly here (e.g. time off for vacation, work, classes, coursework, etc.) and then elaborate on this in the Schedule section if required.
Describe how your project will benefit MuseScore and/or MuseScore users.
Does it benefit musicians? Does it benefit future development?
If the project is about code architecture or development infrastructure then it probably won't benefit end users directly. That's OK if you can tell us how it will benefit other developers, and (ideally) how this could lead to future benefits for end users. Maybe it unblock other features, or permits a faster release cadence?
Provide a user-level summary of the final output or results of your project. What does it look like? How do users interact with it? How does it cooperate with the rest of MuseScore's features? (For architectural/infrastructure projects, the "users" might be other developers.)
What would the MVP (minimum viable product) look like? Would it be ready straight away, or are you laying the groundwork for a larger project that will require more development after GSoC?
There might not be time for everything so try to identify what is essential and what could be left for optional stretch goals at the end of the project.
Include an estimated timeline of the project with mini-milestones. How long will it take? When can you begin work?
Please number the weeks during the coding period and give each Monday's date as the week beginning. The schedule is just an estimate so don't worry if you're not sure how long things will take or what order you will tackle them in.
| Week | Beginning | Tasks |
|---|---|---|
| 1 | 13th June | Do research. Get familiar with code. |
| 2 | 20th June | Start implementing feature X. |
| 3 | 27th June | Vacation. Unavailable. |
| 4 | 4th July | Finish feature X. Tidy code and submit PR. |
Where possible, try to break the project down into stages that can be merged in separate PRs throughout the project rather than in one big PR at the end.
Your goal should be to have an MVP (minimum viable product) ready at the earliest possible stage. If the project turns out to be harder than expected, the MVP might be all you manage to get done.
Your work will serve as a starting point for future development by the community or internal team (or by you if you stick around!). For this reason, you should schedule time for tidying and commenting the code, as well as writing documentation to aid users and other developers.
Be sure to mention any vacation time or other commitments (e.g. work, classes, coursework, etc.) you expect to have during the project period. We can allow for some flexibility during the project, but we will fail GSoC contributors who do not give advance notice of prior commitments or extended periods when they will be unavailable during the coding period.
For bonus points, tell us any details you can about how you would actually implement the project in the code. You could:
- Mention some files and classes you expect to create/edit/remove as part of your project.
- Describe an algorithm that you will have to implement.
- List any libraries or resources that you might need to include, and explain why you chose them over alternatives.
- Create a simple UML diagram or flowchart to illustrate how different areas of code will interact.
This really is a bonus section, so make sure you've completed everything else and sought feedback from us before doing any work on this section.
Why is this the right project for MuseScore? Why are you the right person for this project?