Updated Drupal to 8.6. This goes with the following updates because it's possible...
[yaffs-website] / vendor / drush / drush / CONTRIBUTING.md
index e9da6e65f4cd911ae3eb11979af32638f8a83240..6484552700cfa29f1c244760b5666000e45f1fd4 100644 (file)
@@ -1,17 +1,19 @@
 Drush is built by people like you! Please [join us](https://github.com/drush-ops/drush).
 
 ## Git and Pull requests
-* Contributions are submitted, reviewed, and accepted using GitHub pull requests. [Read this article](https://help.github.com/articles/using-pull-requests) for some details. We use the _Fork and Pull_ model, as described there.
+* Contributions are submitted, reviewed, and accepted using GitHub pull requests.
 * The latest changes are in the `master` branch. PR's should initially target this branch.
 * Try to make clean commits that are easily readable (including descriptive commit messages!)
-* Test before you push. Get familiar with Unish, our test suite. See the test-specific [README.md](tests/README.md)
+* Test before you push. Get familiar with Unish, our test suite. See the test-specific [README.md](tests/README.md). Optionally run tests in the provided Docker containers.
 * We maintain branches named 9.x, 8.x, etc. These are release branches. From these branches, we make new tags for patch and minor versions.
 
+## Development Environment
+* You may choose to use the docker-compose file in root directory for an optimized environment.
+* See `composer run-script -l` for a list of helper scripts.
+
 ## Coding style
 * Do write comments. You don't have to comment every line, but if you come up with something thats a bit complex/weird, just leave a comment. Bear in mind that you will probably leave the project at some point and that other people will read your code. Undocumented huge amounts of code are nearly worthless!
 * We use [PSR-2](http://www.php-fig.org/psr/psr-2/) in the /src directory. [Drupal's coding standards](https://drupal.org/coding-standards) are still used in the includes directory (deprecated code).
-* Don't overengineer. Don't try to solve any possible problem in one step, but try to solve problems as easy as possible and improve the solution over time!
-* Do generalize sooner or later! (if an old solution, quickly hacked together, poses more problems than it solves today, refactor it!)
 * Keep it compatible. Do not introduce changes to the public API, or configurations too casually. Don't make incompatible changes without good reasons!
 
 ## Documentation