Chore: Add issue/pr template and general housekeeping tools and docs (#900)

* Add linting

* Add issue templates and docs

* Add root eslint config and remove tslint

* Autofix lint issues

docs/development/coding-style.md

@@ -0,0 +1,52 @@
+# Coding Style
+
+These are the style guidelines for coding in Electron.
+
+You can run `yarn lint` to show any style issues detected by `tslint` and
+`eslint`.
+
+## General Code
+
+- End files with a newline.
+- Using a plain `return` when returning explicitly at the end of a function.
+  - Not `return null`, `return undefined`, `null` or `undefined`
+
+## Documentation
+
+- Write [remark](https://github.com/remarkjs/remark) markdown style.
+
+<!-- You can run `yarn lint-docs` to ensure that your documentation changes are
+formatted correctly. -->
+
+## TypeScript
+
+- Write [standard](https://www.npmjs.com/package/standard) JavaScript style.
+- File names should be concatenated with `-` instead of `_`, e.g.
+  `file-name.js` rather than `file_name.js`, because in
+  [github/atom](https://github.com/github/atom) module names are usually in
+  the `module-name` form. This rule only applies to `.js` files.
+- Use newer ES6/ES2015 syntax where appropriate
+  - [`const`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const)
+    for requires and other constants. If the value is a primitive, use uppercase naming (eg `const NUMBER_OF_RETRIES = 5`).
+  - [`let`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/let)
+    for defining variables
+  - [Arrow functions](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions)
+    instead of `function () { }`
+  - [Template literals](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals)
+    instead of string concatenation using `+`
+
+## Naming Things
+
+Electron APIs uses the same capitalization scheme as Node.js:
+
+- When the module itself is a class like `BrowserWindow`, use `PascalCase`.
+- When the module is a set of APIs, like `globalShortcut`, use `camelCase`.
+- When the API is a property of object, and it is complex enough to be in a
+  separate chapter like `win.webContents`, use `mixedCase`.
+- For other non-module APIs, use natural titles, like `<webview> Tag` or
+  `Process Object`.
+
+When creating a new API, it is preferred to use getters and setters instead of
+jQuery's one-function style. For example, `.getText()` and `.setText(text)`
+are preferred to `.text([text])`. There is a
+[discussion](https://github.com/electron/electron/issues/46) on this.

docs/styleguilde.md

@@ -0,0 +1,72 @@
+# rrweb Documentation Style Guide
+
+These are the guidelines for writing rrweb documentation.
+
+## Headings
+
+- Each page must have a single `#`-level title at the top.
+- Chapters in the same page must have `##`-level headings.
+- Sub-chapters need to increase the number of `#` in the heading according to
+  their nesting depth.
+- The page's title must follow [APA title case][title-case].
+- All chapters must follow [APA sentence case][sentence-case].
+
+Using `Quick Start` as example:
+
+```markdown
+# Quick Start
+
+...
+
+## Replay
+
+...
+
+## Record
+
+...
+
+## Events
+
+...
+
+### Understanding Events
+
+...
+
+### Custom Events
+
+...
+```
+
+For API references, there are exceptions to this rule.
+
+## Markdown rules
+
+This repository uses the [`markdownlint`][markdownlint] package to enforce consistent
+Markdown styling. For the exact rules, see the `.markdownlint.yaml` file in the root
+folder.
+
+There are a few style guidelines that aren't covered by the linter rules:
+
+<!--TODO(erickzhao): make sure this matches with the lint:markdownlint task-->
+
+- Use `sh` instead of `cmd` in code blocks (due to the syntax highlighter).
+- Keep line lengths between 80 and 100 characters if possible for readability
+  purposes.
+- No nesting lists more than 2 levels (due to the markdown renderer).
+- All `js` and `javascript` code blocks are linted with
+  [standard-markdown](https://www.npmjs.com/package/standard-markdown).
+- For unordered lists, use asterisks instead of dashes.
+
+## Picking words
+
+- Use "will" over "would" when describing outcomes.
+
+## Documentation translations
+
+When adding something to an English doc file, please add a translation if possible, or a placeholder in the respective \*.zh-CN.md files.
+
+[title-case]: https://apastyle.apa.org/style-grammar-guidelines/capitalization/title-case
+[sentence-case]: https://apastyle.apa.org/style-grammar-guidelines/capitalization/sentence-case
+[markdownlint]: https://github.com/DavidAnson/markdownlint