Typo in style example

.github/templates/agenda.md

@@ -0,0 +1,22 @@
+**NOTE: This meeting is on Thursday at 9am - 10am PT**
+
+Zoom Meeting link: [https://zoom.us/j/975841675](https://zoom.us/j/975841675?pwd=SUh4MjRLaEFKNlI3RElpWTdhRDVVUT09). Dial-in passcode: 763054 - [Code-of-Conduct](https://github.com/OAI/OpenAPI-Specification/blob/main/CODE_OF_CONDUCT.md#code-of-conduct)
+
+In order to give some more visibility into the topics we cover in the TDC meetings here is the planned agenda for the next meeting.  Hopefully this will allow people to plan to attend meetings for topics that they have an interest in.  And for folks who cannot attend they can comment on this issue prior to the meeting.  Feel free to suggest other potential agenda topics.
+
+**Please submit comments below for topics or proposals that you wish to present in the TDC meeting**
+
+![F10B5460-B4B3-4463-9CDE-C7F782202EA9](https://user-images.githubusercontent.com/21603/121568843-0b260900-ca18-11eb-9362-69fda4162be8.jpeg)
+
+The agenda backlog is currently maintained in issue #2482
+
+| Topic | Owner | Decision/NextStep |
+|-------|---------|---------|  
+| | | |
+Reports from Special Interest Groups | TDC | |
+AOB (see below) | TDC | |
+New issues / PRs labelled [review](https://github.com/OAI/OpenAPI-Specification/labels/review) | @OAI/triage | |
+[New issues](https://github.com/search?q=repo%3Aoai%2Fopenapi-specification+is%3Aissue+comments%3A0+no%3Alabel+is%3Aopen) without response yet | @OAI/triage  | |
+
+
+/cc @OAI/tsc Please suggest items for inclusion

.github/workflows/agenda.yaml

@@ -0,0 +1,29 @@
+name: agenda
+
+# author: @MikeRalphson
+# issue: various
+
+#
+# This workflow creates the agenda issue each week. It runs on a cron every
+# Monday morning, raising an issue for the following Thursday.
+# It can also be run manually, in case GitHub Actions has a failure.
+#
+
+on:
+  schedule:
+    - cron: '0 16 * * 4'
+  workflow_dispatch: {}
+
+jobs:
+  agenda:
+    env:
+      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1 # checkout repo content
+
+    - name: Create agenda issue
+      run: gh issue create -l Housekeeping -t "Open Community (TDC) Meeting, `date --date='next Thu' +'%A %d %B %Y'`" -F .github/templates/agenda.md
+

.github/workflows/convert-examples-to-json.yaml

@@ -10,19 +10,19 @@ name: convert-examples-to-json
 # Only the YAML files should be adjusted manually.
 #
 
-# run this on push to master
+# run this on push to main
 on:
   push:
     branches:
-      - master
+      - main
 
 jobs:
   yaml2json:
 
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v1 # checkout repo content
+    - uses: actions/checkout@v2 # checkout repo content
 
     - name: Install dependencies
       run: npm i
@@ -36,10 +36,9 @@ jobs:
         git --no-pager -c color.diff=always diff --staged
 
     - name: Create Pull Request
-      uses: peter-evans/create-pull-request@v1
+      uses: peter-evans/create-pull-request@v3
       with:
         token: ${{ secrets.GITHUB_TOKEN }}
-        branch-suffix: none
         branch: update-json-examples
         title: Update JSON example files
         commit-message: Update JSON example files

.github/workflows/respec.yaml

@@ -0,0 +1,57 @@
+name: respec
+
+# author: @MikeRalphson
+# issue: https://github.com/OAI/OpenAPI-Specification/issues/1564
+
+#
+# This workflow updates the respec 'pretty' rendered versions of the spec 
+# on the gh-pages branch when the corresponding markdown files change.
+#
+
+# run this on push to main
+on:
+  push:
+    branches:
+      - main
+  workflow_dispatch: {}
+
+jobs:
+  respec:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v2 # checkout main branch
+      with:
+        fetch-depth: 0
+
+    - name: Install dependencies
+      run: npm i
+
+    - uses: actions/checkout@v2 # checkout gh-pages branch
+      with:
+        ref: gh-pages
+        path: deploy
+
+    - name: run main script
+      run: scripts/md2html/build.sh
+
+    - name: Create Pull Request
+      uses: peter-evans/create-pull-request@v3
+      with:
+        token: ${{ secrets.GITHUB_TOKEN }}
+        branch: update-respec-version
+        base: gh-pages
+        delete-branch: true
+        path: deploy
+        labels: Housekeeping
+        reviewers: webron,darrelmiller
+        title: Update ReSpec versions
+        commit-message: Update ReSpec versions
+        signoff: true
+        body: |
+          This pull request is automatically triggered by GitHub action `respec`.
+
+          The versions/v*.md files have changed, so the HTML files are automatically being regenerated.
+
+

.github/workflows/schema-tests.yaml

@@ -0,0 +1,31 @@
+name: schema-test
+
+# Author: @MikeRalphson / runs @jdesrosiers tests
+# Issue: https://github.com/OAI/OpenAPI-Specification/pull/2489
+
+#
+# This workflow runs the npm test script to validate passing and failing
+# testcases for the metaschema.
+#
+
+# run this on push to any branch and creation of pull-requests
+on: 
+  push: {}
+  pull_request: {}
+  workflow_dispatch: {}
+
+jobs:
+  test:
+
+    runs-on: ubuntu-latest
+
+    steps:
+    - uses: actions/checkout@v1 # checkout repo content
+    - uses: actions/setup-node@v1 # setup Node.js
+      with:
+        node-version: '14.x'
+    - name: Install dependencies
+      run: npm i
+    - name: Run tests
+      run: npm run test
+

.github/workflows/validate-markdown.yaml

@@ -18,10 +18,10 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-    - uses: actions/checkout@v1 # checkout repo content
+    - uses: actions/checkout@v2 # checkout repo content
     - uses: actions/setup-node@v1 # setup Node.js
       with:
-        node-version: '12.x'
+        node-version: '14.x'
     - name: Validate markdown
       run: npx mdv versions/3.*.md
 

.gitignore

@@ -6,4 +6,6 @@ target
 atlassian-ide-plugin.xml
 node_modules/
 package-lock.json
+deploy/
+history
 Gemfile.lock

CODE_OF_CONDUCT.md

@@ -94,13 +94,50 @@ offender, banning the offender from various online spaces (temporary or
 permanent), removing the offender from an event with no refund, or other
 options deemed appropriate.
 
-Further details of specific enforcement policies are currently being
-drafted. When these details are completed we will post updates to our
-website for transparency.
-
-Project maintainers who do not report possible incidents or follow
-responses in good faith may face temporary or permanent repercussions as
-determined by the Code of Conduct Committee.
+Enforcement Guidelines
+----------------------
+
+The Code of Conduct committee will follow these Enforcement Guidelines in 
+determining the consequences for any action they deem in violation of this 
+Code of Conduct:
+
+#### 1. Correction
+Community Impact: Use of inappropriate language or other behavior deemed 
+unprofessional or unwelcome in the community.
+
+Consequence: A private, written warning from the Code of Conduct committee, 
+providing clarity around the nature of the violation and an explanation of 
+why the behavior was inappropriate. A public apology may be requested.
+
+#### 2. Warning
+Community Impact: A violation through a single incident or series of 
+actions.
+
+Consequence: A warning with consequences for continued behavior. No 
+interaction with the people involved, including unsolicited interaction 
+with the Code of Conduct committee, for a specified period of time. This 
+includes avoiding interactions in community spaces as well as external 
+channels like social media. Violating these terms may lead to a temporary 
+or permanent ban.
+
+#### 3. Temporary Ban
+Community Impact: A serious violation of community standards, including 
+sustained inappropriate behavior.
+
+Consequence: A temporary ban from any sort of interaction or public 
+communication with the community for a specified period of time. No 
+public or private interaction with the people involved, including 
+unsolicited interaction with the Code of Conduct committee, is allowed 
+during this period. Violating these terms may lead to a permanent ban.
+
+#### 4. Permanent Ban
+Community Impact: Demonstrating a pattern of violation of community 
+standards, including sustained inappropriate behavior, harassment of 
+an individual, or aggression toward or disparagement of classes of 
+individuals.
+
+Consequence: A permanent ban from any sort of public interaction 
+within the community.
 
 ### Events
 

DEVELOPMENT.md

@@ -24,7 +24,7 @@ The specification *will evolve over time*. Changes  may be made when any of the
 
 For each change in the specification we should *always* consider the following:
 
-* Migration. Is this a construct that has a path from the existing 2.0 specification? If so, how complicated is it to migrate to the proposed change?
+* Migration. Is this a construct that has a path from the [existing specification](https://github.com/OAI/OpenAPI-Specification/releases))? If so, how complicated is it to migrate to the proposed change?
 
 * Tooling. Strive to support code generation, software interfaces, spec generation techniques, as well as other utilities. Some features may be impossible to support in different frameworks/languages. These should be documented and considered during the change approval process.
 
@@ -36,19 +36,19 @@ Spec changes should be approved by a majority of the committers. Approval can be
 
 * GitHub is the medium of record for all spec designs, use cases, and so on.
 
-* As with 2.0, the **human readable** document is the source of truth. If using a JSON Schema again to document the spec, it is secondary to the human documentation. The documentation should live in a *.md file, in parallel to the 2.0 document (versions/3.0.0.md for example).
+* The **human readable** document is the source of truth. If using a JSON Schema again to document the spec, it is secondary to the human documentation. The documentation should live in a *.md file, in parallel to the latest document (versions/3.0.0.md for example).
 
 * At any given time, there would be *at most* 4 work branches. The branches would exist if work has started on them. Assuming a current version of 3.0.0:
 
-    * master - Current stable version. No PRs would be accepted directly to modify the specification. PRs against supporting files can be accepted.
+    * main - Current stable version. No PRs would be accepted directly to modify the specification. PRs against supporting files can be accepted.
 
     * v3.0.1-dev - The next PATCH version of the specification. This would include non-breaking changes such as typo fixes, document fixes, wording clarifications.
 
     * v3.1.0 - The next MINOR version.
 
     * v4.0.0 - The next MAJOR version.
 
-* The master branch shall remain the current, released OpenAPI Specification. We will describe and link the work branch(es) on the **default** README.md on master.
+* The main branch shall remain the current, released OpenAPI Specification. We will describe and link the work branch(es) on the **default** README.md on main.
 
 * Examples of how something is described *currently* vs. the proposed solution should accompany any change proposal.
 
@@ -62,11 +62,11 @@ Spec changes should be approved by a majority of the committers. Approval can be
 
 * Not all committers will contribute to every single proposed change. There may be many open proposals at once, and multiple efforts may happen in parallel.
 
-* When the work branch is ready and approved, the branch will be merged to master.
+* When the work branch is ready and approved, the branch will be merged to main.
 
 ## Release Process
 
-A release requires a vote on the release notes by TSC members within the voting period. Major or minor release voting periods will be announced by the Liaison in the Slack channel and noted on the calendar at least 6 days in advance. During this time, TSC members who have not yet voted must note their approval on the GitHub pull request for the release notes. Patch releases happen at the first TSC meeting of a calendar month. The Liaison is responsible for coordinating the actual merge to Master with marketing support, if any.
+A release requires a vote on the release notes by TSC members within the voting period. Major or minor release voting periods will be announced by the Liaison in the Slack channel and noted on the calendar at least 6 days in advance. During this time, TSC members who have not yet voted must note their approval on the GitHub pull request for the release notes. Patch releases happen at the first TSC meeting of a calendar month. The Liaison is responsible for coordinating the actual merge to main with marketing support, if any.
 
 * Patch-level releases require majority approval by TSC members. (Max voting period 3 days)