Skip to content
Marcin Pączkowski edited this page Feb 3, 2022 · 30 revisions
Clone this wiki locally

If you are looking for information on using SuperCollider, including documentation, you may want the following resources:

  • the project README has general information on the project including a description, a list of supported platforms, instructions for building and installing, and a list of good first resources.
  • has project documentation viewable online.

If you are looking to meet and talk with other people using SuperCollider, check out Joining the community below.

If you are new to SuperCollider and want to contribute to the project, then first and foremost thank you for your interest! We appreciate that you want to contribute to SuperCollider. Your time is valuable, and your contributions mean a lot to us.

Depending on your skills, interests, and experience with other projects, you may want to review the following documentation:

Joining the Community

SuperCollider users and developers communicate on a number of different channels. Here's how to access them:

What does "contributing" mean?

Creating an issue is the simplest form of contributing to a project. But there are many ways to contribute, including the following:

If you're new to this project, check out the issues tagged "good first issue" – fixing one of these is a great way to get started as a contributor!

If you'd like to learn more about contributing to open source projects in general, the Guide to Idiomatic Contributing has a lot of useful information.


Before creating an issue

The purpose of the issue tracker is not just to report that there's a problem with SuperCollider, but to effectively communicate what the problem is so that others can easily help reach a resolution.

Investigate the issue: What is the minimum effort or code required to produce the issue? Does it happen every time? Can you get it to happen on someone else's computer? Someone else's operating system?

See if a ticket already exists: Search SuperCollider's open issues. If an issue for your problem already exists, it may be appropriate to leave a polite comment stating that you can reproduce it on your system, plus any additional info that isn't already known in the issue thread.

Ask the community: If you feel that you need some help investigating the issue, it may help to ask sc-dev, sc-users, or Slack.

Fill out the issue template: Once you feel that you have information for an effective issue, file an issue on the GitHub issue tracker and fill out the template. Please don't erase the template — it's there to help structure your report effectively.

Be sure to create your issue in the appropriate repository. Note that sc3-plugins are maintained in their own repository separate from SuperCollider.

One ticket at a time: If you have multiple issues to report, please open separate tickets for each one.

Creating an issue

We have provided an issue template for you to fill out so that the basic gist of the issue is easily determined at a glance. Please don't erase the template. It's there for a reason.

When an issue involves a crashing or unresponsive executable and you don't know why, providing a crash report can give developers a very helpful first step toward resolving the problem. See Generating a crash report for instructions for your platform.

Above and beyond

Here are some tips for creating idiomatic issues. Taking just a little bit extra time will make your issue easier to read, easier to resolve, more likely to be found by others who have the same or similar issue in the future.

  • Take some time to learn basic markdown. This markdown cheatsheet is super helpful, as is the GitHub guide to basic markdown.
  • Learn about GitHub Flavored Markdown. And if you want to really go above and beyond, read mastering markdown.
  • Use backticks to wrap code. This ensures that code will retain its format, making it much more readable to others
  • Use syntax highlighting by adding "supercollider" or the appropriate language name after the first "code fence" ("```supercollider")

Pull Requests (PRs)

Graciously accepted.

Before working on a pull request, consider whether it might be better to go through the Request for Comments (RFC) process first!

SuperCollider uses the git-flow branching model. We use the develop branch for new features, deprecations, and breaking changes, and we use the 3.12 branch for bug fixes for the next 3.12.x patch release that have no chance of breaking anything.

If you aren't too familiar with git, please see our guide: Creating pull requests.

Developer Reference

Check the sidebar for a full list of reference documents for SuperCollider development. Here are a few that are particularly good for new contributors. You don't need to read and understand all of this before contributing! We are happy to help guide you through your first contributions. If you run into confusion or need help, you are always welcome to ask.