Initial deploment

.github/workflows/deployment.yml

@@ -0,0 +1,31 @@
+name: Deploy to GitHub Pages
+
+on:
+  push:
+    branches: [master]
+    paths: [website/**]
+
+jobs:
+  deploy:
+    name: Deploy to GitHub Pages
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v2
+      - uses: actions/setup-node@v2
+        with:
+          node-version: 14.x
+          cache: npm
+      - name: Build website
+        working-directory: website
+        run: |
+          npm ci
+          npm run build
+
+      # Popular action to deploy to GitHub Pages:
+      # Docs: https://github.com/peaceiris/actions-gh-pages#%EF%B8%8F-docusaurus
+      - name: Deploy to GitHub Pages
+        uses: peaceiris/actions-gh-pages@v3
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          # Build output to publish to the `gh-pages` branch:
+          publish_dir: ./website/build

.gitignore

@@ -1,90 +1,20 @@
-# Logs
-logs
-*.log
-npm-debug.log*
-yarn-debug.log*
-yarn-error.log*
-lerna-debug.log*
-
-# Diagnostic reports (https://nodejs.org/api/report.html)
-report.[0-9]*.[0-9]*.[0-9]*.[0-9]*.json
-
-# Runtime data
-pids
-*.pid
-*.seed
-*.pid.lock
-
-# Directory for instrumented libs generated by jscoverage/JSCover
-lib-cov
-
-# Coverage directory used by tools like istanbul
-coverage
-*.lcov
-
-# nyc test coverage
-.nyc_output
-
-# Grunt intermediate storage (https://gruntjs.com/creating-plugins#storing-task-files)
-.grunt
-
-# Bower dependency directory (https://bower.io/)
-bower_components
-
-# node-waf configuration
-.lock-wscript
-
-# Compiled binary addons (https://nodejs.org/api/addons.html)
-build/Release
-
-# Dependency directories
-node_modules/
-jspm_packages/
-
-# TypeScript v1 declaration files
-typings/
+# Dependencies
+/node_modules
 
-# TypeScript cache
-*.tsbuildinfo
+# Production
+/build
 
-# Optional npm cache directory
-.npm
+# Generated files
+.docusaurus
+.cache-loader
 
-# Optional eslint cache
-.eslintcache
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
 
-# Optional REPL history
-.node_repl_history
-
-# Output of 'npm pack'
-*.tgz
-
-# Yarn Integrity file
-.yarn-integrity
-
-# dotenv environment variables file
-.env
-.env.test
-
-# parcel-bundler cache (https://parceljs.org/)
-.cache
-
-# next.js build output
-.next
-
-# nuxt.js build output
-.nuxt
-
-# vuepress build output
-.vuepress/dist
-
-# Serverless directories
-.serverless/
-
-# FuseBox cache
-.fusebox/
-
-# DynamoDB Local files
-.dynamodb/
-
-.idea/
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

README.md

@@ -1 +1,41 @@
-engineering-docs
+# Website
+
+This website is built using [Docusaurus 2](https://docusaurus.io/), a modern static website generator.
+
+### Installation
+
+```
+$ yarn
+```
+
+### Local Development
+
+```
+$ yarn start
+```
+
+This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
+
+### Build
+
+```
+$ yarn build
+```
+
+This command generates static content into the `build` directory and can be served using any static contents hosting service.
+
+### Deployment
+
+Using SSH:
+
+```
+$ USE_SSH=true yarn deploy
+```
+
+Not using SSH:
+
+```
+$ GIT_USER=<Your GitHub username> yarn deploy
+```
+
+If you are using GitHub pages for hosting, this command is a convenient way to build the website and push to the `gh-pages` branch.

docs/collaboration/common-pull-request-issues.md

@@ -0,0 +1,32 @@
+---
+id: common-pull-request-issues
+title: Common Pull Request Issues
+sidebar_label: Common Pull Request Issues
+---
+
+_A non-exhaustive list of frequently encountered pull request issues._
+
+Collated below is a non-exhaustive list of frequently encountered pull request issues. By collating these issues, it is
+our intention that developers recognize what issues to look out for when performing a self-review.
+
+## Grammatical Mistakes and Awkward Phrasing in Documentation
+
+One common issue is grammatical mistakes and awkward phrasing in the documentation of code. To minimize the occurrence of
+these issues, it is recommended to perform the following:
+* Consider using a grammar checker such as Grammarly or switching to Android Studio/IntelliJ which contain a built-in grammar checker
+* Refer to existing documentation in the same project. It is likely that the project contains similar abstractions. Emulating
+the existing documentation is a great method of ensuring that documentation is consistent.
+* Refer to how a language's standard library phrases similar concepts. Using phrasing and terminology consistent with the language's
+reduces the cognitive burden of those reading the documentation
+* Repeatedly read through the documentation.
+
+See Google's [technical writing guide](https://developers.google.com/tech-writing) for more information.
+
+## Import Ordering
+Most IDEs place suggested import statements either at the top of the file or in alphabetical order. Neither of which confirm
+to our style guide. 
+
+If the project uses Dart/Flutter, consider running the following command to sort all import statements:
+```
+flutter pub run import_sorter:main
+```

docs/collaboration/development-etiquette.md

@@ -0,0 +1,42 @@
+---
+id: development-etiquette
+title: Development Etiquette
+sidebar_label: Development Etiquette
+---
+
+_A guide to good development etiquette._
+
+This document contains engineering conventions and practices that we consider to be good practice.
+In essence, the conventions and practices outlined in this document can be summarised as _"Work hard to make things easier"_.
+
+## Soliciting Feedback
+
+During verbal discussions on a feature, an accompanying draft pull request should be submitted. It is common for both
+parties to forget the contents of the discussion. By inscribing important sections of the discussion in the draft pull
+request, it becomes an indispensable archive for future reference.
+
+It is important to note that a **_draft_** pull request should be created instead of a **_normal_** pull request. This helps 
+other developers distinguish between pull requests soliciting feedback and those ready for review.
+
+![Draft Pull Request Button](/img/collaboration/draft-pull-requests.png)
+<p class = "caption">How to create a draft pull request</p>
+
+## The Definition of "Done"
+
+The definition of _"Done"_ is highly subjective especially in the context of pull requests. By providing a standardised
+definition of _"Done"_, we seek to avoid misunderstandings in what constitutes a pull request that is ready for review.
+
+By our definition, a _"Done"_ pull request satisfies all the following criteria:
+* It is feature-complete
+* It is thoroughly tested and nothing is expected to break
+* It is prepared cleanly and thoroughly to the best of the author's ability
+
+Sometimes, developers may be overwhelmed by the pressure to ship pull requests fast and skip the last two points. However,
+this is counterproductive and often leads to a net decrease in development velocity. The decrease in velocity can be attributed 
+to the latency of the constant ping-ponging between author and reviewer. Furthermore, it can be a frustrating experience
+for the reviewer.
+
+To avoid such situations, it is recommended for developers to perform a cursory self-review at least once. A self-review
+should address common mistakes such as grammatical and spelling errors.
+
+See [common pull request issues](./common-pull-request-issues.md) for more information.