Trying to fix website

.flowconfig

@@ -1,11 +1,61 @@
 [ignore]
+.*/node_modules/styled-components/.*
+.*/website/dist/sandbox/.*
+.*/website/.*
+.*/docs/templates/.*
+.*/packages/bitbucket/codemod-util-shared-styles-to-theme/__fixtures__/.*
+.*/packages/elements/icon/es5/.*
+.*/node_modules/stylelint/.*
+.*/node_modules/babel-flow-types/.*
+.*/node_modules/babel-normalize-comments/.*
+.*/node_modules/extract-react-types/.*
+.*/.git/.*
+[untyped]
+.*/node_modules/react-select
 
 [include]
 
 [libs]
 
-[lints]
-
 [options]
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/bitbucket/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/confluence/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/core/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/build/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/css-packs/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/ecosystem/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/editor/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/elements/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/growth/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/home/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/identity/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/jira/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/marketplace/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/media/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/people-and-teams/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/pipelines/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/purchasing/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/search/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/service-desk/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/statuspage/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/stride/\1/src/index'
+module.name_mapper='^@atlaskit\/\([a-zA-Z0-9_\-]+\)$' -> '<PROJECT_ROOT>/packages/trello/\1/src/index'
+
+module.name_mapper='\!\!style-loader\!css-loader\!.*' -> '<PROJECT_ROOT>/typings/style-loader-css-loader.js'
+module.name_mapper='\!\!raw-loader\!.*' -> '<PROJECT_ROOT>/typings/raw-loader.js'
+module.name_mapper='\!\!extract-react-types-loader\!.*' -> '<PROJECT_ROOT>/typings/extract-react-types-loader.js'
+module.name_mapper='extract-react-types' -> '<PROJECT_ROOT>/typings/extract-react-types.js'
+module.name_mapper='.*\.md' -> '<PROJECT_ROOT>/typings/md.js'
+module.name_mapper.extension='less' -> '<PROJECT_ROOT>/typings/less.js'
 
-[strict]
+suppress_comment=\\(.\\|\n\\)*\\$ExpectError
+suppress_comment=\\(.\\|\n\\)*\\$FlowFixMe
+suppress_comment=\\(.\\|\n\\)*\\$StringLitteral
+
+# Show warnings when running flow as we run flow with --max-warnings=0 to fail in CI
+include_warnings=true
+
+[lints]
+# Disable standard linting rules so we can fail on warnings caused by 'Unused suppression' only
+# 'Unused suppression' lints cannot be specifically elevated to errors - https://github.com/facebook/flow/issues/6891
+all=off

docs/getting-started.md

@@ -0,0 +1,20 @@
+---
+title: Getting Started
+description: Everything you need to know to get up and running with Atlaskit
+---
+
+# Getting Started
+
+_Everything you need to know to get up and running with Atlaskit_
+
+## 1. The React components
+
+These components are Atlassian Design Guidelines(ADG) compliant, reusable, well-maintained and accessible. If you want an introduction to react, we recommend looking [here](https://reactjs.org/tutorial/tutorial.html). For information on how to use our components in your app:
+
+* The [packages section](/packages) of this site has documentation, code samples and examples that can be opened in codesandbox for all of our components, which can be individually installed for use in projects.
+* The [atlaskit-starter](http://go.atlassian.com/ak-starter/) project will help you get a React app setup and running with some demo Atlaskit components.
+* Open any of the examples in codesandbox to quickly experiment with the components.
+
+## 2. The reduced UI pack
+
+The reduced UI pack is a small set of ADG styles for use in any web project. The [reduced UI pack](/packages/css-packs/reduced-ui-pack) details how to apply these.

docs/guides/00-contributing.md

@@ -0,0 +1,117 @@
+# Contributing
+
+Related reading:
+
+* [Contribution checklist](./contribution-checklist)
+* [Component design](./component-design)
+* [Directory structure](./directory-structure)
+* [Adding new icons](./adding-new-icons)
+* [Releasing packages](./releasing-packages)
+* [Versioning](./versioning)
+
+## Code of Conduct
+
+This project is bound by a [Code of Conduct](https://bitbucket.org/atlassian/atlaskit-mk-2/src/HEAD/CODE_OF_CONDUCT.md).
+
+## Introduction
+
+Although it's our job to look after all the components in our repo, we rely heavily on contributions outside of our team to make Atlaskit great. At its core, our contrubution model is very much like contributing to any open source library, but because we get several contributions from within Atlassian from other teams, we have the ability to build on that model to help make inter-team contributions more efficient.
+
+## Open source contribution model
+
+If this is your first time or if you don't have permission to create a branch, follow the instructions under 'Become a contributor' in our [README.md](https://bitbucket.org/atlassian/atlaskit-mk-2/src) to request permission.
+
+We want to keep this model very simple. At it's core, we make the assumptions that developers looking to contribute will look at the `README.md` and thus, be directed to the `CONTRIBUTING.md`. Even so, both of those files are widely known as convention in an open source project and developers will be able to direct themselves there.
+
+The process consists of:
+
+1.  Raise an issue for discussion. This step may not even be necessary as this could all be done in a PR, depending on if the contributor is willing to lose work if the contribution doesn't get accepted.
+2.  Submit a PR resolving the raised issue.
+
+This is super simple and the PR guidelines can be derived from the rest of our conventions and documentation. It's also compatible with the inter-team model, because, at the very worst, internal teams would still be able to follow this process.
+
+The only real downsides here are that:
+
+1.  It can take longer to yield a merge due to async discussions.
+2.  Discovery of contribution need is mostly up to the contributor, unless we reach out to them.
+
+The inter-team model expands on the open source model to make this process more efficient because we have the privilege of working with internal teams in such a way.
+
+## Inter-team contribution model
+
+Like the open source model, the inter-team contribution model is kept as light as possible and is designed for compatibility with it so that, at worst, we can fallback to the open source model as teams in other timezones may not be able to meet as easily.
+
+The different aspects of the inter-team contribution are the following:
+
+* [Introduction](#introduction)
+* [Initial discussion](#initial-discussion)
+* [Regular catch-ups](#regular-catch-ups)
+* [Shepherd involvement](#shepherd-involvement)
+* [Tracking ](#tracking)
+* [Contribution requirements](#contribution-requirements)
+* [Handover and maintenance](#handover-and-maintenance)
+
+### Introduction
+
+The contribution may be initially sparked by several methods:
+
+* Water-cooler discussion with a colleague.
+* Issue raised by another team.
+* Atlaskit team member noticing similar implementations in products and raising it.
+* Any sync meetings between teams.
+
+### Initial discussion
+
+Regardless of how the discussion is triggered, we want to be clear on a few things:
+
+1.  Any initial action items.
+2.  Decide who will be the contributor from the external team.
+3.  Decide who will be the shepherd from within the Atlaskit team.
+
+This process may come naturally and not require an initial meeting. For example, a contribution may be very simple, a PR may have already been made and it may be good to go out of the gate. Others may require a bit more formality to keep the quality bar high.
+
+A more complete process may look like: introduction > discuss approach and plan > spec / prototype review > raise PR > discuss and merge > high five.
+
+_We don't want this process to to impede the contribution, waste anyone's time or to appear like the waterfall process. You should decide up front if the complexity if the contribution warrants such process and always be mindful to keep it as lean as possible._
+
+### Regular catch-ups
+
+Since these two components can affect one another, everyone involved should keep in constant communication. Therefore it's a good idea if a regular catch-up is scheduled between interested parties to keep the feedback loop tight. These catchups may be simply stand-ups, or might be more involved and contain demos of work progress. The complexity of these will be unique for each contribution.
+
+Some examples of this are:
+
+* Daily stand-ups
+* Weekly catch-ups
+* Demos every other day
+* Creating a Stride room for regular communication
+
+The people involved in these catch-ups will vary, as well. For example, it may simply be the contributor and shepherd. It may have a designer present. Other team members may be involved depending on the complexity.
+
+_The key here is that everyone shares knowledge and can hold each other accountable as everyone may have several things on their plate at any given point in time._
+
+### Shepherd involvement
+
+Every contribution will have a shepherd, but to the extent at which this shepherd will be involved will vary. For example, a shepherd may or may not write code depending on their workload and the needs of the contributor. At minimum, shepherds must:
+
+* Review relevant PRs.
+* Meet with contributors, or involved parties.
+* Plan any follow ups after the final contribution and handover has been made.
+
+### Tracking
+
+The shepherd should raise an issue internally to track the overall process and give it a label of "contribution".
+
+### Contribution requirements
+
+To keep the quality bar high, we should do our best to ensure the contribution closely matches our general component design [guidelines](#component-design) as well as the following:
+
+* [Directory structure](./directory-structure)
+* [Naming props](./naming-props)
+* [Using higher-order components vs render props](./hoc-vs-props)
+* [Using `Component` vs `PureComponent`](./component-vs-pure-component)
+
+### Handover and maintenance
+
+In an ideal world, the contributor would be able to support the component for some time after mergin. This isn't always the case, however. Either way, we should ensure that both the shepherd and contributor - in that order - are mentioned as the `maintainers` in the `package.json`. The first person listed - the shepherd - will be the primary point of contact. The second person listed - the contributor - will be the secondary point of contact, just in case, since they were the ones that contributed it.
+
+Over time, this may evolve and both the contributor and shepherd may be removed in favour of a new maintainer. This is fine and should be considered normal.

docs/guides/00-directory-structure.md

@@ -0,0 +1,183 @@
+# Directory structure
+
+Related reading:
+
+* [Component design](./component-design)
+
+The top-level directory structure for Atlaskit looks like the following diagram:
+
+```
+Atlaskit
+├─ build ·········· Build packages
+├─ docs ··········· Project documentation
+├─ flow-typed ····· Flow types for untyped dependencies
+├─ packages ······· Public packages
+├─ patterns ······· Overarching component patterns
+├─ releases ······· Release documentation
+├─ typings ········ Exported Flow / TypeScript types
+├─ website ········ Website package
+└─ package.json ··· Project config
+```
+
+## Build
+
+The `build` directory is where all build tooling goes that isn't handled by our tools directly.
+
+## Docs
+
+The `docs` directory is where all project documentation lives. It is displayed on the website under "Getting started > Documentation" and is the main source of Atlaskit's documentation.
+
+## Packages
+
+The `packages` directory is where all of our public NPM packages are contained. Each subfolder is broken down in to another directory that allows us to separate which packages belong to certain teams, and also to make running a subset of build tasks only for certain sets of packages.
+
+It may look something like:
+
+```
+└─ packages
+  ├─ core
+  ├─ editor
+  ├─ elements
+  └─ media
+```
+
+### Per-package structure
+
+The structure leading to each package will look something like:
+
+```
+└─ packages
+  └─ core
+    └─ avatar
+      ├─ dist ··········· Built files, autogenerated
+      ├─ docs ··········· Package-specific documentation
+      ├─ examples ······· Package-specific examples
+      ├─ node_modules ··· NPM dependencies
+      ├─ src ············ Package source
+      ├─ CHANGELOG.md ··· Entire change history for the package
+      ├─ index.js ······· Private entry point for tests
+      ├─ LICENSE ········ Package license
+      └─ package.json ··· NPM package configuration
+```
+
+The details of each directory in each package is explained in greater detail further down.
+
+#### `dist`
+
+The `dist` directory contains the bundles we ship to our NPM package. We ship both CommonJS and ES Modules to NPM.
+
+```
+└─ packages
+  └─ core
+    └─ avatar
+      └─ dist
+        ├─ cjs
+        ├─ esm
+        └─ package.json
+```
+
+#### `docs`
+
+The `docs` directory houses the docs specific to the respective package. The docs are written in Markdown and are prefixed with a number to maintain order.
+
+```
+└─ packages
+  └─ core
+    └─ avatar
+      └─ docs
+        ├─ 01-intro.md
+        └─ 02-another-page.md
+```
+
+#### `examples`
+
+Like the `docs` directory, the purpose of the `examples` directory is to document behaviour, but in a much more fine-grained fashion. It shows you an example and the code to create the corresponding example.
+
+When not writing unit tests, this is where you'll spend most of your development time when viewing your components as you write your source code. It's preferable that you write your tests first, but you can have both running at the same time so as you make updates, you can see your test output *and* your component output.
+
+```
+└─ packages
+  └─ core
+    └─ avatar
+      └─ examples
+        ├─ 01-basic.js
+        └─ 02-another-example.js
+```
+
+#### `node_modules`
+
+This is where the NPM packages are kept. Bolt will automatically populate this, you don't have to manually install the dependencies for each package.
+
+#### `src`
+
+Each package's source should contain a similar directory structure. Essentially this rule follows the convention that anything that has a default export must be `CamelCapped` or `camelCased`. Everything else is `dash-cased`. This rule is expanded into the following that goes into greater detail about how certain things in the structure should look (i.e. styled-components / tests).
+
+1. There must always be an `index.js` that exports your public API.
+2. Each file that has a default export, must *only* have a default export - no named exports. This simplifies the heuristics to determine a name for the file.
+3. The file name should be the name of the export. For example, if `Avatar` is a default export for a file, the file name should be `Avatar.js`. For a HoC, this might look something like `withAvatar`.
+4. In lieu of a file, you may use a directory with an `index.js` file. For example, `Avatar/index.js`.
+5. Styled components should go in a `styled.js` file, or you can use a `styled/index.js` file that exports sibling files with default exports that conform to #3 or #4. This should also follow something similar to #6 and have this for every level of components.
+6. Tests should be in a `__tests__` that correspond to the level of files you're testing and the type of testing you want to apply. A good rule of thumb is that `__tests__` should be placed under `src`. In addition, if you write different types of testing, to avoid confusion, you may club tests under subfolders. For further information about testing, please consult this [page](./testing).
+
+Your structure may look something like this:
+
+```
+└─ packages
+  └─ core
+    └─ avatar
+      └─ src
+        ├─ __tests__ ············ Tests for Avatar.js, index.js, styled.js
+        ├─ Avatar ··············· Directory form of Avatar.js
+        │ ├─ __tests__ ·········· Tests for Avatar/index.js
+        | |  ├─ unit ............ Unit tests for Avatar
+          |  ├─ integration ..... Integration tests for Avatar
+          |  ...............
+        │ └─ index.js ··········· Default export for Avatar
+        │ └─ styled ············· Directory for styled components
+        │   ├─ __tests__ ········ Tests for Styled/index.js, MyComponent.js
+        |      ├─ unit ............ Unit tests for Avatar
+        |      ├─ integration ..... Integration tests for Avatar
+        |      ...............
+        │   ├─ index.js ········· Exports MyComponent
+        │   └─ MyComponent.js ··· Exported by index.js
+        ├─ Avatar.js ············ Simpler form of Avatar/index.js
+        ├─ index.js ············· Main entry point
+        ├─ styled.js ············ Simpler form of styled/index.js
+        └─ types.js ············· Type definitions
+```
+
+The key difference between the file and directory forms (i.e. `styled.js` vs `styled/index.js`) is how complex your component becomes. What matters here is that consistency is still very close and your imports do not change.
+
+_The rules listed above are exhaustive. Anything outside of them are not supported. This includes things like leading underscores (_filename.js), underscored names (file_name.js) and dotted names (file.name.js)._
+
+#### `CHANGELOG.md`
+
+The changelog contains all of the relevant changes of the package, over time, in an easy-to-consume format. It also is searchable from the website if you want the changes for a particular version.
+
+#### `index.js`
+
+This `index.js` file exists for Jest so that it can resolve the actual source of the package as opposed to having to build the entire set of packages prior to running tests.
+
+#### `LICENSE`
+
+The `LICENSE` file contains the license for each package. Generally this is just the Apache 2 license.
+
+#### `package.json`
+
+The `package.json` file contains all the information and configuration that NPM needs to host our package.
+
+#### `README.md`
+
+The `README.md` file contains a introduction for each package.
+
+## Patterns
+
+The `patterns` directory is a single package that houses all of our overarching component patterns. For example, this may contain a rough implementation of `@atlaskit/navigation` for Jira.
+
+## Releases
+
+Contains the documentation for releases containing significant changes along with any migration guides.
+
+## Website
+
+The Atlaskit website is how we dogfood our components and also serves as our public documentation.