Steps toward a successful application

A lot of information is already available in the GSoC Contributor Guide. Do read it!

If you like to participate to Google Summer of Code with MuseScore, these are the steps you need to follow to apply:

• Help us get to know you.
  If you aren't communicating with us before the application is due, your application will not be accepted.

  • Hang out in our Discord Server. Ask questions, show us that you are motivated and well-prepared. There will be more applicants than we can effectively mentor, so do ask for feedback on your application to increase the strength of your proposal!

• Find something that interests you.
  It's critical that you find a project that excites you. You'll be spending most of the summer working on it (we expect you to treat the SoC as a full-time job).
  Don't just tell us how interested you are, show us that you're willing and able to contribute to MuseScore. You can do that by fixing a bug or submitting a pull request well before the deadline, in addition to regularly interacting with MuseScore developers and users on the forum and Discord Server. Our experience shows us that successful GSoC students demonstrate their interest early and often.

• Prepare your proposal with us.
  By working with us to prepare your proposal, you'll be getting to know us and showing us how you approach problems. The best place for this is in the Discord Server.

• Complete your application.
  Fill out our application template.
  Only the organization admin and the possible mentors will see this data. You can still edit it after submitting until the deadline!

Things you'll be expected to know or quickly learn

MuseScore is mostly written in C++ and use the Qt SDK. In addition to being familiar with C++, successful applicants will be familiar with or able to quickly learn about MuseScore's infrastructure. You can't spend the whole summer learning how to build MuseScore or prepare a changeset and still successfully complete your project.

• The build system. CMake is used to build MuseScore.
  While you generally don't need to understand too much unless you actually want to change how MuseScore is built, you should be able to understand enough to get a general idea of how to build MuseScore. You must demonstrate that you are able to build the development version of MuseScore from sources before the application deadline. Steps to compile MuseScore are available in the developer handbook.

• The version control system. We use git and GitHub.
  Git is the distributed version control system (DVCS) we use for managing our source code. You should have some basic understanding of how a DVCS works.

• The procedure for contributing changes.
  You will be expected to follow the same procedures as other contributors. You will be helping current and future MuseScore developers by using our standard style for changes, commit messages, and so on.

• The Developer Group Chat.
  https://musescore.org/en/handbook/developers-handbook/references/develo…
  It's very helpful for new contributors (you) to get immediate feedback on ideas and code.
  Unless your primary mentor has a strong preference for some other method of communication, the Developer Group Chat will likely be your primary means of communicating with your mentor and MuseScore developers.

• Progress blog.
  If you're selected for the program, you'll be expected to write up progress reports on your own musescore blog. Request activation in the Developer Group Chat. Once activated, you can add a new blog post using https://musescore.org/en/node/add/blog .

• Related skills.
  In addition, you probably should know some things about music and music notation and be able to read simple music. It's not mandatory and we already had successful students who couldn't but MuseScore is a tool for musicians, most of the developers are musicians too. Also music notation has a specific vocabulary that you should know or learn quickly (staff, stem, chord, beam, slur etc...)

Criteria by which applications are judged

These might vary somewhat depending on the mentors and coordinators for a particular Google Summer of Code, but typically the main factors considered would be:

• Applicant has demonstrated an ability to make substantial modifications to MuseScore.
  The most important thing is that you've contributed some interesting code samples to judge you by.

• Applicant shows understanding of topic.
  Your application should make it clear that you're reasonably well versed in the subject area and that you researched it before your application and won't need all summer just to read up on it.

• Applicant shows understanding of and interest in MuseScore development.
  The best evidence for this is previous contributions and interactions.

• Well thought out, adequately detailed, realistic project plan.
  "I'm good at this, so trust me" isn't enough. You should describe which steps you'll take to implement the feature and how you'll integrate with existing MuseScore code. You should also prepare a full timeline and goals for the midterm and final evaluations.