Thank you for your interest in helping to develop SuperCollider! There are many ways you can help out:
- Answering questions from your fellow users in the mailing list.
- Filing bug reports and feature requests.
- Writing and maintaining documentation. Anything from typos to entire tutorials helps. Documentation contributions are done in the form of pull requests (see below). If you are using scide, there is a useful trick to setting up your workspace for documentation edits.
- Reviewing, discussing, and testing out proposed changes.
- Improving other auxiliary parts of SC, such as sc3-plugins, this website, and the various quarks.
Bugs and Features
SuperCollider uses Git for source code control. Git knowledge is necessary to try out the latest developer versions and to contribute your own changes.
You can submit changes in the form of pull requests, gratefully accepted at our GitHub repository.
The first step to filing a PR is to get your git environment working. First, fork supercollider/supercollider on GitHub. By convention,
origin should point to your fork, and
upstream to the main repository:
git remote add origin firstname.lastname@example.org:YOUR_GITHUB_USERNAME/supercollider git remote add upstream https://github.com/supercollider/supercollider
For each pull request, you should first update your fork to match upstream (not needed, but it helps guard against conflicts):
git checkout master # switch to master branch git pull upstream master # download the latest and the greatest git push origin master # update your fork on GitHub
To start a new branch:
git checkout master # make sure your new branch is based off master, not something else! git checkout -b topic/my-great-improvement # add and commit your changes git push origin topic/my-great-improvement
Your changes are at the “topic/my-great-improvement” branch on your fork of SuperCollider. Now point your browser to your SuperCollider fork and file a PR. (The “topic/” prefix is a Git convention used to mark a “topic branch,” which is a branch created for short-term development use. It helps organize the list of branches in your fork, but it’s also fine to leave it out.)
Here are some important guidelines for making pull requests:
- Don’t put unrelated changes in the same pull request. Separate by functionality or issue.
- Try not to change whitespace or needlessly rearrange things if they don’t have anything to do with the issue you are fixing. Save rearrangement for a separate commit.
- Be patient! It might take a few days for your changes to get reviewed and merged. Smaller PRs get merged faster, which is another good reason to break down your contributions into bite-sized pieces.