Browse Source

Rewrite CONTRIBUTING. Tweak issue templates.

Andrew Belt 4 years ago
3 changed files with 30 additions and 26 deletions
  1. +27
  2. +2
  3. +1

+ 27
- 25
.github/ View File

@@ -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]( license.
- or ask for a copyright reassignment form if you prefer this instead.
VCV Rack is [open-source]( but not [open-contribution](
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*](, 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]( 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](
- responding to [issues]( and answering questions in the [VCV communities](
- [developing and maintaining your own plugins](
- contributing to Rack's open-source dependencies, like [GLFW](, [nanovg](, [RtAudio](, and [RtMidi](

+ 2
- 1
.github/ISSUE_TEMPLATE/ View File

@@ -5,10 +5,11 @@ about: Bugs, build errors, compatibility/stability issues

Search existing issues before posting a new one to avoid duplicates.
To file a bug report, fill out the form below.
Use a descriptive title that best explains the bug in one sentence.
Attach screenshots if the bug is visual.
Attach your `<Rack user folder>/log.txt` file if Rack is crashing.
If Rack crashed, attach/upload (don't copy/paste) your `<Rack user folder>/log.txt` file.
Surround terminal output with three tildes
like this.

+ 1
- 0
.github/ISSUE_TEMPLATE/ View File

@@ -5,6 +5,7 @@ about: Feature ideas, design proposals

Search existing issues before posting a new one to avoid duplicates.
To request a feature, fill out the form below.
Use a descriptive title that best explains the feature request in one sentence.