Let's go

.gitignore

@@ -86,3 +86,5 @@ typings/
 
 # DynamoDB Local files
 .dynamodb/
+
+.idea/

Forus Labs' Engineering Documentation/.gitignore

@@ -0,0 +1,20 @@
+# Dependencies
+/node_modules
+
+# Production
+/build
+
+# Generated files
+.docusaurus
+.cache-loader
+
+# Misc
+.DS_Store
+.env.local
+.env.development.local
+.env.test.local
+.env.production.local
+
+npm-debug.log*
+yarn-debug.log*
+yarn-error.log*

Forus Labs' Engineering Documentation/README.md

@@ -0,0 +1,41 @@
+# 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.

Forus Labs' Engineering Documentation/babel.config.js

@@ -0,0 +1,3 @@
+module.exports = {
+  presets: [require.resolve('@docusaurus/core/lib/babel/preset')],
+};

Forus Labs' Engineering Documentation/docs/collaboration/crafting-a-good-pull-request.md

@@ -0,0 +1,68 @@
+---
+id: crafting-a-good-pull-request
+title: Crafting a Good Pull Request
+sidebar_label: Crafting a Good Pull Request
+---
+
+_A guide to crafting good pull requests._
+
+## Atomicity
+
+An atomic pull request is self-contained and independent of other pull requests. It should be a small, production-ready 
+change with everything included. In practice, an atomic pull request will contain all supporting tests, documentation and 
+relevant examples. In a sense, it is similar to an atomic operation in concurrent programming.
+
+Pull requests that merge into master should be atomic.
+
+## Size Matters
+
+Each pull request should be small and address exactly one concern. As a rule of thumb, a pull request should contain ~10 files
+with substantial changes. Large pull requests are difficult and tedious to review. For an in-depth discussion,
+see [Google's Engineering Practices Documentation](https://google.github.io/eng-practices/review/developer/small-cls.html).
+
+## The Anatomy of Good Pull Requests
+
+A good pull request describes _what_ changes are made and _why_ they are made.
+
+### Short Titles
+
+The title of a pull request should be a short summary of _what_ is being accomplished. It should be informative enough to 
+describe what the pull request does without reading the description.
+
+A title should be phrased as an imperative sentence (without a trailing .). For example, "Remove Palette and replace it with Styles", 
+instead of "Removing Palette and replacing it with Styles".
+
+Following the naming convention outlined in [Git Gud](./git-gud.md), a branch name is **not** a suitable title. Using it will result in 
+something ill-formatted and vague. Since the default title generated by GitHub is derived from the branch's name, it should therefore be avoided.
+
+### Detailed Descriptions
+
+The title should be a short summary while the description should contain the details and information needed for a reader to understand the changes holistically,
+i.e. (_why_ something was changed). It should not be empty barring the most trivial bug fixes. Bullet points may be preferred over a lengthy prose in some situations.
+
+If a pull request contains changes to the UI, consider attaching images of the altered UI.
+
+Listed below are some useful prompts for crafting descriptions under different circumstances. They should not be blindly applied to all descriptions.
+
+* Are there other pull requests or issues related to this pull request?
+
+* What is the problem being solved?
+
+* Why is this the best approach?
+
+* Are there any shortcomings to this approach?
+
+* Is there any relevant background information or context?
+
+* Is there any future work that needs to be addressed?
+
+### Counterexamples
+Listed below are some examples of inadequate descriptions. They lack information on what is being changed and why so.
+
+* "Fix build"
+
+* "Fix bug"
+
+* "Add function"
+
+* "Delete class"

Forus Labs' Engineering Documentation/docs/collaboration/gentlemens-etiquette.md

@@ -0,0 +1,39 @@
+---
+id: gentlemens-etiquette
+title: A Gentleman's Etiquette
+sidebar_label: Gentlemen's Etiquette
+---
+
+_A Gentleman's guide to good development etiquette._
+
+This guide contains what we consider to be good development etiquette that gentlemen follow. Only barbarians willfully ignore them.
+
+## Pull Requests
+
+### Draft a Pull Request
+
+A gentleman drafts a pull request when soliciting feedback. Barbarians willfully submit a work-in-progress pull request
+as ready for review.
+
+![Draft Pull Request Button](/img/collaboration/draft-pull-requests.png)
+
+Drafting a pull request distinguishes between pull requests soliciting feedback and those ready for review. It helps other
+developers keep track of a pull request's status.
+
+### Perform a Self-review
+
+Before submitting a pull request for peer-review, a gentleman performs a cursory self-review and fixes any obvious mistakes
+they can find. Barbarians willfully (mis)uses peer-reviews as a human-powered lint to spot trivial issues. 
+
+It's perfectly normal to submit a pull request with a few careless mistakes. On the contrary, submitting a pull request filled 
+with careless mistakes every other line implies that the developer is a barbarian that simply does not care or does not spot
+the mistakes. Both of which does not reflect well on the developer.
+
+A pull request filled with careless mistakes dramatically slows down the progress of a code review. Not to mention, it is
+a frustrating experience for the reviewer. Put yourself into the shoes of the reviewer and imagine if someone else did the same.
+
+See [common pull request issues](./common-pull-request-issues.md) for frequently encountered issues.
+
+
+
+

Forus Labs' Engineering Documentation/docs/collaboration/git-gud.md

@@ -0,0 +1,43 @@
+---
+id: git-gud
+title: Git Gud
+sidebar_label: Git Gud
+---
+_An introduction to Forus Labs' Git workflow._
+
+Forus Labs' Git workflow is modelled after the [trunk-based development model](https://trunkbaseddevelopment.com/) albeit with a few adjustments.
+
+## The `master` Branch
+
+Each Git repository contains a permanent `master` branch with production-ready code. During deployment to production, 
+a commit on `master` is tagged and a corresponding GitHub release is created. This tagged commit is then subsequently deployed.
+
+## Ephemeral Branches
+
+Ephemeral branches contain new features and improvements that are being worked on. As the name suggests, ephemeral branches 
+are temporary, short-lived branches which aid in the concurrent development of new features. They are created from either `master` 
+or other ephemeral branches and always merged back into `master`.
+
+![Branching Model](/img/collaboration/feature-branch.png)
+
+<p class="caption">
+    Forus Labs' Git workflow
+</p>
+
+There are two different types of ephemeral branches:
+
+| Type    | Prefix        | Description                            |
+|:--------|:--------------|:---------------------------------------|
+| feature | `feature/...` | contains new features and enhancements |
+| fix     | `fix/...`     | contains bug fixes                     |
+
+
+An ephemeral branch name starts with a prefix, followed by a description. The description should be a short summary of what 
+changes the branch contains. Spaces in the description are replaced with hyphens.
+
+For example, an ephemeral branch that adds laser beams should be named `feature/laser-beams` while a branch that fixes exploding 
+buttons should be named `fix/exploding-buttons`.
+
+To request feedback on a feature's progress or when a feature is ready, open a pull request. The pull request will then be 
+commented on and reviewed. If the pull request is approved, the ephemeral branch is merged into `master` by the reviewer
+and deleted by the pull request author.

Forus Labs' Engineering Documentation/docs/overview.mdx

@@ -0,0 +1,25 @@
+---
+id: overview
+title: Engineering Practices Overview
+sidebar_label: Overview
+hide_title: true
+---
+
+import ThemedImage from '@theme/ThemedImage';
+
+<ThemedImage
+  alt="Forus Labs themed image"
+  sources={{
+    light: '/img/logo-full-light.svg',
+    dark: '/img/logo-full-dark.svg',
+  }}
+/>;
+
+Every respectable organization that produces software adheres to certain best practices and conventions. These living documents
+represent _our_ best practices and conventions that we developed over time from our experience and observations. We welcome
+any improvements and suggestions to these documents, so don't be afraid to contribute!
+
+The documents are sorted into three categories:
+* [Getting Started](./getting-started) - Essential information for new developers
+* [Collaboration](./collaboration) - Our conventions and practices
+* [Style Guides](./style-guides) - Style guides for different languages (and technical writing)

Forus Labs' Engineering Documentation/docusaurus.config.js

@@ -0,0 +1,119 @@
+// @ts-check
+// Note: type annotations allow type checking and IDEs autocompletion
+
+const lightCodeTheme = require('prism-react-renderer/themes/github');
+const darkCodeTheme = require('prism-react-renderer/themes/dracula');
+
+/** @type {import('@docusaurus/types').Config} */
+const config = {
+  title: 'Forus Labs\' Engineering Documentation',
+  tagline: 'Unlocking your potential',
+  url: 'https://your-docusaurus-test-site.com',
+  baseUrl: '/',
+  onBrokenLinks: 'throw',
+  onBrokenMarkdownLinks: 'warn',
+  favicon: 'img/favicon.ico',
+  organizationName: 'Forus Labs', // Usually your GitHub org/user name.
+  projectName: 'engineering-docs', // Usually your repo name.
+
+  presets: [
+    [
+      'classic',
+      /** @type {import('@docusaurus/preset-classic').Options} */
+      ({
+        docs: {
+          sidebarPath: require.resolve('./sidebars.js'),
+          // Please change this to your repo.
+          editUrl: 'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
+        },
+        blog: {
+          showReadingTime: true,
+          // Please change this to your repo.
+          editUrl:
+            'https://github.com/facebook/docusaurus/tree/main/packages/create-docusaurus/templates/shared/',
+        },
+        theme: {
+          customCss: require.resolve('./src/css/custom.css'),
+        },
+      }),
+    ],
+  ],
+
+  themeConfig:
+    /** @type {import('@docusaurus/preset-classic').ThemeConfig} */
+    ({
+      navbar: {
+        title: 'Forus Labs\'s Engineering Documentation',
+        logo: {
+          alt: 'Forus Labs Logo',
+          src: 'img/logo-light.svg',
+          srcDark: 'img/logo-dark.svg',
+        },
+        items: [
+          {
+            type: 'doc',
+            docId: 'overview',
+            position: 'right',
+            label: 'Documentation',
+          },
+//          {to: '/blog', label: 'Blog', position: 'left'},
+          {
+            href: 'https://github.com/facebook/docusaurus',
+            label: 'GitHub',
+            position: 'right',
+          },
+        ],
+      },
+      footer: {
+        style: 'dark',
+        links: [
+          {
+            title: 'Docs',
+            items: [
+              {
+                label: 'Tutorial',
+                to: '/docs/intro',
+              },
+            ],
+          },
+          {
+            title: 'Community',
+            items: [
+              {
+                label: 'Stack Overflow',
+                href: 'https://stackoverflow.com/questions/tagged/docusaurus',
+              },
+              {
+                label: 'Discord',
+                href: 'https://discordapp.com/invite/docusaurus',
+              },
+              {
+                label: 'Twitter',
+                href: 'https://twitter.com/docusaurus',
+              },
+            ],
+          },
+          {
+            title: 'More',
+            items: [
+              {
+                label: 'Blog',
+                to: '/blog',
+              },
+              {
+                label: 'GitHub',
+                href: 'https://github.com/forus-labs',
+              },
+            ],
+          },
+        ],
+        copyright: `Copyright © ${new Date().getFullYear()} Forus Labs Pte Ltd. Built with Docusaurus.`,
+      },
+      prism: {
+        theme: lightCodeTheme,
+        darkTheme: darkCodeTheme,
+      },
+    }),
+};
+
+module.exports = config;