Notes on 3rd party dependencies

docs/developers.md

@@ -54,6 +54,14 @@ workflow for doing this is as follows:
 5. When you are ready for us to review, push your branch to GitHub, and
    then open a new pull request with us.
 
+### Third Party Dependencies
+
+Third party dependencies reside locally inside the repository under the `vendor/` directory. We use [glide](https://github.com/Masterminds/glide) to enforce our dependency graph, declared in [glide.yaml](https://github.com/Azure/acs-engine/blob/master/CONTRIBUTING.md) in the project root.
+
+If you wish to introduce a new third party dependency into `acs-engine`, please file an [issue](https://github.com/Azure/acs-engine/issues), and include the canonical VCS path (e.g., `github.com/Azure/azure-sdk-for-go`) along with either the desired release string expression to depend on (e.g., `~8.1.0`), or the commit hash to pin to a static commit (e.g., `4cdb38c072b86bf795d2c81de50784d9fdd6eb77`). A project maintainer will then own the effort to update the codebase with that dependency, including relevant updates to `glide.yaml` and `vendor/`.
+
+As a rule we want to distinguish dependency update PRs from feature/bug PRs; we may ask that feature/bug PRs which include updates to `vendor/` and/or contain any other dependency-related overhead to be triaged into separate PRs that can be managed independently, pre-requisite dependency changes in one, and features/bugs in another. The objective of enforcing these distinctions is to help focus the PR review process, and to make manageable the difficult task of rationalizing a multitude of parallel PRs in flight, many of which which may carry hard-to-reconcile dependency side-effects when aggressively updated with a fresh dependency graph as part of the PR payload.
+
 ### Go Conventions
 
 We follow the Go coding style standards very closely. Typically, running