Commit 9d3efdf0 authored by Mike Ryan's avatar Mike Ryan

#51: Expand community documentation and move to docs directory.

parent cc67dd9e
# Contributing
Contributions are **welcome** and will be fully **credited**.
We accept contributions via Pull Requests on [Gitlab](https://gitlab.com/soong/soong).
## Pull Requests
- **[PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md)** - Check the code style with ``$ composer check-style`` and fix it with ``$ composer fix-style``.
- **Add tests!** - Your patch won't be accepted if it doesn't have tests.
- **Document any change in behaviour** - Make sure the `README.md`, `CHANGELOG.md`, and any other relevant documentation are kept up-to-date.
- **Consider our release cycle** - We try to follow [SemVer v2.0.0](http://semver.org/). Randomly breaking public APIs is not an option.
- **Create feature branches** - Don't ask us to pull from your master branch.
- **One pull request per feature** - If you want to do more than one thing, send multiple pull requests.
- **Send coherent history** - Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
## Running Tests
``` bash
$ composer test
```
**Happy coding**!
<!-- Provide a general summary of the issue in the Title above -->
## Detailed description
Provide a detailed description of the change or addition you are proposing.
Make it clear if the issue is a bug, an enhancement or just a question.
## Context
Why is this change important to you? How would you use it?
How can it benefit other users?
## Possible implementation
Not obligatory, but suggest an idea for implementing addition or change.
## Your environment
Include as many relevant details about the environment you experienced the bug in and how to reproduce it.
* Version used (e.g. PHP 7.1, HHVM 3):
* Operating system and version (e.g. Ubuntu 16.04, Windows 7):
* Link to your project:
* ...
* ...
<!--- Provide a general summary of your changes in the Title above -->
## Description
Describe your changes in detail.
## Motivation and context
Why is this change required? What problem does it solve?
If it fixes an open issue, please link to the issue here (if you write `fixes #num`
or `closes #num`, the issue will be automatically closed when the pull is accepted.)
## How has this been tested?
Please describe in detail how you tested your changes.
Include details of your testing environment, and the tests you ran to
see how your change affects other areas of the code, etc.
## Screenshots (if appropriate)
## Types of changes
What types of changes does your code introduce? Put an `x` in all the boxes that apply:
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
## Checklist:
Go over all the following points, and put an `x` in all the boxes that apply.
Please, please, please, don't send your pull request until all of the boxes are ticked. Once your pull request is created, it will trigger a build on our [continuous integration](http://www.phptherightway.com/#continuous-integration) server to make sure your [tests and code style pass](https://help.github.com/articles/about-required-status-checks/).
- [ ] I have read the **[CONTRIBUTING](CONTRIBUTING.md)** document.
- [ ] My pull request addresses exactly one patch/feature.
- [ ] I have created a branch for this patch/feature.
- [ ] Each individual commit in the pull request is meaningful.
- [ ] I have added tests to cover my changes.
- [ ] If my change requires a change to the documentation, I have updated it accordingly.
If you're unsure about any of these, don't hesitate to ask. We're here to help!
# Contributing
Contributions are **welcome** and will be fully **credited**.
We accept contributions via issues and merge requests at [Gitlab](https://gitlab.com/soong/soong).
## Submission process
1. See if there are any existing relevant issues in [the Gitlab repo](https://gitlab.com/soongetl/soong/issues). If not, [open a new issue](https://gitlab.com/soongetl/soong/issues/new).
1. If you are going to work on a solution to the issue, assign the issue to yourself.
1. Fork the project and create a feature branch in your fork.
1. Develop your solution locally. Be sure to:
- Make sure your changes are fully tested.
- Make sure your changes are fully documented, including in code comments blocks, README.md, CHANGELOG.md, and in the `docs` directory.
- Follow the [PSR-2 Coding Standard](https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md). Check the code style with ``$ composer check-style`` and fix it with ``$ composer fix-style``.
1. Make sure each individual commit in your pull request is meaningful. If you had to make multiple intermediate commits while developing, please [squash them](http://www.git-scm.com/book/en/v2/Git-Tools-Rewriting-History#Changing-Multiple-Commit-Messages) before submitting.
1. Commits should reference the issue number - e.g., a commit for [Add community docs up front](https://gitlab.com/soongetl/soong/issues/51) might have the commit message "#51: Expand community documentation and move to docs directory.".
## Running Tests
``` bash
$ composer test
```
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment