docs: add code of conduct and contributing documentation

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,23 @@
+<!--
+Thanks for reporting an issue!
+
+This issue tracker is for bugs and issues found within Lux core. If you require
+more general support please ask in the Gitter room http://bit.ly/2k4qS1k.
+
+Please fill in as much of the template below as you're able.
+
+Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
+Database: the RDBMS you are using (i.e SQLite3, MySQL, Postgres, etc.)
+Lux Version: the specified version in your `package.json` file
+Node Version: output of `node --version`
+
+If possible, please provide a stack trace and/or code that demonstrates the
+problem, keeping it as simple and free of external dependencies as you are able.
+-->
+
+*   **Platform**:
+*   **Database**:
+*   **Lux Version**:
+*   **Node Version**:
+
+<!-- Enter your issue details below this comment. -->

CODE_OF_CONDUCT.md

@@ -0,0 +1,95 @@
+# The Lux Code of Conduct
+
+## Conduct
+
+**Contact**: [lux@postlight.com](mailto:lux@postlight.com)
+
+*   We are committed to providing a friendly, safe and welcoming environment for
+all, regardless of level of experience, gender, gender identity and expression,
+sexual orientation, disability, personal appearance, body size, race, ethnicity,
+age, religion, nationality, or other similar characteristic.
+
+*   On Gitter, please avoid using overtly sexual nicknames or other nicknames
+that might detract from a friendly, safe and welcoming environment for all.
+
+*   Please be kind and courteous. There's no need to be mean or rude.
+
+*   Respect that people have differences of opinion and that every design or
+implementation choice carries a trade-off and numerous costs. There is seldom a
+right answer.
+
+*   Please keep unstructured critique to a minimum. If you have solid ideas you
+want to experiment with, make a fork and see how it works.
+
+*   We will exclude you from interaction if you insult, demean or harass anyone.
+That is not welcome behavior. We interpret the term "harassment" as including
+the definition in the [Citizen Code of Conduct](http://bit.ly/2jCvEok); if you
+have any lack of clarity about what might be included in that concept, please
+read their definition. In particular, we don't tolerate behavior that excludes
+people in socially marginalized groups.
+
+*   Private harassment is also unacceptable. No matter who you are, if you feel
+you have been or are being harassed or made uncomfortable by a community member,
+please contact one of the channel ops or any of the [Lux moderation team](mailto:lux@postlight.com)
+immediately. Whether you're a regular contributor or a newcomer, we care about
+making this community a safe place for you and we've got your back.
+
+*   Likewise any spamming, trolling, flaming, baiting or other attention-stealing
+behavior is not welcome.
+
+## Moderation
+
+These are the policies for upholding our community's standards of conduct. If you
+feel that a thread needs moderation, please contact the [Lux moderation team](mailto:lux@postlight.com).
+
+1.  Remarks that violate the Lux standards of conduct, including hateful, hurtful,
+oppressive, or exclusionary remarks, are not allowed. (Cursing is allowed, but
+never targeting another user, and never in a hateful manner.)
+
+2.  Remarks that moderators find inappropriate, whether listed in the code of
+conduct or not, are also not allowed.
+
+3.  Moderators will first respond to such remarks with a warning.
+
+4.  If the warning is unheeded, the user will be "kicked," i.e., kicked out of
+the communication channel to cool off.
+
+5.  If the user comes back and continues to make trouble, they will be banned,
+i.e., indefinitely excluded.
+
+6.  Moderators may choose at their discretion to un-ban the user if it was a first
+offense and they offer the offended party a genuine apology.
+
+7.  If a moderator bans someone and you think it was unjustified, please take it
+up with that moderator, or with a different moderator, **in private**. Complaints
+about bans in-channel are not allowed.
+
+8.  Moderators are held to a higher standard than other community members. If a
+moderator creates an inappropriate situation, they should expect less leeway than
+others.
+
+In the Lux community we strive to go the extra step to look out for each other.
+Don't just aim to be technically unimpeachable, try to be your best self. In
+particular, avoid flirting with offensive or sensitive issues, particularly if
+they're off-topic; this all too often leads to unnecessary fights, hurt feelings,
+and damaged trust; worse, it can drive people away from the community entirely.
+
+And if someone takes issue with something you said or did, resist the urge to be
+defensive. Just stop doing what it was they complained about and apologize. Even
+if you feel you were misinterpreted or unfairly accused, chances are good there
+was something you could've communicated better — remember that it's your responsibility
+to make your fellow community members comfortable. Everyone wants to get along and we
+are all here first and foremost because we want to talk about cool technology.
+You will find that people will be eager to assume good intent and forgive as long
+as you earn their trust.
+
+The enforcement policies listed above apply to all official Lux venues; including
+the official Gitter room ([*postlight/lux*](http://bit.ly/2k4qS1k)); GitHub
+repositories under postlight/lux such as Lux core and other Postlight repositories
+with a \*-lux or lux-\* naming convention; For other projects adopting the Lux
+Code of Conduct, please contact the maintainers of those projects for enforcement.
+If you wish to use this code of conduct for your own project, consider explicitly
+mentioning your moderation policy or making a copy with your own moderation policy
+so as to avoid confusion.
+
+*Adapted from the [Rust Code of Conduct](https://bit.ly/2jhrmEo).*

CONTRIBUTING.md

@@ -0,0 +1,248 @@
+# Contributing to Lux
+
+Thank you for your interest in contributing to Lux! This document will help
+answer any outstanding questions you may have about the contribution process.
+
+*Please read the [Code of Conduct](./CODE_OF_CONDUCT.md) before you participate
+in community.*
+
+## Contents
+
+*   [Reporting a Bug](#reporting-a-bug)
+*   [Requesting a Feature](#requesting-a-feature)
+*   [Development Workflow](#development-workflow)
+*   [Writing Documentation](#writing-documentation)
+*   [Submitting a Pull Request](#submitting-a-pull-request)
+*   [Helpful Links and Information](#helpful-links-and-information)
+
+## Reporting a Bug
+
+While bugs are unfortunate, they're a reality in software. We can't fix what we
+don't know about, so please report liberally. If you're not sure if something is
+a bug or not, feel free to file a bug anyway.
+
+If you have the chance, before reporting a bug, please search existing issues,
+as it's possible that someone else has already reported your error. This doesn't
+always work, and sometimes it's hard to know what to search for, so consider
+this extra credit. We won't mind if you accidentally file a duplicate report.
+
+Opening an issue is as easy as following [this link](https://github.com/postlight/lux/issues/new)
+and filling out the fields.
+
+## Requesting a Feature
+
+To request a change to the way that Lux works, please open an issue in the RFCs
+repository rather than this one. New features and other significant API changes
+must go through the RFC process. For more information about the RFC process, head
+over to the [lux-rfcs repository](https://github.com/postlight/lux-rfcs).
+
+## Development Workflow
+
+This section of the document outlines how to build, run, and test Lux locally.
+
+### Building
+
+![lux build](https://media.giphy.com/media/l0ExhMFcO0stlw0q4/giphy.gif)
+
+When a project that is built with Lux executes a command like `lux serve` it goes
+through a build process. During this build process, Lux core is also being built.
+The output of this build process is a bundled JavaScript file that includes only
+the parts of Lux core and your application that you actually use. This is known as
+tree shaking. Although saving bytes may not be necessary for server side applications,
+tree shaking can still help optimize application start time amongst other things.
+Technically speaking, Lux is not built until a project that uses Lux is built—so why
+build in development at all? Well, some parts of Lux core are required to be built and
+executable in the targeted Node.js version(s).
+
+To build the required modules for local development, execute the following commands:
+
+```bash
+# Clone this repository from GitHub.
+git clone https://github.com/postlight/lux.git
+
+# Navigate into the root of this repository.
+cd lux
+
+# Install local dependencies.
+npm install
+
+# Clean any build artifacts remaining from prior builds. This step is optional
+# and only makes sense if a build has already occurred.
+npm run clean
+
+# Run the build tools.
+npm run build
+
+# Symlink the lux-framework to the global node_modules directory. This ensures
+# that the "lux" command will use the files we just built instead of another
+# install.
+npm link
+```
+
+For general debugging and sanity checking code changes to Lux core, you can use
+the [test app](./test/test-app). To run the test app for the first time,
+execute the following commands:
+
+```bash
+# Navigate to the test/test-app directory from the root of this repository.
+cd test/test-app
+
+# Create the database schema.
+lux db:create
+
+# Run any pending database migrations.
+lux db:migrate
+
+# Seed the database with fixtures.
+lux db:seed
+
+# Run the application server.
+lux serve
+```
+
+### Testing
+
+First make sure you have built lux locally and it is symlinked to your global
+`node_modules` directory. Once you have completed the build steps, execute the
+following command:
+
+```bash
+# Run the test suite from the root of this repository.
+NODE_ENV="test" npm test
+```
+
+*NOTE:*
+
+Subsequent executions of the test suite can run without going through the build
+steps again.
+
+### Code Style
+
+#### Flow
+
+The Lux codebase is statically typed with [Flow](https://flowtype.org). This
+helps prevent many common bugs including ones caused by [unexpected type coercions](https://www.destroyallsoftware.com/talks/wat).
+
+If you have never written JavaScript with [Flow](https://flowtype.org) or
+[TypeScript](https://www.typescriptlang.org/) before, you may have a bit of a
+learning curve. If you get stuck on something, feel free to ask a question in the
+[*postlight/lux*](https://gitter.im/postlight/lux) and/or [*facebook/flow*](https://gitter.im/facebook/flow)
+Gitter room. We recommend installing an editor plugin with autocompletion and realtime error
+checking. Below you will find a few example plugins for many common editors.
+
+*   [Nuclide (Atom)](https://nuclide.io/)
+*   [FlowIDE (Sublime Text)](https://github.com/tptee/FlowIDE)
+*   [flow-for-vscode (Visual Studio Code)](https://github.com/flowtype/flow-for-vscode)
+*   [flow-for-emacs (Emacs)](https://github.com/flowtype/flow-for-emacs)
+*   [vim-flow (Vim)](https://github.com/flowtype/vim-flow)
+
+#### JavaScript
+
+We use a slightly modified version of the Airbnb JavaScript [Style Guide](https://github.com/airbnb/javascript).
+To enforce this, all pull requests that must pass [ESLint](http://eslint.org/)
+before they can merge.
+
+#### Markdown
+
+In addition to enforcing a JavaScript style guide, we also require that markdown
+files pass [remarklint](https://github.com/wooorm/remark-lint) with the recommended
+preset. This helps keep our markdown tidy, consistent, and compatible with a range of
+markdown parsers used for generating documentation.
+
+### Node.js Version Requirement
+
+Lux is built against Node `>= v6`. Since this is the latest LTS release and the
+version we run in our CI environments, we recommend you use it when working on
+the Lux codebase.
+
+If you use [nvm](https://github.com/creationix/nvm) to manage Node.js versions
+and zsh (like [Oh-My-ZSH](https://github.com/robbyrussell/oh-my-zsh)), you can
+have nvm switch to the correct Node.js version automatically when you cd into
+this repository. To do so, add the following to your `~/.zshrc` file:
+
+```bash
+# place this after nvm initialization!
+autoload -U add-zsh-hook
+load-nvmrc() {
+  local node_version="$(nvm version)"
+  local nvmrc_path="$(nvm_find_nvmrc)"
+
+  if [ -n "$nvmrc_path" ]; then
+    local nvmrc_node_version=$(nvm version "$(cat "${nvmrc_path}")")
+
+    if [ "$nvmrc_node_version" != "N/A" ] && [ "$nvmrc_node_version" != "$node_version" ]; then
+      nvm install
+    fi
+  elif [ "$node_version" != "$(nvm version default)" ]; then
+    echo "Reverting to nvm default version"
+    nvm use default
+  fi
+}
+add-zsh-hook chpwd load-nvmrc
+load-nvmrc
+```
+
+## Writing Documentation
+
+Improvements to documentation are a great way to start contributing to Lux. The
+sources for the official documentation is generated from source code comments
+and markdown files that live in this repository.
+
+The [Guide](https://lux.postlight.com/docs/latest/guide) section of the official
+documentation is generated from markdown files found in files within the[`./guide`](./guide)
+directory of this repository.
+
+The [API reference](https://lux.postlight.com/docs/latest/api) section of the official
+documentation is generated from source code comments found in files within the [`./src`](./src)
+directory of this repository.
+
+## Submitting a Pull Request
+
+Want to make a change to Lux? Submit a pull request! We use the "fork and pull"
+model [described here](https://help.github.com/articles/creating-a-pull-request-from-a-fork).
+
+**Before submitting a pull request**, please make sure you do the following:
+
+*   [X] You have added tests for modifications you made to the codebase.
+*   [X] You have updated any documentation in the source code comments for APIs
+that you may have changed.
+*   [X] You have no linter errors to correct after running `npm run lint`.
+*   [X] You have no type errors to correct after running `npm run flow`.
+*   [X] You have ran the test suite via `npm test` and it passed.
+
+### Commit Style
+
+Commit messages should follow the format outlined below:
+
+`prefix: message in present tense`
+
+ Prefix      | Description
+------------:|:-------------------------------------------------------------------------
+       chore | does not effect the production version of the app in any way.
+        deps | add, update, or remove a dependency.
+        docs | add, update, or remove documentation. no code changes.
+          dx | improve the development experience of lux core.
+        feat | a feature or enhancement. can be incredibly small.
+         fix | a bug fix for something that was broken.
+        perf | add, update, or fix a test.
+    refactor | change code, but not functionality.
+       style | change code style, like removing whitespace. no functional code changes.
+        test | add, update, or fix a test.
+
+### Code Reviews
+
+Once you have submitted a pull request, a member of the core team must review it
+before it is merged. We try to review pull requests within 3 days but sometimes
+fall behind. Feel free to reach out to someone in the [*postlight/lux*](https://gitter.im/postlight/lux)
+room on Gitter if you have not received a review after 3 days.
+
+## Helpful Links and Information
+
+Some useful places to look for information are:
+
+*   The [*postlight/lux*](https://gitter.im/postlight/lux) room on Gitter
+*   The official [guides and documentation](https://lux.postlight.com/docs/latest)
+*   Example applications in [this repository](./examples)
+
+*Adapted from [Contributing to Node.js](https://github.com/nodejs/node/blob/master/CONTRIBUTING.md)
+as well as [Contributing to Rust](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md).*