docs(guide): update developer contribution guide

- add design standards

guide/CONTRIBUTING.md

@@ -19,11 +19,11 @@ Thank you for deciding to make a contribution! There are several ways you can co
 * Does the component satisfy an immediate and ongoing outcome for multiple teams?
 * Does the component comply with TELUS branding guidelines? <!-- TODO add link -->
 
-We would appreciate your patience during this process. Once a cataloguing system has been released, there will be opportunities to self-govern your own components. learn more by reading our [roadmap](ROADMAP.md).
+We would appreciate your patience during this process. Once a cataloguing system has been released, there will be opportunities to self-govern your own components. Learn more by reading our [roadmap](ROADMAP.md).
 
 When in doubt, feel free to [reach out to us](SUPPORT.md).
 
-## Contribution process (TDS Core) {#process}
+## Contribution process {#process}
 
 ### 1. Submit an issue {#1-submit-issue}
 
@@ -56,15 +56,24 @@ First, thanks for taking the time. :)
 
 Learn [how to open a pull request on GitHub](https://help.github.com/articles/creating-a-pull-request/)
 
+## Designer guide
+
+As a designer contributing to TDS, be sure to follow our [design standards][DESIGN]
+
 ## Developer guide
 
+When contributing to TDS, be sure to follow our [coding standards][CODE].
+
 ### Set up your environment
 
-After forking TDS, do the following steps to get started.
+After forking TDS, the following steps will get you started:
 
-```sh
+```bash
 # Install yarn
-brew install yarn # alternatively: npm i -g yarn
+brew install yarn
+
+# you can also use npm
+# npm i -g yarn
 
 # Install commitizen to write commit messages according to our preferred format.
 yarn global add commitizen
@@ -76,9 +85,13 @@ git clone https://github.com/<your-username>/tds.git && cd tds
 yarn
 ```
 
+We use [Prettier](https://prettier.io/), a tool that integrates with your text editor to automatically format your code to use our standards. You can configure your IDE to format your code automatically on save, and Prettier will adjust your syntax in accordance with [TDS standards][CODE].
+
 ### Development
 
-```sh
+**Dev environment**:
+
+```bash
 # Start the docs server, check output for the location of the docs
 yarn dev
 
@@ -88,19 +101,38 @@ yarn dev
 yarn test:watch
 ```
 
-After this, you can open up a browser to view the documentation site (usually <http://localhost:6060>). The browser will
-automatically refresh when there are changes to any of the source files.
+After this, you can open up a browser to view the documentation site (usually <http://localhost:6060>). The browser will automatically refresh when there are changes to any of the source files.
+
+**Creating a new component**:
+
+```bash
+# create a new component of `<componentname>` in /src/components
+yarn scaffold <componentname>
+
+# example result of `yarn scaffold PriceLock`
+# /src/components/PriceLock/PriceLock.md
+# /src/components/PriceLock/PriceLock.jsx
+# /src/components/PriceLock/PriceLock.module.scss
+# /src/components/PriceLock/__tests__/PriceLock.spec.jsx
+```
 
 ### When you are ready to make a commit
 
-<!-- TODO: consider using husky to install a git-push hook -->
-```sh
+<!--
+  TODO: consider using husky to install a git-push hook
+  That way developers don't need to use precommit
+-->
+```bash
 # Run build, linting and tests
 yarn precommit
 
-# Make a commit using commitizen
+# Stage your files and then make a commit using commitizen
 git cz
 ```
 
+After development, you may open a [pull request][PR].
+
 <!-- META -->
 [PR]: #3-pull-request
+[CODE]: STANDARDS.md#code
+[DESIGN]: STANDARDS.md#design

guide/STANDARDS.md

@@ -7,7 +7,7 @@
 
 When it comes to writing code, documentation, or Sketch assets, we have internal standards that help keep everything consistent and highly maintainable.
 
-## Documentation standards
+## Documentation standards {#docs}
 
 <!-- 
   TODO: include markdown, code snippet rules (spaces over tabs, etc)
@@ -16,12 +16,42 @@ When it comes to writing code, documentation, or Sketch assets, we have internal
 TBD
 [Documenting components](#documenting-components)
 
-## Design standards
+## Design standards {#design}
 
-<!-- TODO: make these -->
-TBD
+### Format
+
+Design contributions should be contributed in the form of a Sketch file (*.sketch).
+Components and blocks that are being contributed to TDS should be in a separate sketch file, in stand-alone art boards (i.e. not in a mock of a project). This will reduce the risk of any confusion of what is being supplied for contribution.
+Files being contributed should be clearly named according to the TELUS Digital file naming convention.
+
+### Viewports and Grid
+
+Each contribution should be supplied in the following viewports:
+XL (desktop): 1200+ px with container width 1168 px
+M (tablet): 768 px with container width 736 px
+XS (mobile): 320 px with container width 288 px
+
+For each viewport supplied, the TDS grid should be applied to ensure consistent sizing and measurements across the system.
+
+### Page/Layer Naming
+
+Layers should be named clearly and not using the naming applied to it as standard with sketch (i.e. Layer 1, Layer 1 Copy). The naming structure uses forward slashes ( / ) instead of spacing.
+Applying the above standards to the contributed sketch files will ensure a cohesive and consistent design language that can be used by all teams. Contributed blocks and components will be used by teams within TELUS and also external vendors.
 
-## Code standards
+### Typestyles
+
+For the any of the components or blocks being contributed, the file should have the TDS type stack applied to any and ALL of the text blocks in the contribution (ie. Display, H1, H2, H3, etc).
+Note: We understand that there are some cases that require the type stack to change slightly (ie. colour of H1). In these cases, please make the appropriate change to the file, and note it during the contribution and we can add the new type stack style to the master TDS file. This helps us manage the type stack and will help when we make that update globally.
+
+### Use of Symbols
+
+Any of the components in TDS being used in the new component or block being contributed should be maintained as a symbol from the original master Sketch file.
+Any new components being contributed, should NOT be made into a symbol. We will do this on our end and add it to the master Sketch file. This will ensure that the NEW symbol is named and put in the appropriate section.
+TDS will manage any new symbols/components being contributed and allow us to add them globally to the design system for further reuse.
+
+### [Example contribution file](https://docs.google.com/document/d/1zDX69nq_HZE8zRb26LYr9LY3SZRmYy1syb9aB1VQ0XM/edit#)
+
+## Code standards {#code}
 
 At a high level, all components are written in ECMAScript2015+ and React using JSX syntax. Component documentation is powered by [react-styleguidist](react-styleguidist.js.org) and [jest](https://facebook.github.io/jest/) is the testing framework. We broadly follow the comprehensive AirBnb style guides for [JavaScript](https://github.com/airbnb/javascript) and [React](https://github.com/airbnb/javascript/tree/master/react).
 
@@ -142,5 +172,3 @@ const MyLink = ({children, link, ...props}) => (
 * Use a snapshot test for components that do not have any logic and to increase confidence in the structure of the component. Snapshot tests do not replace unit tests.
 This codebase uses [react-styleguidist](https://react-styleguidist.js.org) to document components, and
 [jest](https://facebook.github.io/jest/)/[enzyme](http://airbnb.io/enzyme/) for unit testing.
-
-We use [Prettier](https://prettier.io/), a tool that integrates with your text editor to automatically format your code to use our standards.

guide/SUMMARY.md

@@ -10,10 +10,11 @@
 * [About the TELUS Design System](README.md)
 * [Contributing](CONTRIBUTING.md)
   * [Process](CONTRIBUTING.md#process)
+  * [Designer guide](CONTRIBUTING.md#designer-guide)
   * [Developer guide](CONTRIBUTING.md#developer-guide)
 * [Standards](STANDARDS.md)
-  * [Documentation](STANDARDS.md#documentation-standards)
-  * [Design](STANDARDS.md#design-standards)
-  * [Code](STANDARDS.md#coding-standards)
+  * [Documentation](STANDARDS.md#docs)
+  * [Design](STANDARDS.md#design)
+  * [Code](STANDARDS.md#code)
 * [Roadmap](ROADMAP.md)
 * [Support](SUPPORT.md)