Skip to content
Peter Jonas edited this page Feb 6, 2024 · 1 revision

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.

Tips

  • 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!

Getting feedback

If you would like feedback before the deadline:

  1. Write your draft proposal in Google Docs.
  2. Set the sharing permission to "Anyone with the link can comment".
  3. Check you can comment on it from an incognito tab / private browsing window.
  4. 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.

Submitting

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.

Resources


Proposal template

About you

Name and email

Please provide your full name and email address.

Discord nickname

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!

MuseScore.org and GitHub profiles

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!

Links to evidence (optional)

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.

Bio

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?

About the project

Synopsis

A short description of the project.

Size

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.

Duration

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.

Benefits

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?

Deliverables

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.

Schedule

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.

Implementation (optional)

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.

Conclusion

Why is this the right project for MuseScore? Why are you the right person for this project?

Testing

Translation

Compilation

  1. Set up developer environment
  2. Install Qt and Qt Creator
  3. Get MuseScore's source code
  4. Install dependencies
  5. Compile on the command line
  6. Compile in Qt Creator

Beyond compiling

  1. Find your way around the code
  2. Submit a Pull Request
  3. Fix the CI checks

Misc. development

Architecture general

Audio

Engraving

Extensions

Google Summer of Code

References

Clone this wiki locally