|
|
|
@@ -1,26 +1,28 @@ |
|
|
|
|
|
|
|
### Pre-implementation |
|
|
|
|
|
|
|
Before authoring a code contribution, open an issue explaining your proposal in detail. |
|
|
|
Remember that code is easy to write, but inventing a valid design is usually the crux. |
|
|
|
Expect the proposal to be rejected if you do not consider 100% of use-cases and corner cases. |
|
|
|
|
|
|
|
### Code style and quality |
|
|
|
|
|
|
|
Be courteous and try to match the code style. |
|
|
|
I won't define the exact style here, so just follow the existing code. |
|
|
|
|
|
|
|
Use C++11 style, not >=C++14 or C. |
|
|
|
This means using the `std::` namespace for stdlib symbols, `std::string` instead of `char*`, `//` comments and `/** */` docstrings, etc. |
|
|
|
Avoid over-engineered things like `iostream`, `std::array`, `std::unique_ptr`, etc when simpler alternatives exist. |
|
|
|
|
|
|
|
Write maintainable code that will last >4 years. |
|
|
|
No feature/bug is urgent enough to write dirty/temporary implementations. |
|
|
|
I have no need to withdraw technical debt. |
|
|
|
|
|
|
|
### Legal |
|
|
|
|
|
|
|
Because a proprietary fork of VCV Rack is planned by VCV (*Rack for DAWs*), in order for your patch to be accepted, you must make a declaration stating that: |
|
|
|
- you are the sole author of your patch. |
|
|
|
- your patch is released under the [CC0](https://creativecommons.org/publicdomain/zero/1.0/) license. |
|
|
|
- or ask for a copyright reassignment form if you prefer this instead. |
|
|
|
VCV Rack is [open-source](https://opensource.org/osd) but not [open-contribution](https://opensource.guide/how-to-contribute/). |
|
|
|
I am unable to accept free code contributions to Rack for the following reasons. |
|
|
|
- **Quality.** |
|
|
|
Most contributions to open-source projects typically only contain code, but writing code is just a small percentage of the effort required to maintain a large software project. |
|
|
|
Additional tasks for fully supporting a feature include |
|
|
|
- debating the best design before any code is written |
|
|
|
- considering all use cases and corner cases of the implementation |
|
|
|
- generalizability to allow other features to be built on top if needed |
|
|
|
- testing across all supported operating systems and hardware |
|
|
|
- dedication to support the feature for >4 years |
|
|
|
- **Time.** |
|
|
|
In the past, free code contributions have cost far more time to review, iterate, fix, and test than writing the implementation from scratch. |
|
|
|
There have been exceptions to this, but they are rare. |
|
|
|
- **Legal.** |
|
|
|
A proprietary fork of VCV Rack is planned (see [*Rack for DAWs*](https://vcvrack.com/manual/FAQ.html#is-vcv-rack-available-as-a-vst-au-aax-plugin-for-daws)), so VCV must own all GPLv3 code. |
|
|
|
To accept a contribution, all authors of the contribution need to either |
|
|
|
- declare the patch under the [CC0](https://creativecommons.org/publicdomain/zero/1.0/) license. |
|
|
|
- complete a copyright reassignment form. |
|
|
|
- perform the work under a paid agreement. |
|
|
|
|
|
|
|
Except in exceptional circumstances, contributions are only accepted as paid work under detailed guidelines. |
|
|
|
|
|
|
|
However there are several areas you may contribute Rack project. |
|
|
|
- [creating high-quality issues](https://vcvrack.com/manual/FAQ.html#i-found-a-bug) |
|
|
|
- responding to [issues](https://github.com/VCVRack/Rack/issues) and answering questions in the [VCV communities](https://vcvrack.com/manual/Communities.html) |
|
|
|
- [developing and maintaining your own plugins](https://vcvrack.com/manual/PluginDevelopmentTutorial.html) |
|
|
|
- contributing to Rack's open-source dependencies, like [GLFW](https://www.glfw.org/), [nanovg](https://github.com/memononen/nanovg), [RtAudio](https://www.music.mcgill.ca/~gary/rtaudio/), and [RtMidi](https://www.music.mcgill.ca/~gary/rtmidi/). |
Andrew Belt