Skip to content

Contribution Guidelines

John Waiton edited this page Feb 18, 2026 · 4 revisions

Fixing Issues

If you wish to address an issue or have found an issue yourself, this short explainer will detail the steps you should take to resolve it.

Create/Assign yourself an Issue

In the Issues tab, you can either create an issue or assign yourself to an already existing one.

Make your changes

After choosing an issue, you should create a new branch on your own MULE fork* and develop the changes you want to make there. The standard practice for your commits are:

Make them short

In code and in message, its better to have short frequent commits that describe individual logic changes. On the other hand, don't commit things line by line.

Make them imperative

You're telling the code what to do: alter the default config, remove unneeded variables in file.txt, etc

If you need more text...

Add a commit description, these don't clog up the commit history, but allow for you to extrapolate what you've done. An example:

image

Create a pull request

After choosing and resolving an issue, you create a new branch on your own MULE fork*, resolve the issue and open a pull request (PR). This request should detail the changes you made.

The pull request should detail the changes you made, and your commits should detail the code history in an easy to follow manner. This isn't always easy, but it makes it easier for reviewers to review!

Examples of prior pull requests can be seen here.

Respond to comments

Your code will be reviewed by a reviewer from the nu-ZOO, who will provide comments and suggestions to make the code better before approving it to be merged into MULE.

Merging into MULE

Once approved, the code needs to be rebased and then merged by a member with permissions to do so. At this point, congratulations! You've contributed to MULE and made the repository a better place! 🥳

Contributing Features

New features will be held to a higher level of scrutiny with respect to MULE's intended purpose. While an MP3 player version of your waveforms would be cool, it may not be the most beneficial addition! Otherwise, the path for including new features into MULE follows the same path as fixing issues.


*github jargon for: create a copy of the code that has a tag of 'fixing this issue', there are many good guides online for how to do this