Application Template

最終更新は 2 ヶ月前

    Please read the "Writing a proposal" chapter from the GSoC Contributor Guide. The full guide is a must read if you want to apply.

    Write your draft proposal in Google Docs and share a link with us via the GSoC Dashboard. Set the sharing permissions to "Anyone with the link can comment" and check you can access it via an incognito / private browsing window. Ask a mentor in the Discord Server to review it for you.

    Remember that the draft proposal link does not count as a final submission. You must download the Google Doc as a PDF and upload it to the GSoC Dashboard before the deadline.

    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, then you'd better connect and introduce yourself!

    MuseScore.org and GitHub profile links

    Please include links to these profiles. To save us time, you can also include a 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?q=author:shoogle

    Please note that your musescore.ORG profile has a different link to your musescore.COM profile. We need the .ORG profile link. You can find this by visiting https://musescore.org/user and copying the URL this redirects to (if you are logged in).

    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.

    Please note, if you already make non-trivial contributions to open source projects on a regular basis then this would make you ineligible to participate as a GSoC contributor, but you could still participate as a mentor.

    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 and Duration

    Do you consider the project to be 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 period or do you anticipate needing extra time? Google allows projects to be extended by up to 10 weeks (i.e. total length of 22 weeks). The extension can be granted during the project if necessary, but we want to know in advance wherever possible. Please state your reason(s) briefly here (e.g. time off for vacation, work, classes, coursework, etc.) and then elaborate on this in the Schedule section if required.

    Benefits to MuseScore

    Describe how your project will benefit MuseScore. How will it benefit musicians using MuseScore to create scores? Will it be an aid for future MuseScore development?

    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?

    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. What would the MVP (minimum viable product) look like? Would it be ready for end users straight away, or is it just the beginnings of a system that would require further development beyond the end of your project?

    Schedule

    How long will the project take? When can you begin work? Include an estimated timeline of the project with mini-milestones. Please number the weeks during the coding period and give each Monday's date as the week beginning:

    Week 1 - 13th June
    Do research. Get familiar with code.

    Week 2 - 20th June
    Start implementing feature X.

    Week 3 - 27th June
    Unavailable (vacation).

    Week 4 - 4th July
    Continue implementing feature X.

    The schedule is just an estimate so don't worry if you're not exactly sure how long things will take or what order you will tackle them in. 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.

    The aim is to have your 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, but it should serve as a starting point for future development by the community or internal team (or by you if you stick around!). For this reason, it's a good idea to spend a bit of time tidying and commenting the code as you go along, and writing documentation at the end of the project to aid future development.

    Make sure you note any vacation time or other commitments (e.g. work, classes, coursework, etc.) you expect to have during the project period. Such things may provide valid reasons for requesting an extension in advance. With the exception of fixed dates like the first evaluations, we can allow for some flexibility during the project. However, 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 have completed everything else first and sought feedback from us before doing any work on this section.

    Conclusion

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