merge

5 files changed, 91 insertions, 3 deletions

diff --git a/docs/creating-metrics-events.md b/docs/creating-metrics-events.md
new file mode 100644
index 000000000..7e7f2d77d
--- /dev/null
+++ b/docs/creating-metrics-events.md
@@ -0,0 +1,71 @@
+## Creating Metrics Events
+
+The `metricsEvent` method is made available to all components via context. This is done in `metamask-extension/ui/app/helpers/higher-order-components/metametrics/metametrics.provider.js`. As such, it can be called in all components by first adding it to the context proptypes:
+
+```
+static contextTypes = {
+  t: PropTypes.func,
+  metricsEvent: PropTypes.func,
+}
+```
+
+and then accessing it on `this.context`.
+
+Below is an example of a metrics event call:
+
+```
+this.context.metricsEvent({
+  eventOpts: {
+    category: 'Navigation',
+    action: 'Main Menu',
+    name: 'Switched Account',
+  },
+})
+```
+
+### Base Schema
+
+Every `metricsEvent` call is passed an object that must have an `eventOpts` property. This property is an object that itself must have three properties:
+- category: categorizes events according to the schema we have set up in our matomo.org instance
+- action: usually describes the page on which the event takes place, or sometimes a significant subsections of a page
+- name: a very specific descriptor of the event
+
+### Implicit properties
+
+All metrics events send the following data when called:
+- network
+- environmentType
+- activeCurrency
+- accountType
+- numberOfTokens
+- numberOfAccounts
+
+These are added to the metrics event via the metametrics provider.
+
+### Custom Variables
+
+Metrics events can include custom variables. These are included within the `customVariables` property that is a first-level property within first param passed to `metricsEvent`.
+
+For example:
+```
+this.context.metricsEvent({
+  eventOpts: {
+    category: 'Settings',
+    action: 'Custom RPC',
+    name: 'Error',
+  },
+  customVariables: {
+    networkId: newRpc,
+    chainId,
+  },
+})
+```
+
+Custom variables can have custom property names and values can be strings or numbers.
+
+**To include a custom variable, there are a set of necessary steps you must take.**
+
+1. First you must declare a constant equal to the desired name of the custom variable property in `metamask-extension/ui/app/helpers/utils/metametrics.util.js` under `//Custom Variable Declarations`
+1. Then you must add that name to the `customVariableNameIdMap` declaration
+    1. The id must be between 1 and 5
+    1. There can be no more than 5 custom variables assigned ids on a given url
diff --git a/docs/design-system.md b/docs/design-system.md
new file mode 100644
index 000000000..fa088bdbf
--- /dev/null
+++ b/docs/design-system.md
@@ -0,0 +1,5 @@
+# MetaMask Design System
+
+A design system is a series of components that can be reused in different combinations. Design systems allow you to manage design at scale.
+
+Design System [Figma File](https://www.figma.com/file/aWgwMrzdAuv9VuPdtst64uuw/Style-Guide?node-id=211%3A0)
diff --git a/docs/limited_site_access.md b/docs/limited_site_access.md
new file mode 100644
index 000000000..f703d5c7e
--- /dev/null
+++ b/docs/limited_site_access.md
@@ -0,0 +1,5 @@
+# Google Chrome/Brave Limited Site Access for Extensions
+
+Problem: MetaMask doesn't work with limited site access enabled under Chrome's extensions. 
+
+Solution: In addition to the site you wish to whitelist, you must add 'api.infura.io' as another domain, so the MetaMask extension is authorized to make RPC calls to Infura.
diff --git a/docs/porting_to_new_environment.md b/docs/porting_to_new_environment.md
index d901f2b78..f7a2ac8b7 100644
--- a/docs/porting_to_new_environment.md
+++ b/docs/porting_to_new_environment.md
@@ -10,7 +10,7 @@ The `metamask-background` describes the file at `app/scripts/background.js`, whi
 
 When a new site is visited, the WebExtension creates a new `ContentScript` in that page's context, which can be seen at `app/scripts/contentscript.js`. This script represents a per-page setup process, which creates the per-page `web3` api, connects it to the background script via the Port API (wrapped in a [stream abstraction](https://github.com/substack/stream-handbook)), and injected into the DOM before anything loads.
 
-The most confusing part about porting MetaMask to a new platform is the way we provide the Web3 API over a series of streams between contexts. Once you understand how we create the [InpageProvider](../app/scripts/lib/inpage-provider.js) in the [inpage.js script](../app/scripts/inpage.js), you will be able to understand how the [port-stream](../app/scripts/lib/port-stream.js) is just a thin wrapper around the [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), and a similar stream API can be wrapped around any communication channel to communicate with the `MetaMaskController` via its `setupUntrustedCommunication(stream, domain)` method.
+The most confusing part about porting MetaMask to a new platform is the way we provide the Web3 API over a series of streams between contexts. Once you understand how we create the [MetamaskInpageProvider](https://github.com/MetaMask/metamask-inpage-provider/blob/master/index.js) in the [inpage.js script](../app/scripts/inpage.js), you will be able to understand how the [port-stream](../app/scripts/lib/port-stream.js) is just a thin wrapper around the [postMessage API](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage), and a similar stream API can be wrapped around any communication channel to communicate with the `MetaMaskController` via its `setupUntrustedCommunication(stream, domain)` method.
 
 ### The MetaMask Controller
 
@@ -89,7 +89,7 @@ MetaMask has two kinds of [duplex stream APIs](https://github.com/substack/strea
 
 If you are making a MetaMask-powered browser for a new platform, one of the trickiest tasks will be injecting the Web3 API into websites that are visited. On WebExtensions, we actually have to pipe data through a total of three JS contexts just to let sites talk to our background process (site -> contentscript -> background).
 
-To see how we do that, you can refer to the [inpage script](https://github.com/MetaMask/metamask-extension/blob/master/app/scripts/inpage.js) that we inject into every website. There you can see it creates a multiplex stream to the background, and uses it to initialize what we call the [inpage-provider](https://github.com/MetaMask/metamask-extension/blob/master/app/scripts/lib/inpage-provider.js), which you can see stubs a few methods out, but mostly just passes calls to `sendAsync` through the stream it's passed! That's really all the magic that's needed to create a web3-like API in a remote context, once you have a stream to MetaMask available.
+To see how we do that, you can refer to the [inpage script](https://github.com/MetaMask/metamask-extension/blob/master/app/scripts/inpage.js) that we inject into every website. There you can see it creates a multiplex stream to the background, and uses it to initialize what we call the [MetamaskInpageProvider](https://github.com/MetaMask/metamask-inpage-provider/blob/master/index.js), which you can see stubs a few methods out, but mostly just passes calls to `sendAsync` through the stream it's passed! That's really all the magic that's needed to create a web3-like API in a remote context, once you have a stream to MetaMask available.
 
 In `inpage.js` you can see we create a `PortStream`, that's just a class we use to wrap WebExtension ports as streams, so we can reuse our favorite stream abstraction over the more irregular API surface of the WebExtension. In a new platform, you will probably need to construct this stream differently. The key is that you need to construct a stream that talks from the site context to the background. Once you have that set up, it works like magic!
 
diff --git a/docs/publishing.md b/docs/publishing.md
index 132c28d9b..392e20955 100644
--- a/docs/publishing.md
+++ b/docs/publishing.md
@@ -2,6 +2,13 @@
 
 When publishing a new version of MetaMask, we follow this procedure:
 
+## Overview
+
+The below diagram outlines our process for design, development, and release. Building MetaMask is a community affair, and many steps of the process invite participation from external contributors as indicated. All QA, code review, and release of new versions is done by members of the core MetaMask team.
+
+<img width="664" alt="mm-dev-process" src="https://user-images.githubusercontent.com/1016190/56308059-36906000-60fb-11e9-8e61-6655bca0c54f.png">
+
+
 ## Preparation
 
 We try to ensure certain criteria are met before deploying:
@@ -15,7 +22,7 @@ We try to ensure certain criteria are met before deploying:
 
 Version can be automatically incremented [using our bump script](./bumping-version.md).
 
-npm run version:bump $BUMP_TYPE` where `$BUMP_TYPE` is one of `major`, `minor`, or `patch`.
+npm run version:bump `$BUMP_TYPE` where `$BUMP_TYPE` is one of `major`, `minor`, or `patch`.
 
 ## Preparing for Sensitive Changes