docs: add CONTRIBUTING, DEVELOPING and VSCODE

Add a short CONTRIBUTING.md file serving as a collection of links
pointing to other documentation.

Start a guide for developers in DEVELOPING.md.

Describe VS Code setup in VSCODE.md, document steps needed to verify
integration with tsc and tslint.

docs/CONTRIBUTING.md

@@ -0,0 +1,38 @@
+# Contributing to LoopBack
+
+Contributions to Node.js include code, documentation, answering user questions, and advocating for all types of Node.js users. See our official documentation on loopback.io for more information common to all of our GitHub repositories:
+
+  - http://loopback.io/doc/en/contrib/index.html
+
+## [Principles](http://loopback.io/doc/en/contrib/Governance.html#principles)
+
+LoopBack is an open, inclusive, and tolerant community of people working together to build a world-class Node framework and tools. We value diversity of individuals and opinions, and seek to operate on consensus whenever possible. We strive to maintain a welcoming, inclusive, and harassment-free environment, regardless of the form of communication. When consensus is not achievable, we defer to the owners of each individual module; the powers of the individual owner are kept in check by the ability of the community to fork and replace dependencies on the individual module and maintainer.
+
+## [Reporting issues](http://loopback.io/doc/en/contrib/Reporting-issues.html)
+
+Issues in [strongloop/loopback-next](https://github.com/strongloop/loopback-next/issues) are the primary means by which bug reports and general discussions are made.
+
+ - [How to report an issue](http://loopback.io/doc/en/contrib/Reporting-issues.html#how-to-report-an-issue)
+ - [Disclosing security vulnerabilities](http://loopback.io/doc/en/contrib/Reporting-issues.html#security-issues)
+
+## [Contributing code](http://loopback.io/doc/en/contrib/code-contrib.html)
+
+Pull Requests are the way concrete changes are made to the code, documentation
+and tools contained in LoopBack repositories.
+
+ - [Setting up development environment](./DEVELOPING.md#setting-up-development-environment)
+ - [How to contribute the code](http://loopback.io/doc/en/contrib/code-contrib.html#how-to-contribute-to-the-code)
+ - [Coding style](http://loopback.io/doc/en/contrib/style-guide.html)
+ - [Git commit messages](./DEVELOPING.md#commit-message-guidelines)
+ - [Reviewing pull requests](http://loopback.io/doc/en/contrib/triaging-pull-requests.html)
+ - [Contributor License Agreement (CLA)](http://loopback.io/doc/en/contrib/code-contrib.html#agreeing-to-the-cla)
+
+## [Documentation](http://loopback.io/doc/en/contrib/doc-contrib.html)
+
+LoopBack documentation is sourced in the [strongloop/loopback.io](https://github.com/strongloop/loopback.io) GitHub repository.
+
+ - [How LoopBack documentation works](http://loopback.io/doc/en/contrib/doc-contrib.html#how-loopback-documentation-works)
+ - [Using Jekyll](http://loopback.io/doc/en/contrib/jekyll_getting_started.html)
+ - [Authoring pages](http://loopback.io/doc/en/contrib/pages.html)
+ - [Translations](http://loopback.io/doc/en/contrib/translation.html)
+

docs/DEVELOPING.md

@@ -0,0 +1,180 @@
+# Developing LoopBack
+
+This document describes how to develop modules living in loopback-next monorepo.
+
+ - [Setting up development environment](#setting-up-development-environment)
+ - [Building the project](#building-the-project)
+ - [Running tests](#running-tests)
+ - [Coding rules](#coding-rules)
+ - [API documentation](#api-documentation)
+ - [Commit message guidelines](#commit-message-guidelines)
+ - [How to test infrastructure changes](#how-to-test-infrastructure-changes)
+
+## Setting up development environment
+
+Before you can start developing LoopBack, you need to install and configure few
+dependencies.
+
+ - [git](https://git-scm.com/): Github's [Set Up Git](https://help.github.com/articles/set-up-git/) guide is a good source of information.
+ - [Node.js 8.x (LTS)](https://nodejs.org/en/download/)
+
+You may want to configure your IDE or editor to get better support for
+TypeScript too.
+
+ - [VisualStudio Code](./VSCODE.md)
+ - _Missing your favorite IDE/editor here? Pull requests are welcome!_
+
+Before getting started, it is recommended to configure `git` so that it knows who you are:
+
+```sh
+$ git config --global user.name "J. Random User"
+$ git config --global user.email "[email protected]"
+```
+
+Please make sure this local email is also added to your [GitHub email list](https://github.com/settings/emails) so that your commits will be properly associated with your account and you will be promoted to Contributor once your first commit is landed.
+
+## Building the project
+
+Whenever you pull updates from GitHub or switch between feature branches,
+we recommend to do a full reinstall of all npm dependencies:
+
+```sh
+$ npm run clean:lerna && npm run bootstrap
+```
+
+The next step is to compile all packages from TypeScript to JavaScript:
+
+```sh
+$ npm run build
+```
+
+Please note that we are automatically running the build from `pretest`
+script, therefore you should not need to run this command as part of your
+[red-green-refactor cycle](http://www.jamesshore.com/Blog/Red-Green-Refactor.html).
+
+## Running tests
+
+This is the only command you should need while developing LoopBack:
+
+```sh
+$ npm test
+```
+
+It does all you need:
+
+ - Compile TypeScript
+ - Run all tests
+ - Check code formatting using [Prettier](https://prettier.io/)
+ - Lint the code using [TSLint](https://palantir.github.io/tslint/)
+
+## Coding rules
+
+## API Documentation
+
+## Commit message guidelines
+
+A good commit message should describe what changed and why.
+
+Our commit messages are formatted according to [Conventional Commits](https://conventionalcommits.org/), we use [commitlint](https://github.com/marionebl/commitlint) to verify and enforce this convention.  These rules lead to more readable messages that are easy to follow when looking through the project history. But also, we use the git commit messages to generate change logs when publishing new versions.
+
+### Commit Message Format
+
+Each commit message consists of a **header**, a **body** and a **footer**. The header has a special format that includes a **type**, an optional **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+#### type
+
+The **type** must be one of the following:
+
+ - **feat**: A new feature
+ - **fix**: A bug fix
+ - **docs**: Documentation only changes
+ - **style**: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
+ - **refactor**: A code change that neither fixes a bug nor adds a feature
+ - **perf**: A code change that improves performance
+ - **test**: Adding missing or correcting existing tests
+ - **build**: Changes that affect the build system or external dependencies
+ - **ci**: Changes to our CI configuration files and scripts
+ - **chore**: Changes to the auxiliary tools and libraries such as documentation generation
+ - **revert**: Reverts a previous commit
+
+#### scope
+
+The **scope** must be a list of one or more packages contained in this monorepo. Eeach scope name must match a directory name in [packages/](../packages), e.g. `core` or `context`.
+
+
+#### subject
+
+The **subject** contains succinct description of the change:
+
+ - use the imperative, present tense: "change" not "changed" nor "changes"
+ - don't capitalize first letter
+ - no dot (.) at the end
+
+#### body
+
+The **body** provides more details, it should include the motivation for the change and contrast this with previous behavior.
+
+Just as in the subject, use the imperative, present tense: "change" not "changed" nor "changes"a
+
+#### footer (optional)
+
+The **footer** should contain any information about Breaking Changes introduced by this commit.
+
+This section must start with the upper case text `BREAKING CHANGE` followed by a colon (`:`) and a space (` `). A description must be provided, describing what has changed and how to migrate from older versions.
+
+## How to test infrastructure changes
+
+When making changes to project infrastructure, e.g. modifying `tsc` or `tslint`
+configuration, it's important to verify that all usage scenarios keep working.
+
+### Verify TypeScript setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Add a small bit of code to break TypeScript's type checks, for example:
+
+    ```ts
+    const foo: number = 'bar';
+    ```
+
+3. Run `npm test`
+
+4. Verify that the build failed and the compiler error message shows a path
+   relative to monorepo root, e.g. `packages/src/index.ts`.
+
+   _(2018-02-82: this is does not work now, `tsc` is reporting paths relative to individual package directories.)_
+
+5. Test integration with supported IDEs:
+    - [VS Code](./VSCode.md#how-to-verify-typescript-setup)
+
+### Verify TSLint setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Introduce two kinds linting problems - one that does and another that does not require type information to be detected. For example, you can add the following line at the end of the opened `index.ts`:
+
+    ```ts
+    const foo: any = 'bar';
+    ```
+
+3. Run `npm test`
+
+4. Verify that the build failed and both linting problems are reported:
+
+    ```text
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 7]: 'foo' is declared but its value is never read.
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 12]: Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type.
+    ```
+
+5. Test integration with supported IDEs:
+
+    - [VS Code](./VSCode.md#how-to-verify-tslint-setup)
+

docs/VSCODE.md

@@ -0,0 +1,93 @@
+# Developing with VisualStudio Code
+
+We recommend our contributors to use [VisualStudio Code](https://code.visualstudio.com/) with the following extensions installed:
+ - [Prettier - Code Formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode) for automatic formatting of source files on save.
+ - [TSLint](https://marketplace.visualstudio.com/items?itemName=eg2.tslint) to highlight and auto-fix linting problems directly in the editor.
+
+Our monorepo comes with few preconfigured [VSCode
+Tasks](https://code.visualstudio.com/docs/editor/tasks):
+
+ - The build task is configured to run the TypeScript compiler
+ - The test task is configured to run `npm test` (which runs the build before running any tests).
+
+## How to verify TypeScript setup
+
+### Compilation errors
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Add a small bit of code to break TypeScript's type checks, for example:
+
+    ```ts
+    const foo: number = 'bar';
+    ```
+
+3. Verify that VS Code editor has marked `foo` with a red underscore. Hover over `foo` and check the problem message. It should mention `[ts]` source, e.g.
+
+    ```text
+    [ts] Type '"bar"' is not assignable to type 'number'.
+
+    ```
+
+4. Check VS Code's [PROBLEMS Window](https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_errors-and-warnings).  There should be an entry showing the same tslint error. When you click on the entry, it should jump on the problematic line.
+
+5. Close the editor tab. (This will clear the PROBLEMS entry reported by TSLint extension).
+
+6. Run the test task ("Tasks: Run test task"). This will invoke package scripts like `npm test` under the hood.
+
+7. Open "Tasks" OUTPUT window and verify that compilation error was parsed by VSCode.
+
+8. Verify that compilation errors are correctly associated with the problematic source code line.
+   _(2018-02-82: this is does not work now, `tsc` is reporting paths relative to individual package directories.)_
+
+### Navigation in VS Code
+
+Verify that "Go to definition" works across package boundaries.  Find a place where we are calling `@inject` in `authentication` package, press F12 to go to the definition of `inject`. VSCode should jump to the `.ts` file in `src` (as opposed to jumping to a `.d.ts` file in `dist`)
+
+#### Refactoring in VS Code
+
+Verify that refactorings like "rename" will change all places using the renamed entity. Two different scenarios to verify: rename at the place where the entity is defined, rename at the place where the entity is used. (You can e.g. rename `inject` to test.)
+
+## How to verify TSLint setup
+
+1. Open any existing TypeScript file, e.g. `packages/src/index.ts`
+
+2. Verify that TSLint extension is not reporting any warnings in the output
+   window:
+    - pres _Cmd+shift+P_ or _Ctrl+shift+P_ to open task selector
+    - find and run the task `TSLint: Show Output`
+    - check the logs
+
+    An example of a warning we want to **avoid**:
+
+    ```text
+    Warning: The 'no-unused-variable' rule requires type information.
+    ```
+
+3. Introduce two kinds linting problems - one that does and another that does not require type information to be detected. For example, you can add the following line at the end of the opened `index.ts`:
+
+    ```ts
+    const foo: any = 'bar';
+    ```
+
+4. Verify that VS Code editor has marked `any` with a red underscore. Hover over `any` and check the problem message. It should mention `no-any` rule, e.g.
+
+    ```text
+    [tslint] Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type. (no-any)
+    ```
+
+5. Check VS Code's [PROBLEMS Window](https://code.visualstudio.com/docs/getstarted/tips-and-tricks#_errors-and-warnings).  There should be an entry showing the same tslint error. When you click on the entry, it should jump on the problematic line.
+
+6. Close the editor tab. (This will clear the PROBLEMS entry reported by TSLint extension).
+
+7. Run the test task ("Tasks: Run test task"). This will invoke package scripts like `npm test` under the hood.
+
+8. Open "Tasks" OUTPUT window and verify that two tslint problems were reported:
+
+    ```text
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 7]: 'foo' is declared but its value is never read.
+    ERROR: /Users/(...)/packages/core/src/index.ts[16, 12]: Type declaration of 'any' loses type-safety. Consider replacing it with a more precise type.
+    ```
+
+9. Open "PROBLEMS" window again. Verify that both problems were parsed by VS Code and are correctly associated with the problematic source code line.
+