[docs] Add a maintainers document (#5938)

* Remove skip-ci article from docs

Skipping CI causes a hiccup in the PR merging and approval process.
Molly and I talked about this, and we probably need to revisit our
github process revolving around this, but since it is presently causing
an issue, it probably shouldn't be in the docs. We can always add it
back if we change our minds.

* Add a maintainers doc

This doc will give us a place to store information, like the discussion
that Molly and I had around skipping CI, so that anyone with Repo access
can find and contribute to how we run the project.

docs/maintainers/readme.md

@@ -0,0 +1,48 @@
+# Maintainer Processes
+
+This document contains basic instructions for the maintainers of the DEV
+application. It's a work in-progress, but should allow the DEV Core Team to
+document processes and strategies in a transparent way!
+
+# Skipping CI
+
+Some small PRs might seem like good candidates for skipping the CI suite. For
+example, a change that only touches documentation copy or a tiny CSS tweak.
+
+For the time being, we should avoid skipping CI in PRs because it causes some
+confusion during the review process. However, it does make sense to skip CI on
+merge commits that include extremely minor changes.
+
+You can skip CI by appending [ci skip] to merge commit's message.
+
+When in doubt, don't skip CI.
+
+# Pull Request Review
+
+At the moment, our PR review process is being evaluated, so this is subject to
+change.
+
+Before a PR is merged we expect:
+
+- every contributor to sign our CLA
+- all of the automated checks to pass
+- approval from at least two members of the Core Team
+
+PR review is the Core Team's opportunity to weigh-in on changes before they go
+into master.
+
+Keep in mind that our team is distributed across the world. It's a good idea to
+leave far-reaching PRs open for a day, to give everyone a change to share their
+thoughts.
+
+# Merging Pull Requests
+
+At the time of writing, we tend to prefer squashing PRs into a single commit and
+merging them. This is easily (and safely) achieved using the GitHub UI.
+
+# Deploying DEV
+
+If the application needs to be deployed when the code is merged, appending
+[deploy] to the merge commit's message will trigger a deploy.
+
+Generally, it's a good idea to keep the SRE team in the loop on any deploys.

docs/readme.md

@@ -7,13 +7,14 @@ items:
   - frontend
   - internal
   - design
-  - deployment.md
+  - deployment
   - tests
-  - contributing.md
-  - contributing_api.md
-  - faqs.md
-  - licensing.md
-  - self-hosting.md
+  - contributing
+  - contributing_api
+  - faqs
+  - licensing
+  - self-hosting
+  - maintainers
 ---
 
 # Welcome to DEV's developer documentation

docs/tests/readme.md

@@ -9,7 +9,6 @@ items:
   - regression-tests.md
   - code-coverage.md
   - codeclimate.md
-  - skip-ci.md
 ---
 
 We use the following testing tools:

docs/tests/skip-ci.md

@@ -1,18 +0,0 @@
----
-title: Skipping CI for minor changes
----
-
-# Skipping Continuous Integration
-
-It's almost always a good idea to let our [Continuous Integration][ci] tools do
-their work, but sometimes it can make sense to skip CI.
-
-In the case of extremely minor changes, like updating the project README or
-fixing a typo in the docs, you might want to skip CI by including `[ci skip]` in
-your commit message:
-
-```shell
-git commit -m "Fixed a typo in the testing docs [ci skip]"
-```
-
-[ci]: /deployment/