Welcome! First off; THANK YOU for your interest in contributing to Shithole! We know that your time is valuable; so let's get started!
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
- Contributors must comply with our code of conduct.
- Contributors must assign ownership of their contributions to Zinc Technology Inc (ZTI).
- Contributors must not commit directly to the
developmentorproductionbranches. - Contributors should ask for help when they get stuck.
- Contributors may build on top of other Contributors unmerged branches.
- Maintainers must comply with our code of conduct.
- Maintainers must perform regression testing prior to release.
- Maintainers must ensure that all feedback provided to Contributors is specific, actionable, and kind.
- Maintainers must not erase authorship information from any Contributors.
- Maintainers should acknowledge Contributors issues and patches within two weeks of submission.
We need to create a more formal responsible security disclosure process; but in the meantime, we strongly encourage people with security concerns to create a ticket explaining their concerns. If the concern is a vulnerability in a released version of compensated; please email the maintainers.
Because Compensated is very early alpha software, it's light on documentation. If you are trying to figure something out or have a question we would love for you to open a ticket requesting documentation improvements.
If you have an idea for what that documentation would look like, you can use the built in GitHub editor to suggest a change using a pull request!
We consider any gaps between what you expected Shithole to do and what it actually did to be a bug. It makes it easier for us to fix things when bug reports clearly express what was expected and what actually happened.
But don't let that stop you! We'd prefer to hear about what was surprising even if you can't reproduce it or would like help to figure out how to communicate the issue effectively.
If you notice something weird when working in Shithole; please open a ticket in our issue tracker. We'll do our best to prioritize fixing bugs over adding features.
If you want to try squashing it yourself; we encourage you to review the development workflow.
We are happy to continue building Shithole in the direction our current clients and projects need it to; but we'd love to hear what you wish it would do! To make a feature request, create an issue in our issue tracker.
You can also take a stab at implementing the feature yourself! If you do, we encourage you to create a pull request as soon as you get started, even if it's not working yet! This makes it easier to see what is in flight, and gives you the ability ask for help by mentioning @zspencer. We'll happily work with you to get it refined and merged in!
We have two vectors for getting help; one is through opening a ticket in our issue tracker, where we will do our best to provide support in a timely manner.
For businesses with greater support needs, we offer professional support at $250USD per hour. Support may be scheduled by emailing hello@zincma.de.
The development guide is a work in progress, and is intended to serve as a starting point for people who would like to directly modify Shithole to fix a bug or enhance a feature.
If you have an idea of what change you would like to make, start learning the system. If you are already comfortable with Shithole's product design and architecture, you can start working on the change. For everyone else, let's find something to do!
Look at the open tickets in our issue tracker. Items labeled “Help Wanted” are where we would appreciate some help. Items labeled “Good First Issue” are where we think new contributors would be able to chip in effectively. If there aren't any labeled with these two things; feel free to pick something else!
Now that you've got something to do,
Once you've found something to do, you'll want to clone the repository and review the product design and architecture documentation to develop a firmer grasp of the underlying mental models.
Review the dependencies that require manual installation and install them.
Run bin/setupfrom the project root directory or from a module specific
directory to install dependencies which can be automatically installed.
If that doesn't work, read the source of bin/setup and the nearest README and
try again to get it working. Failing that, ask for help
We encourage people to start off by writing a test that demonstrates the bug they are attempting to fix or the use case they want to add.
Run tests with bin/test from the project root directory or from a module
specific directory.
Ideally, there are at least two tests, a “unit” test and a “system”
test. If you are struggling to write tests, that is OK!
You can find examples of unit tests in the spec/unit folder. Our system tests
are written in cucumber and live in features folder. If you are still stuck,
you can always ask for help.
Once you have a test that help you feel confident you will know that the change you made has the impact you want, dive on in to writing code! Reviewing the architecture documentation and the nearest README should get you headed in the right direction. If not, ask for help!
We encourage contributors to create a pull request early, even if the work isn't 'done' as this is the easiest way to get the best help. This also makes it possible for other Contributors to build on top of the work you've already done, instead of needing to reinvent the wheel.
We encourage Contributors to follow a branch naming schema like for bugs that
looks something like fix/apple-iap/<words-describing-fix>; and for features
looks something like enhance/stripe/<words-describing-improvement>. However,
feel free to name your branches in the way that feels most comfortable to you.
Shithole uses a proprietary license for commercial use. This ensures we can maintain the library and related services over the long haul, as well as gives us the right to refuse to license to organizations who we do not want to benefit from our labor.
In order to unambiguously own and sell Shithole as a commercial product, ZTI must have the copyright associated with the entire project. Any intellectual property you create which is merged must be owned by ZTI. We're not trying to be a jerk, just trying to cover our asses. (Phrasing shamelessly lifted from SideKiq Pro's Commercial Collaboration Guide)
Before we can merge patches, we will need you to grant us all rights to the work you perform on Shithole to ZTI. You can do this by sending “I assign all rights, including copyright, to any future Shithole work by myself to Zinc Technology Inc” to the maintainer or as a comment on your patch.