Spike out some internal documentation for Jekyll processes.

docs/avoiding-burnout.md

@@ -0,0 +1,3 @@
+# Maintainers: Avoiding Burnout
+
+**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.

docs/becoming-a-maintainer.md

@@ -0,0 +1,3 @@
+# Contributors: Becoming a Maintainer
+
+**This guide is for contributors.** These special people have contributed to one or more of Jekyll's repositories, but do not yet have write access to any. You may find what is written here interesting, but it’s definitely not for everyone.

docs/merging-a-pull-request.md

@@ -0,0 +1,52 @@
+# Maintainers: Merging a Pull Request
+
+**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
+
+## Code Review
+
+All pull requests should be subject to code review. Code review is a [foundational value](https://blog.fullstory.com/what-we-learned-from-google-code-reviews-arent-just-for-catching-bugs-b125a13aa292) of good engineering teams. Besides providing validation of correctness, it promotes a sense of community and gives other maintainers understanding of all parts of the code base. In short, code review is crucial to a healthy open source project.
+
+Before merging a pull request **that changes code**, ensure that code is thoroughly reviewed and has received a thorough review from at least two maintainers.
+
+Before merging a pull request **that changes the documentation**, ensure there aren't any errors and that at least one other maintainer has agreed on the changes.
+
+## Merging
+
+We have [a helpful little bot](https://github.com/jekyllbot) which we use to merge pull requests. We don't use the GitHub.com interface for two reasons:
+
+1. You can't modify anything on mobile (e.g. titles, labels)
+2. Provide a consistent paper trail in the `History.markdown` file for each release
+
+To merge a pull request, leave a comment thanking the contributor, then add the special merge request:
+
+```text
+Thank you very much for your contribution. Folks like you make this project and community strong. :heart:
+
+@jekyllbot: merge +dev
+```
+
+The merge request is made up of three things:
+
+1. `@jekyllbot:` – this is the prefix our bot looks for when processing commands
+2. `merge` – the command
+3. `+dev` – the category to which the changes belong
+
+The categories match the H3's in the history/changelog file, and they are:
+
+1. Major Enhancements (`+major`) – major updates or breaking changes to the code which necessitate a major version bump (v3 ~> v4)
+2. Minor Enhancements (`+minor`) – minor updates (feature, enhancement) which necessitate a minor version bump (v3.1 ~> v3.2)
+3. Bug Fixes (`+bug`) – corrections to code which do not change or add functionality, which necessitate a patch version bump (v3.1.0 ~> v3.1.1)
+4. Site Enhancements (`+site`) – changes to the source of https://jekyllrb.com, found in `site/`
+5. Development Fixes (`+dev`) – changes which do not affect user-facing functionality or documentation, such as test fixes or bumping internal dependencies
+
+Once @jekyllbot has merged the pull request, you should see three things:
+
+1. A successful merge
+2. Addition of labels for the necessary category if they aren't already applied
+3. A commit to the `History.markdown` file which adds a note about the change
+
+If you forget the category, that's just fine. You can always go back and move the line to the proper category header later. The category is always necessary for `jekyll/jekyll`, but many plugins have too few changes to necessitate changelog categories.
+
+## Rejoice
+
+You did it! Thanks for being a maintainer for one of our official Jekyll projects. Your work means the world to our thousands of users who rely on Jekyll daily. :heart:

docs/readme.md

@@ -0,0 +1,12 @@
+# Maintaining Jekyll
+
+Hello! This is where we document various processes for maintaining Jekyll. Being a maintainer for any Jekyll project is a big responsibility, so we put together some helpful documentation for various tasks you might do as a maintainer.
+
+1. [Triaging and issue](triaging-an-issue.md)
+2. [Reviewing a pull request](reviewing-a-pull-request.md)
+3. [Merging a pull request](merging-a-pull-request.md)
+4. [Avoiding burnout](avoiding-burnout.md)
+
+Interested in becoming a maintainer? Here is some documentation for **contributors**:
+
+1. [Becoming a maintainer](becoming-a-maintainer.md)

docs/reviewing-a-pull-request.md

@@ -0,0 +1,4 @@
+# Maintainers: Reviewing a Pull Request
+
+**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
+

docs/triaging-an-issue.md

@@ -0,0 +1,9 @@
+# Maintainers: Triaging an Issue
+
+**This guide is for maintainers.** These special people have **write access** to one or more of Jekyll's repositories and help merge the contributions of others. You may find what is written here interesting, but it’s definitely not for everyone.
+
+Here are some key things to remember when evaluating an issue.
+
+## Reproducible?
+
+If the bug has clear reproduction steps, take a minute to try them.