Skip to content

5. Contribution Guidelines

Andrew Ikenberry edited this page Mar 2, 2021 · 1 revision

Thanks in advance for your interest in contributing!

While any contributions are welcome, we do layout a few guidelines and requirements for contribution to help make the process as clean and easy to maintain as possible.

Contributing

There are several facets of Daisy that can be contributed to.

Modules

The most obvious would be adding DSP modules, or fixing bugs in existing ones.

When adding a new module, please reference an existing module as well as the style guide to stay consistent with the rest of the library.

Examples

The examples/ folder should have one example for each module in modules/

Here's what a module example should do:

  • make sound by itself without external audio (when possible).
  • be simple, well commented, and effective at illustrating the purpose of the module.
  • if the module is most-noticeable when a parameter is moving you can use the phasor, metro, or line objects to change them.
  • use as few additional modules as possible while accomplishing the above so that the example remains clear and concise.

Documentation

Most of the existing documentation is inline with the code.

We use a simple python script that parses header files, and converts this to markdown.

It's easiest to maintain, and write the documentation while adding or modifying an existing module. However, you may find errors, or typos within the PDF documentation. Fixing these is as easy as editing the header file for the corresponding module.

Additionally, we'll be wanting to add tutorials, guides, and more generic usage documentation to complement the generated reference docs. So we welcome any contributions in that department!

Commits

Commits should be atomic so that parallel work across the repository can continue uninterrupted as things get added/fixed.

Keep the commit messages as concise as possible while still being descriptive.

Pull Requests

Keep the title short and descriptive.

The description can be longer, and should contain:

  • what was changed
  • why the change was necessary
  • any side-effects that may come from the change

When a lot of people are working on the same files at once, Pull Requests can go stale quickly. Before merging a stale pull request, your branch will have to be rebased so that it is up to date with the current master before it can be merged.