ci: add workflow to fetch contrib docs nightly

.github/workflows/CI.yml

@@ -4,6 +4,8 @@ on:
   push:
     branches:
       - master
+    paths-ignore:
+      - "_contrib/**"
 
 env:
   RUST_BACKTRACE: 1

.github/workflows/contrib.yml

@@ -0,0 +1,97 @@
+name: contrib
+on:
+  schedule:
+    - cron: '15 3 * * *'
+  workflow_dispatch:
+
+permissions:
+  contents: write # to update _contrib
+  pull-requests: write # to send the updated _contrib PRs
+
+jobs:
+  update-contrib:
+    name: Update _contrib
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout website
+        uses: actions/checkout@v3
+        with:
+          persist-credentials: false
+
+      - name: Checkout hyper
+        uses: actions/checkout@v3
+        with:
+          persist-credentials: false
+          repository: hyperium/hyper
+          path: hyper
+
+      - name: Copy CONTRIBUTING.md into docs
+        run: |
+          sed -i -e 's|./docs/||g' hyper/CONTRIBUTING.md
+          cp -a hyper/CONTRIBUTING.md hyper/docs
+
+      # Insert frontmatter borders, replace markdown header with
+      # frontmatter title and insert layout: guide
+      - name: Convert doc titles to frontmatter 
+        run: |
+          for f in hyper/docs/*.md; do
+            sed -i -e '1i ---' \
+            -e '1s/#/title:/' \
+            -e '2i layout: guide' \
+            -e '2i ---' $f;
+          done
+
+      # Use the hyper docs readme as the index page of contrib,
+      # and insert permalink: /contrib/ in the frontmatter
+      - name: Convert readme to index
+        run: |
+          sed -i -e '4i permalink: /contrib/' hyper/docs/README.md
+          mv hyper/docs/README.md hyper/docs/index.md
+
+      # Lowercase the internal links so they will correctly point to
+      # the lowercased filenames.
+      - name: Lowercase internal links
+        run: |
+          for filename in hyper/docs/*.md; do
+            # cut `.md` from the filename before search and replace
+            filename=${filename::-3};
+
+            for file in hyper/docs/*.md; do
+              # don't lowercase MSRV
+              if [[ "${filename##*/}" == 'MSRV' ]]; then
+                continue
+              fi
+
+              # match instances of only the filename, not including
+              # the parent path, and convert them to lowercase
+              sed -i -e "s|${filename##*/}|\L\0|g" $file;
+            done
+          done
+
+      - name: Lowercase filenames and replace underscores
+        run: |
+          for f in hyper/docs/*; do
+            mv -vn "$f" "$(echo "$f" | tr '[:upper:]' '[:lower:]' | tr '_' '-')"; 
+          done
+
+      - name: Copy docs to contrib
+        run: |  
+          mkdir -p _contrib
+          cp -a hyper/docs/. _contrib/
+
+      - uses: gr2m/create-or-update-pull-request-action@v1
+        env:
+          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+        with:
+          author: github-actions <github-actions@github.com>
+          branch: actions/update-contrib
+          title: 'doc: update contrib docs'
+          body: >
+            The _contrib docs are likely out of date. This is an automatically 
+            generated PR by the `contrib.yml` GitHub workflow, which clones the docs
+            from the main repo, implements the changes in _contrib then submits a new 
+            PR or updates an existing PR.
+          commit-message: 'doc: update contrib docs'
+          path: _contrib/
+

_config.yml

@@ -11,12 +11,17 @@ defaults:
     values:
       layout: "guide"
   -
-
     scope:
       path: "_stable/"
       type: "guides"
     values:
       layout: "guide"
+  -
+    scope:
+      path: "_contrib/"
+      type: "guides"
+    values:
+      layout: "guide"
 
 
 collections:
@@ -29,6 +34,9 @@ collections:
   posts:
     permalink: /blog/:year/:month/:day/:title/
     output: true
+  contrib:
+    permalink: /contrib/:path/
+    output: true
 
 # Build settings
 markdown: kramdown

_contrib/code-of-conduct.md

@@ -0,0 +1,24 @@
+---
+title: Code of Conduct
+layout: guide
+---
+
+## Be Kind
+
+- Don't be mean.
+- Insulting anyone is prohibited.
+- Harassment of any kind is prohibited.
+- If another person feels uncomfortable with your remarks, stop it.
+- If a moderator deems your comment or conduct as inappropriate, stop it.
+- Disagreeing is fine, but keep it to technical arguments. Never attack the person.
+- Give the benefit of the doubt. Assume good intentions.
+- Show empathy. There are 3 interpretations to any message: what we thought, what we said, and what they understand.
+- This does mean we exclude people who are not kind. We are happy to make that sacrifice.
+
+## Or Else
+
+- Violations of the Code of Conduct will result in 1 warning.
+- If the violation is major, a moderator may just ban immediately.
+- If a warning has already been given, a moderator will ban the offender.
+- There is no process for appealing a ban.
+- Any violations can be reported to sean@seanmonstar.com.

_contrib/commits.md

@@ -0,0 +1,68 @@
+---
+title: Git Commit Guidelines
+layout: guide
+---
+
+We have very precise rules over how our git commit messages can be formatted.  This leads 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 the change log**.
+
+## 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**, a **scope** and a **subject**:
+
+```
+<type>(<scope>): <subject>
+<BLANK LINE>
+<body>
+<BLANK LINE>
+<footer>
+```
+
+Any line of the commit message cannot be longer 100 characters! This allows the message to be easier
+to read on github as well as in various git tools.
+
+## 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 or adds a feature
+* **perf**: A code change that improves performance
+* **test**: Adding missing tests
+* **chore**: Changes to the build process or auxiliary tools and libraries such as documentation
+    generation
+
+## Scope
+The scope should refer to a module in hyper that is being touched. Examples:
+
+* client
+* server
+* http1
+* http2
+* ffi
+* upgrade
+* examples
+
+## 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
+
+Just as in the **subject**, use the imperative, present tense: "change" not "changed" nor "changes"
+The body should include the motivation for the change and contrast this with previous behavior.
+
+## Footer
+
+The footer should contain any information about **Breaking Changes** and is also the place to
+reference GitHub issues that this commit **Closes**.
+
+The last line of commits introducing breaking changes should be in the form `BREAKING CHANGE: <desc>`

_contrib/contributing.md

@@ -0,0 +1,14 @@
+---
+title: Contributing to Hyper
+layout: guide
+---
+
+You want to contribute? You're awesome! Don't know where to start? Check the [list of easy issues](https://github.com/hyperium/hyper/issues?q=is%3Aopen+is%3Aissue+label%3AE-easy).
+
+[easy tag]: https://github.com/hyperium/hyper/issues?q=label%3AE-easy+is%3Aopen
+
+
+## [Pull Requests](pull_requests.md)
+
+- [Submitting a Pull Request](pull_requests.md#submitting-a-pull-request)
+- [Commit Guidelines](commits.md)

_contrib/governance.md

@@ -0,0 +1,114 @@
+---
+title: Governance
+layout: guide
+---
+
+## Making decisions
+
+There's two main pieces to the way decisions are made in hyper:
+
+1. A decision-making framework
+2. The people who apply it
+
+The people are described [lower down in this document](#roles).
+
+### Decision-making framework
+
+We start with the users. The project wouldn't exist without them, and it exists
+in order to enable users to do amazing things with HTTP. We listen to our
+users. Some actively contribute their thoughts, but many others we must seek
+out to learn about their usage, joys, and headaches. Those insights allow our
+experts to determine the best solutions for the users.
+
+We then define a set of [tenets](./tenets.md), which are guiding principles
+that can be used to measure aspects of individual decisions. It should be
+possible to identify one or more tenets that apply to why a decision is made.
+And the set helps us balance which priorities are more important for our users.
+
+We combine the usecases with the tenets to come up with a [vision](./vision.md)
+that provides a longer-term plan of what hyper _should_ look like.
+
+Finally, we define a [roadmap](./roadmap.md) that describes what the
+short-term, tactical changes to bring hyper closer in line with the vision.
+
+## Roles
+
+These are the roles people can fill when participating in the project. A list
+of the people in each role is available in [maintainers](./maintainers.md).
+
+### Contributor
+
+A contributor is anyone who contributes their time to provide value for the
+project. This could be in the form of code, documentation, filing issues,
+discussing designs, or helping others on the issue tracker or in chat.
+
+All contributors MUST follow the [Code of Conduct][coc].
+
+👋  **New here?** [This could be you!][contrib]
+
+
+### Triager
+
+Triagers assess issues on the issue tracker. They help make sure the work is
+well organized, and are critical for making new issue reporters feeling
+welcome.
+
+Responsibilities:
+
+- Adhere to the [Code of Conduct][coc]
+- Follow the [triager's guide][triage-guide]
+
+Privileges:
+
+- Can edit, label, and close issues
+- Member of the organization
+- Can be assigned issues and pull requests
+
+How to become:
+
+- Make a few [contributions][contrib] to the project, to show you can follow
+  the [Code of Conduct][coc].
+- Self-nominate by making a pull request adding yourself to the
+  [list](./maintainers.md#triagers).
+
+
+### Collaborator
+
+Collaborators are contributors who have been helping out in a consistent basis.
+
+Responsibilities:
+
+- Be exemplars of the [Code of Conduct][coc]
+- Internalize the [vision](./vision.md)
+- Reviewing pull requests from other contributors
+- Provide feedback on proposed features and design documents
+- [Welcome new contributors][triage-guide]
+- Answer questions in issues and/or chat
+- Mentor contributors to become members
+
+Privileges:
+
+- Can review and merge pull requests
+- Can trigger re-runs of CI, and approve CI for first-time contributors
+- Can assign issues and pull requests to other organization members
+
+How to become:
+
+- Work at fulfilling the above responsibilities.
+- Any collaborator may nominate a contributor who has been around for some time
+  and is already filling the responsibilities.
+- Another collaborator must second the nomination.
+- If there are no objections, a maintainer will welcome the new collaborator.
+
+Don't be afraid to ask a collaborator for what you could work on to reach this
+goal!
+
+### Maintainer
+
+Maintainers are the project admins. Besides being a collaborator, they take care
+of house-keeping duties, help lead the direction, and have the final authority when
+required.
+
+[coc]: ./code_of_conduct.md
+[contrib]: ../contributing.md
+[triage-guide]: ./issues.md#triaging

_contrib/index.md

@@ -0,0 +1,7 @@
+---
+title: Developing hyper
+layout: guide
+permalink: /contrib/
+---
+
+This is a set of documents outline how hyper is developed, how to contribute or get involved, various processes we use, and internal design explanations.