adds development and contribution guidelines

Author: aoberoi

CONTRIBUTING.md

@@ -0,0 +1,47 @@
+# Contributing Guidelines
+
+For anyone looking to get involved to this project, we are glad to hear from you. Here are a few types of contributions
+that we would be interested in hearing about.
+
+*  Bug fixes
+    -  If you find a bug, please first report it using Github Issues.
+    -  Issues that have already been identified as a bug will be labelled `bug`.
+    -  If you'd like to submit a fix for a bug, send a Pull Request from your own fork and mention the Issue number.
+        +  Include a test that isolates the bug and verifies that it was fixed.
+*  New Features
+    -  If you'd like to accomplish something in the library that it doesn't already do, describe the problem in a new
+       Github Issue.
+    -  Issues that have been identified as a feature request will be labelled `enhancement`.
+    -  If you'd like to implement the new feature, please wait for feedback from the project maintainers before spending
+       too much time writing the code. In some cases, `enhancement`s may not align well with the project objectives at
+       the time.
+*  Tests, Documentation, Miscellaneous
+    -  If you think the test coverage could be improved, the documentation could be clearer, you've got an alternative
+       implementation of something that may have more advantages, or any other change we would still be glad hear about
+       it.
+       -  If its a trivial change, go ahead and send a Pull Request with the changes you have in mind
+       -  If not, open a Github Issue to discuss the idea first.
+
+## Requirements
+
+For a contribution to be accepted:
+
+*  The test suite must be complete and pass
+*  Code must follow existing styling conventions
+*  Commit messages must be descriptive. Related issues should be mentioned by number.
+
+If the contribution doesn't meet these criteria, a maintainer will discuss it with you on the Issue. You can still
+continue to add more commits to the branch you have sent the Pull Request from.
+
+## How To
+
+1. Fork this repository on GitHub.
+1. Clone/fetch your fork to your local development machine.
+1. Create a new branch (e.g. `issue-12`, `feat.add_foo`, etc) and check it out.
+1. Make your changes and commit them. (Did the tests pass?)
+1. Push your new branch to your fork. (e.g. `git push myname issue-12`)
+1. Open a Pull Request from your new branch to the original fork's `master` branch.
+
+## Developer Guidelines
+
+See DEVELOPING.md for guidelines for developing this project.

DEVELOPING.md

@@ -0,0 +1,76 @@
+# Development Guidelines
+
+This document describes tools, tasks and workflow that one needs to be familiar with in order to effectively maintain
+this project. If you use this package within your own software as is but don't plan on modifying it, this guide is
+**not** for you.
+
+## Tools
+
+*  [Phing](http://www.phing.info/): used to run predefined tasks. Installed via Composer into the vendor directory. You
+   can run phing but using the command line script `./vendor/bin/phing` or you can put it on your PATH.
+*  [Composer](https://getcomposer.org/): used to manage dependencies for the project.
+
+## Tasks
+
+### Testing
+
+This project's tests are written as PHPUnit test cases. Common tasks:
+
+*  `./vendor/bin/phing test` - run the test suite.
+
+### Releasing
+
+In order to create a release, the following should be completed in order.
+
+1. Ensure all the tests are passing (`./vendor/bin/phing test`) and that there is enough test coverage.
+1. Make sure you are on the `master` branch of the repository, with all changes merged/commited already.
+1. Update the version number in the source code and the README. See [Versioning](#versioning) for information
+   about selecting an appropriate version number. Files to change:
+   - src/OpenTok/Util/Client.php
+   - sample/HelloWorld/composer.json
+   - sample/Archiving/composer.json
+   - README.md
+1. Commit the version number change with the message "Update to version x.x.x", substituting the new version number.
+1. Create a git tag: `git tag -a vx.x.x -m "Release vx.x.x"`
+1. Change the version number for future development by adding "-alpha.1" in each file, then make another commit with the
+   message "Begin development on next version".
+1. Push the changes to the source repository: `git push origin master`
+1. Create a zip for uploading the release to Github Releases
+
+## Workflow
+
+### Versioning
+
+The project uses [semantic versioning](http://semver.org/) as a policy for incrementing version numbers. For planned
+work that will go into a future version, there should be a Milestone created in the Github Issues named with the version
+number (e.g. "v2.2.1").
+
+During development the version number should end in "-alpha.x" or "-beta.x", where x is an increasing number starting from 1.
+
+### Branches
+
+*  `master` - the main development branch.
+*  `feat.foo` - feature branches. these are used for longer running tasks that cannot be accomplished in one commit.
+   once merged into master, these branches should be deleted.
+*  `vx.x.x` - if development for a future version/milestone has begun while master is working towards a sooner
+   release, this is the naming scheme for that branch. once merged into master, these branches should be deleted.
+
+### Tags
+
+*  `vx.x.x` - commits are tagged with a final version number during release.
+
+### Issues
+
+Issues are labelled to help track their progress within the pipeline.
+
+*  no label - these issues have not been triaged.
+*  `bug` - confirmed bug. aim to have a test case that reproduces the defect.
+*  `enhancement` - contains details/discussion of a new feature. it may not yet be approved or placed into a
+   release/milestone.
+*  `wontfix` - closed issues that were never addressed.
+*  `duplicate` - closed issue that is the same to another referenced issue.
+*  `question` - purely for discussion
+
+### Management
+
+When in doubt, find the maintainers and ask.

README.md

@@ -9,7 +9,9 @@ applications, and [archive](http://tokbox.com/#archiving) OpenTok 2.0 sessions.
 If you are updating from a previous version of this SDK, see
 [Important changes in v2.2](#important-changes-in-v22).
 
-# Installation with Composer (recommended):
+# Installation
+
+## Composer (recommended):
 
 Composer helps manage dependencies for PHP projects. Find more info here: <http://getcomposer.org>
 
@@ -20,6 +22,15 @@ command line:
 $ composer require opentok/opentok 2.2.x
 ```
 
+## Manually:
+
+Download the zip file for the latest release from the [Releases](https://github.com/opentok/opentok-php-sdk/releases)
+page. Unzip the file and place it into your project directory. If you have a
+[PSR-4](http://www.php-fig.org/psr/psr-4/) compliant loader, you should place the unzipped directory
+into a place your loader can find it. Otherwise, place it in the
+[include_path](http://www.php.net/manual/en/ini.core.php#ini.include-path) and include or require
+the files as necessary.
+
 # Usage
 
 ## Initializing
@@ -192,10 +203,8 @@ docs directory of the SDK.
 
 # Development and Contributing
 
-Interested in contributing? We <3 pull requests! File a new
-[Issue](https://github.com/opentok/opentok-php-sdk/issues) or take a look at the existing ones. If
-you are going to send us a pull request, please try to run the test suite first and also include
-tests for your changes.
+Interested in contributing? We :heart: pull requests! See the [Development](DEVELOPING.md) and
+[Contribution](CONTRIBUTING.md) guidelines.
 
 # Support