Master updated upstream

.babelrc

@@ -1,4 +1,19 @@
 {
-	"presets": ["es2015"],
-	"plugins": ["transform-object-assign", "transform-es3-property-literals", "transform-es3-member-expression-literals"]
+	"presets": [
+		["env", {
+			"targets": {
+				"browsers": [
+					"chrome >= 61", 
+					"safari >=8", 
+					"edge >= 14", 
+					"ff >= 57", 
+					"ie >= 10",
+					"ios >= 8"
+				]
+			}
+		}]
+	],
+	"plugins": [
+		"transform-object-assign"
+	]
 }

.eslintrc.js

@@ -3,6 +3,13 @@ module.exports = {
     "browser": true,
     "commonjs": true
   },
+  "settings": {
+    "import/resolver": {
+      "node": {
+        "moduleDirectory": ["node_modules", "./"]
+      }
+    }
+  },
   "extends": "standard",
   "globals": {
     "$$PREBID_GLOBAL$$": false
@@ -21,12 +28,9 @@ module.exports = {
     // See Issue #1111.
     "camelcase": "off",
     "eqeqeq": "off",
-    "no-control-regex": "off",
     "no-return-assign": "off",
     "no-throw-literal": "off",
     "no-undef": "off",
-    "no-use-before-define": "off",
     "no-useless-escape": "off",
-    "standard/no-callback-literal": "off",
   }
 };

.github/PULL_REQUEST_TEMPLATE.md

@@ -11,6 +11,7 @@ Thank you for your pull request. Please make sure this PR is scoped to one chang
 - [ ] Refactoring (no functional changes, no api changes)
 - [ ] Build related changes
 - [ ] CI related changes
+- [ ] Does this change affect user-facing APIs or examples documented on http://prebid.org?
 - [ ] Other
 
 ## Description of change
@@ -32,6 +33,9 @@ Be sure to test the integration with your adserver using the [Hello World](/inte
 - contact email of the adapter’s maintainer
 - [ ] official adapter submission
 
+For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:
+
+- A link to a PR on the docs repo at https://github.com/prebid/prebid.github.io/
 
 ## Other information
 <!-- References to related PR or issue #s, @mentions of the person or team responsible for reviewing changes, etc. -->

.github/stale.yml

@@ -0,0 +1,19 @@
+# Number of days of inactivity before an issue becomes stale
+daysUntilStale: 14
+# Number of days of inactivity before a stale issue is closed
+daysUntilClose: 7
+# Issues with these labels will never be considered stale
+exemptLabels:
+  - pinned
+  - security
+  - bug
+  - feature
+# Label to use when marking an issue as stale
+staleLabel: stale
+# Comment to post when marking an issue as stale. Set to `false` to disable
+markComment: >
+  This issue has been automatically marked as stale because it has not had
+  recent activity. It will be closed if no further activity occurs. Thank you
+  for your contributions.
+# Comment to post when closing a stale issue. Set to `false` to disable
+closeComment: false

.travis.yml

@@ -1,17 +1,28 @@
+sudo: required
 dist: trusty
-
 language: node_js
-
 node_js:
-  - "7.0"
-
-# See https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-the-Chrome-addon-in-the-headless-mode
+- '7.0'
+env:
+- BROWSERSTACK_USERNAME=info184
 addons:
-  chrome: stable
-
+  chrome: stable,
+  browserstack:
+    username: info184
+    access_key:
+      secure: Ru286R4pMcEIRKwb2AoaaJY6lEKIzeZraxY7CtbOP4ykNk7uqsnyitk4QwxpCCh0n35b71m30okW6ZmZnl0lJXhOMdYoSOYBAnUw2Vn7Y93oMSKIC5dc2/qmtF1t2b1qX65/Ont2iJUj+UY8VQw5Hk2vIT4/5wifYPBnV5ILK4AI7SVk/ma7OzK4rkp3WThlouddctAd7tx4O3YIyJKDi9lkfcMA0pnH4OZSOlDClRLIy50Q1NE+iyqHtWFZK1TwJ+IhQbSsCLbuyQJBRnyJJEftNmtrs5MCZt/9pwFDj7c8+o11F6HCsTBYFkehFRfbKnmhCc1G+bsNXY8OxIWwEHeuVmSGK7TDPYcPPQBc03mcQ1fY/IPNQOdsVJ/n8RsG2u0IU2CF2hhkuNFzeov7dOHljanc45NKOrLdjwzP1aZCAUvLquOTzvmdF23nJhMs8UO+Du4kTK5VfmKyz1MC91E40a0Q15+O4qmS39rNOlwhxPJSfuxxL1jKVPJ7PsFbTkGM8M/XPJ6dyGLufy225HjdLdJTAOa5BZ4st+nXH/AzqHzy6a2I5vTmAz1j4gHLgVU+iNxAkX8znb25s3Rs1ZuFVj+aBSBmNoQA1FA5f/uXWeruTdDig7ksp+XdjsjLm9Md8cWwYaEn04FYj1ztJrylrEMfnc0Kcs6zQ3fll1g=
 before_install:
-  - npm install -g gulp
-  - google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &
-
-script:
-  - gulp run-tests
+- npm install -g gulp
+- google-chrome-stable --headless --disable-gpu --remote-debugging-port=9222 http://localhost &
+script: |-
+  if [[ ${TRAVIS_PULL_REQUEST} == "false" ]]; then
+    gulp test --browserstack
+  else
+    gulp run-tests
+  fi
+notifications:
+  slack:
+    on_success: never
+    on_failure: always
+    on_pull_requests: false
+    secure: C4O77VtABLE5DiPDeKGqUcsBdTBMNjQRLc8iBfSp231e95K1rA/JXJJEQN/lVhhiFJyPhxueE0i6cR0zD8uAMC8HRShGGfPjEZ7f6glawPzap2wFwjAyVkknYV+BMKcX0jvn7CiSKBj+zTbHQfn/Uj3nMSbDZQIdbNDiFGh4NuDr3/Yd/efhsw/miExlSPSWqGVCKV3WPpTrU3BRpLNDq4sZMXP9ORZxGK7ER3tsMiD2z05YpvC+mibESJxaY0qsuQu1y1Gu65QLPe5ocw405btJwqYn+b4YFpUd2GbLNhjtLzsc+OKrD0DWuEI0bxePQUYDga5wR6g4cdZaXU3ixDjee7sJbDeVJAuykGlfZ4A1k+fQIgPs3s9XMHaeG9AfDhFiZ/UoNdonzos1iSa/Y1TzHIXp1wnbHKT5HUWWPFNb5PzJxHEtHbm3jwOH4iK8VAq94ec16M2aqUAj7muiqcrTlYa5rs6jRlXo/TRymFnbQRdBT7eLmLNDQD35yR1Y+4mxHqKi+3189yG9RE+uwIlB+9HZFgNbioOApB+jarKC6M0qEgn0bHxkpJBP8JmNCA84U0ZUzyPvuMGsRbisAmKoUsU8C6cq59QDfBTcCTvKXK6r+6f23iRGieoGSbTxYQj46QkykpbWU0WstQDQsZL3L316uZecOVZmWKBRxPs=

CONTRIBUTING.md

@@ -48,9 +48,6 @@ When you are adding code to Prebid.js, or modifying code that isn't covered by a
   - _Assert_: check that the expected results have occurred
     - e.g., use Chai assertions to check that the expected output is equal to the actual output
 - Test the public interface, not the internal implementation
-- If using global `pbjs` data structures in your test, take care to not completely overwrite them with your own data as that may affect other tests relying on those structures, e.g.:
-    - **OK**: `pbjs._bidsRequested.push(bidderRequestObject);`
-    - **NOT OK**: `pbjs._bidsRequested = [bidderRequestObject];`
 - If you need to check `adloader.loadScript` in a test, use a `stub` rather than a `spy`. `spy`s trigger a network call which can result in a `script error` and cause unrelated unit tests to fail. `stub`s will let you gather information about the `adloader.loadScript` call without affecting external resources
 - When writing tests you may use ES2015 syntax if desired
 

LICENSE

@@ -176,18 +176,7 @@
 
    END OF TERMS AND CONDITIONS
 
-   APPENDIX: How to apply the Apache License to your work.
-
-      To apply the Apache License to your work, attach the following
-      boilerplate notice, with the fields enclosed by brackets "[]"
-      replaced with your own identifying information. (Don't include
-      the brackets!)  The text should be enclosed in the appropriate
-      comment syntax for the file format. We also recommend that a
-      file or class name and description of purpose be included on the
-      same "printed page" as the copyright notice for easier
-      identification within third-party archives.
-
-   Copyright 2013 APPNEXUS INC
+   Copyright 2017 PREBID.ORG, INC
 
    Licensed under the Apache License, Version 2.0 (the "License");
    you may not use this file except in compliance with the License.
@@ -199,4 +188,4 @@
    distributed under the License is distributed on an "AS IS" BASIS,
    WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
    See the License for the specific language governing permissions and
-   limitations under the License.
+   limitations under the License.

PR_REVIEW.md

@@ -0,0 +1,48 @@
+## Summary
+We take PR review seriously. Please read https://medium.com/@mrjoelkemp/giving-better-code-reviews-16109e0fdd36#.xa8lc4i23 to understand how a PR review should be conducted. Be rational and strict in your review, make sure you understand exactly what the submitter's intent is. Anyone in the community can review a PR, but a Prebid Org member is also required. A Prebid Org member should take ownership of a PR and do the initial review.
+
+If the PR is for a standard bid adapter or a standard analytics adapter, just the one review from a core member is sufficient. The reviewer will check against [required conventions](http://prebid.org/dev-docs/bidder-adaptor.html#required-adapter-conventions) and may merge the PR after approving and confirming that the documentation PR against prebid.org is open and linked to the issue.
+
+For modules and core platform updates, the initial reviewer should request an additional team member to review as a sanity check. Merge should only happen when the PR has 2 `LGTM` from the core team and a documentation PR if required.
+
+### General PR review Process
+- Checkout the branch (these instructions are available on the github PR page as well).
+- Verify PR is a single change type. Example, refactor OR bugfix. If more than 1 type, ask submitter to break out requests.
+- Verify code under review has at least 80% unit test coverage. If legacy code has no unit test coverage, ask for unit tests to be included in the PR.
+- Verify tests are green in Travis-ci + local build by running `gulp serve` | `gulp test`
+- Verify no code quality violations are present from linting (should be reported in terminal)
+- Review for obvious errors or bad coding practice / use best judgement here.
+- If the change is a new feature / change to core prebid.js - review the change with a Tech Lead on the project and make sure they agree with the nature of change.
+- If the change results in needing updates to docs (such as public API change, module interface etc), add a label for "needs docs" and inform the submitter they must submit a docs PR to update the appropriate area of Prebid.org **before the PR can merge**. Help them with finding where the docs are located on prebid.org if needed. 
+- If all above is good, add a `LGTM` comment and request 1 additional core member to review.
+- Once there is 2 `LGTM` on the PR, merge to master
+- Ask the submitter to add a PR for documentation if applicable.
+- Add a line into the [draft release](https://github.com/prebid/Prebid.js/releases) notes for this submission. If no draft release is available, create one using [this template]( https://gist.github.com/mkendall07/c3af6f4691bed8a46738b3675cb5a479)
+
+### New Adapter or updates to adapter process
+- Follow steps above for general review process. In addition, please verify the following:
+- Verify that bidder has submitted valid bid params and that bids are being received.
+- Verify that bidder is not manipulating the prebid.js auction in any way or doing things that go against the principles of the project. If unsure check with the Tech Lead.
+- Verify that  the bidder is being as efficient as possible, ideally not loading an external library, however if they do load a library it should be cached.
+- Verify that code re-use is being done properly and that changes introduced by a bidder don't impact other bidders.
+- If the adapter being submitted is an alias type, check with the bidder contact that is being aliased to make sure it's allowed.
+- If the adapter is triggering any user syncs make sure they are using the user sync module in the Prebid.js core.
+- Requests to the bidder should support HTTPS
+- Responses from the bidder should be compressed (such as gzip, compress, deflate)
+- Bid responses may not use JSONP: All requests must be AJAX with JSON responses
+- All user-sync (aka pixel) activity must be registered via the provided functions
+- Adapters may not use the $$PREBID_GLOBAL$$ variable
+- All adapters must support the creation of multiple concurrent instances. This means, for example, that adapters cannot rely on mutable global variables.
+- Adapters may not globally override or default the standard ad server targeting values: hb_adid, hb_bidder, hb_pb, hb_deal, or hb_size, hb_source, hb_format.
+- After a new adapter is approved, let the submitter know they may open a PR in the [headerbid-expert repository](https://github.com/prebid/headerbid-expert) to have their adapter recognized by the [Headerbid Expert extension](https://chrome.google.com/webstore/detail/headerbid-expert/cgfkddgbnfplidghapbbnngaogeldmop). The PR should be to the [bidder patterns file](https://github.com/prebid/headerbid-expert/blob/master/bidderPatterns.js), adding an entry with their adapter's name and the url the adapter uses to send and receive bid responses.
+
+## Ticket Coordinator
+
+Each week, Prebid Org assigns one person to keep an eye on incoming issues and PRs. That person should:
+- Review issues and PRs at least once per weekday for new items.
+- For PRs: assign PRs to individuals on the PR review list. Try to be equitable -- not all PRs are created equally. Use the "Assigned" field and add the "Needs Review" label.
+- For Issues: try to address questions and troubleshooting requests on your own, assigning them to others as needed.
+- Issues that are questions or troubleshooting requests may be closed if the originator doesn't respond within a week to requests for confirmation or details.
+- Issues that are bug reports should be left open and assigned to someone in PR rotation to confirm or deny the bug status.
+- It's polite to check with others before assigning them large tasks.
+- If possible, check in on older items and see if they can be unstuck.

README.md

@@ -26,11 +26,7 @@ Working examples can be found in [the developer docs](http://prebid.org/dev-docs
 
     $ git clone https://github.com/prebid/Prebid.js.git
     $ cd Prebid.js
-    $ yarn install
-
-Prebid supports the `yarn` npm client. This is an alternative to using `npm` for package management, though `npm install` will continue to work as before.
-
-For more info, see [the Yarn documentation](https://yarnpkg.com).
+    $ npm install
 
 *Note:* You need to have `NodeJS` 4.x or greater installed.
 
@@ -60,11 +56,8 @@ For example, when running the serve command: `gulp serve --modules=openxBidAdapt
 Building with just these adapters will result in a smaller bundle which should allow your pages to load faster.
 
 **Build standalone prebid.js**
-Prebid now supports the `yarn` npm client. This is an alternative to using `npm` for package management, though `npm` will continue to work as before.
-
-For more info about yarn see https://yarnpkg.com
 
-- Clone the repo, run `yarn install`
+- Clone the repo, run `npm install`
 - Then run the build:
 
         $ gulp build --modules=openxBidAdapter,rubiconBidAdapter,sovrnBidAdapter
@@ -82,11 +75,11 @@ With `modules.json` containing the following
 ]
 ```
 
-**Build prebid.js using Yarn for bundling**
+**Build prebid.js using npm for bundling**
 
-In case you'd like to explicitly show that your project uses `prebid.js` and want a reproducible build, consider adding it as an `yarn` dependency.
+In case you'd like to explicitly show that your project uses `prebid.js` and want a reproducible build, consider adding it as an `npm` dependency.
 
-- Add `prebid.js` as a `yarn` dependency of your project: `yarn add prebid.js`
+- Add `prebid.js` as a `npm` dependency of your project: `npm install prebid.js`
 - Run the `prebid.js` build under the `node_modules/prebid.js/` folder
 
         $ gulp build --modules=path/to/your/list-of-modules.json
@@ -113,6 +106,11 @@ To run the unit tests:
 ```bash
 gulp test
 ```
+To run tests for a single file:
+
+```bash
+gulp test --file "path/to/spec/file.js"
+```
 
 To generate and view the code coverage reports:
 

RELEASE_SCHEDULE.md

@@ -0,0 +1,22 @@
+# Release Schedule
+
+We push a new release of Prebid.js every other week on Tuesday. During the adoption phase for 1.x, we are releasing updates for 1.x and 0.x at the same time.
+
+While the releases will be available immediately for those using direct Git access,
+it will be about a week before the Prebid Org [Download Page](http://prebid.org/download.html) will be updated.  
+
+You can determine what is in a given build using the [releases page](https://github.com/prebid/Prebid.js/releases)
+
+Announcements regarding releases will be made to the #headerbidding-dev channel in subredditadops.slack.com.
+
+# FAQs
+
+**1. Is there flexibility in the 2-week schedule?**
+
+If a major bug is found in the current release, a maintenance patch will be done as soon as possible.
+
+It is unlikely that we will put out a maintenance patch at the request of a given bid adapter or module owner.
+
+**2. What Pull Requests make it into a release?**
+
+Every PR that's merged into master will be part of a release. Here are the [PR review guidelines](https://github.com/prebid/Prebid.js/blob/master/PR_REVIEW.md).