Merge pull request #2 from OAI/master

Updating master from upstream repo

Author: tedepstein

.travis.yml

@@ -9,10 +9,11 @@ matrix:
     - env: VALIDATORS=tv4
 install:
   - rm -rf ~/.nvm
+  - mkdir -p ~/.nvm
   - curl -L https://raw.githubusercontent.com/creationix/nvm/master/install.sh | sh
   - source ~/.nvm/nvm.sh
-  - nvm install 6.1
-  - nvm use 6.1
+  - nvm install 8
+  - nvm use 8
 script:
   - npm install
   - node node_modules/mdv/mdv versions/3.*.md

DEVELOPMENT.md

@@ -1,6 +1,6 @@
 ## Development Guidelines
 
-This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The Open API Technical Developer Community will initially follow these processes when merging changes from external contributors or from the TDC itself. This guideline document will be adjusted as practicality dictates.
+This document intends to establish guidelines which build a transparent, open mechanism for deciding how to evolve the OpenAPI Specification. The Open API Technical Steering Committee (TSC) will initially follow these processes when merging changes from external contributors or from the TSC itself. This guideline document will be adjusted as practicality dictates.
 
 ## OAI Specification Driving factors
 
@@ -43,7 +43,7 @@ For each change in the specification we should _always_ consider the following:
  - Tooling.  Strive to support code generation, software interfaces, and spec generation techniques.  Some features may be impossible to support in different frameworks/languages.  These should be documented and considered during the change approval process.
  - Visualization.  Can the specification change be graphically visualized somehow in a UI or other interface?
 
-Spec changes should be approved by a majority of the committers.  Approval can be given by commenting on the issue itself, for example, "Approved by @fehguy".  After voting criteria is met, any committer can merge the PR. (**TODO**: we will want to formalize what voting criteria actually is).
+Spec changes should be approved by a majority of the committers.  Approval can be given by commenting on the issue itself, for example, "Approved by @webron".  After voting criteria is met, any committer can merge the PR. (**TODO**: we will want to formalize what voting criteria actually is).
 
 No change should be approved until there is documentation for it, supplied in an accompanying PR.
 

GOVERNANCE.md

@@ -0,0 +1,31 @@
+# Governance
+
+The OpenAPI Specification is a project of the Open API Initiative (OAI), under the auspices of the Linux Foundation. For governance of the OAI, review the [OAI's charter](https://www.openapis.org/participate/how-to-contribute/governance).
+
+# Processes and procedures of the Technical Steering Committee (TSC)
+
+The TSC is a self-organizing sub-group of the OAI. Herein are its principles and guidelines.
+
+## 1. The establishment of roles and the responsibilities for each role
+
+Roles:
+
+* [Liaison](https://www.merriam-webster.com/dictionary/liaison) — Elected by TSC members in a plurality vote (oral count). Liaison represents the TSC to the OAI's Business Governing Board (BGB) at board meetings (though this itself does not confer voting rights) and is the public facing mouthpiece of the TSC.
+
+* [Maintainer](https://www.merriam-webster.com/dictionary/maintainer) — all and only members of the TSC are maintainers, and are responsible for approving proposed changes to the specification. If membership drops below 3, work is suspended until the BGB can re-establish the minimum. To maintain agility, the TSC should be capped at a maximum 9 members, though that number can be reconsidered by the TSC in the future. Past members will be noted as emeritus status once they are no longer members. 
+
+* [Rick](https://www.youtube.com/watch?v=dQw4w9WgXcQ) — Responsible for not giving up or letting down. Requires plurality vote of TSC members.
+
+## 2. Adding members to the TSC
+
+A call-for-nominations period may be agreed upon by the TSC voting members and announced in a timely manner through [@OpenApiSpec](https://twitter.com/OpenApiSpec) on Twitter, assuming the TSC membership is not already at its maximum. A candidate may be nominated through a motion by a voting TSC member in a closed TSC meeting. A nominee must not receive opposition votes of more than 25% of the TSC voting membership via a confidential vote held electronically within a week following the nomination meeting. Approved nominees become provisional members and are expected to comport themselves as full members of the TSC during the provisional period of 4-6 weeks (to be determined at start of each nominating period), though nominees have no voting rights. The provisional period is concluded by a second, confidential vote similar to the nomination period's vote. At most there are four voting periods per year (no more than one every three months), with a minimum of one per year.
+
+## 3. Removal of membership from the TSC
+
+In dire situations, it may be necessary to remove a TSC member, such as behavior that violates the code of conduct (NB: whether non-participation merits removal is a decision left to the TSC voting members). 75% vote (confidential, electronic) of the other TSC members is required to remove a member. Otherwise, TSC members are removed when they renounce their position by informing the Liaison of their effective resignation date.
+
+## 4. Criteria for decisions
+
+The group will strive to achieve all decisions via unopposed consensus. When not possible, unresolved conflicts will be raised to the OAI's Technical Oversight Board (TOB).
+
+The TSC will maintain a publicly available document specifying the process in the contributor guidelines for how proposed changes are merged into the specification. The TSC will document and publicize the schedule of merge parties and release parties for the benefit of the developer community.

IMPLEMENTATIONS.md

@@ -2,46 +2,60 @@
 
 Below is a list of known tooling that implements the 3.0.0 specification. While support for the 3.0.0 specification matures,  refer to the details of projects listed below for any notes about stability and roadmap.  The process to improve the 3.x specification includes feedback from end-users and tooling creators. We strongly encourage draft tooling be made available for early users of OAS drafts.
 
-These tools are not necessarily endorsed by the OAI.
+These tools are not endorsed by the OAI.
 
 #### Low-Level tooling
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| swagger-parser | [GitHub/swagger-api](https://github.com/swagger-api/swagger-parser/tree/feature/3.0.0-rc0) | Java | Swagger 1.0, 1.1, 1.2, 2.0 to Open API Specification converter |
-| swagger-models | [GitHub/swagger-api](https://github.com/swagger-api/swagger-core/tree/feature/3.0.0-rc0/modules/swagger-models) | Java | Open API 3.0 Java Pojos |
-| KaiZen OpenAPI Parser | [GitHub/RepreZen/KaiZen-OpenAPI-Parser](https://github.com/RepreZen/KaiZen-OpenAPI-Parser) | Java | High-performance Parser, Validator, and Java Object Model for OpenAPI 3.x |
-| openapi3-ts | [GitHub/metadevpro/openapi3-ts](https://github.com/metadevpro/openapi3-ts) | TypeScript | TS Model & utils for OpenAPI 3.0.x contracts |
-| swagger2openapi | [GitHub/mermade/swagger2openapi](https://github.com/mermade/swagger2openapi) | Node.js | An OpenAPI / Swagger 2.0 to OpenAPI 3.0.x converter and validator |
-| Tavis.OpenApi | [GitHub/tavis-sofware/Tavis.OpenApi](https://github.com/tavis-software/Tavis.OpenApi/) | dotnet | C# based parser with definition validation and migration support from V2 |
-| odata-openapi | [GitHub/oasis-tcs/odata-openapi](https://github.com/oasis-tcs/odata-openapi) | XSLT | OData 4.0 to OpenAPI 3.0.0 converter |
+| swagger-parser | [github/swagger-api](https://github.com/swagger-api/swagger-parser/tree/feature/3.0.0-rc0) | Java | Swagger 1.0, 1.1, 1.2, 2.0 to OpenAPI Specification converter |
+| swagger-models | [github/swagger-api](https://github.com/swagger-api/swagger-core/tree/feature/3.0.0-rc0/modules/swagger-models) | Java | OpenAPI 3.0 Java Pojos |
+| KaiZen OpenAPI Parser | [github/RepreZen/KaiZen-OpenAPI-Parser](https://github.com/RepreZen/KaiZen-OpenAPI-Parser) | Java | High-performance Parser, Validator, and Java Object Model for OpenAPI 3.x |
+| openapi3-ts | [github/metadevpro/openapi3-ts](https://github.com/metadevpro/openapi3-ts) | TypeScript | TS Model & utils for OpenAPI 3.0.x contracts |
+| swagger2openapi | [github/mermade/swagger2openapi](https://github.com/mermade/swagger2openapi) | Node.js | An OpenAPI / Swagger 2.0 to OpenAPI 3.0.x converter and validator |
+| Microsoft.OpenApi.net | [github/microsoft/OpenApi.net](https://github.com/microsoft/openapi.net/) | dotnet | C# based parser with definition validation and migration support from V2 |
+| odata-openapi | [github/oasis-tcs/odata-openapi](https://github.com/oasis-tcs/odata-openapi) | XSLT | OData 4.0 to OpenAPI 3.0.0 converter |
+| openapi3_parser | [github/kevindew/openapi3_parser](https://github.com/kevindew/openapi3_parser) | Ruby | A Ruby implementation of parser and validator for the OpenAPI 3 Specification |
+| oas_parser | [github/Nexmo/oas_parser](https://github.com/Nexmo/oas_parser) | Ruby | An open source OpenAPI Spec 3 Definition Parser writen in Ruby |
 
 
 #### Editors
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| KaiZen OpenAPI Editor | [GitHub/RepreZen/KaiZen-OpenAPI-Editor](https://github.com/RepreZen/KaiZen-OpenAPI-Editor) | Java | Eclipse Editor for OpenAPI 2.0 and 3.0 |
+| Apicurio Studio | [github/Apicurio/apicurio-studio](https://github.com/Apicurio/apicurio-studio) | Java/Typescript | Web-Based **visual designer** for OpenAPI 2.0 and 3.0.0. |
+| KaiZen OpenAPI Editor | [github/RepreZen/KaiZen-OpenAPI-Editor](https://github.com/RepreZen/KaiZen-OpenAPI-Editor) | Java | Eclipse Editor for OpenAPI 2.0 and 3.0 |
 | RepreZen API Studio | [RepreZen.com/OpenAPI](https://www.reprezen.com/OpenAPI) | Java | Commercial desktop IDE for API design, documentation & development |
-| OpenApi-gui | [GitHub/Mermade/openapi-gui](https://github.com/Mermade/openapi-gui) | Node.js | GUI / visual editor for creating and editing OpenApi / Swagger definitions |
-| swagger-editor | [GitHub/swagger-api](https://github.com/swagger-api/swagger-editor) | JavaScript | Web-Based editor for creating, editing, validating and testing OpenAPI\Swagger definitions |
+| OpenAPI-gui | [github/Mermade/openapi-gui](https://github.com/Mermade/openapi-gui) | Node.js | GUI / visual editor for creating and editing OpenAPI definitions |
+| SwaggerHub | [swaggerhub.com](https://swaggerhub.com) | | API Design and Documentation Platform, Built For Teams
+| swagger-editor | [github/swagger-api](https://github.com/swagger-api/swagger-editor) | JavaScript | Web-Based editor for creating, editing, validating and testing OpenAPI\Swagger definitions |
 
 #### User Interfaces
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| openapi-viewer | [GitHub/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification. |
-| swagger-ui | [GitHub/swagger-api](https://github.com/swagger-api/swagger-UI) | JavaScript | Web-Based interface for visualizing and testing OpenAPI\Swagger definitions |
-| lincoln | [GitHub/temando/open-api-renderer](https://github.com/temando/open-api-renderer)| React.js| A React renderer for Open API v3 |
-
+| openapi-viewer | [github/koumoul/openapi-viewer](https://github.com/koumoul-dev/openapi-viewer) | Vue.js | Browse and test a REST API described with the OpenAPI 3.0 Specification. |
+| swagger-ui | [github/swagger-api](https://github.com/swagger-api/swagger-UI) | JavaScript | Web-Based interface for visualizing and testing OpenAPI\Swagger definitions |
+| lincoln | [github/temando/open-api-renderer](https://github.com/temando/open-api-renderer)| React.js| A React renderer for OpenAPI v3 |
+| WebSphere Liberty | [Download jar](https://developer.ibm.com/wasdev/downloads/) | JavaScript | Includes a native OpenAPI v3 UI which allows for customization of its banners and URL |
+| Widdershins | [github/Mermade/widdershins](https://github.com/Mermade/widdershins) | Node.js | Generate Slate/Shins markdown from OpenAPI 3.0.x |
+| angular-swagger-ui | [github/angular-swagger-ui](https://github.com/Orange-OpenSource/angular-swagger-ui) | AngularJS | An angularJS implementation of Swagger UI |
 
 #### Server Implementations
-
+| Title          | Project Link | Language |Description                          |
+|----------------|--------------|----------|---------------------|
+| Vert.x Web API Contract | [github/vert-x3/vertx-web](http://vertx.io/docs/#web) | Java, Kotlin, JavaScript, Groovy, Ruby, Ceylon & Scala | Create an API endpoint with Vert.x 3 and OpenAPI 3 with automatic requests validation
+| Fusio | [github/apioo/fusio](https://github.com/apioo/fusio) | PHP, JavaScript | Build API endpoints based on OpenAPI 3
+| Modern | [github/modern-project/modern-ruby](https://github.com/modern-project/modern-ruby) | Ruby | OpenAPI 3-based Rack framework with automatic OAS generation and requests/response validation
 
 #### Code Generators
 
 | Title          | Project Link | Language |Description                          |
 |----------------|--------------|----------|---------------------|
-| baucis-openapi3 | [Github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts. |
-| Google Gnostic | [GitHub/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations. |
-| serverless-openapi-documentation | [GitHub/temando/serverless-openapi-documentation](https://github.com/temando/serverless-openapi-documentation) | Typescript | Serverless 1.0 plugin to generate OpenAPI V3 documentation from serverless configuration |
+| baucis-openapi3 | [github/metadevpro/baucis-openapi3](https://github.com/metadevpro/baucis-openapi3) | Node.js | [Baucis.js](https://github.com/wprl/baucis) plugin for generating OpenAPI 3.0 compliant API contracts. |
+| Google Gnostic | [github/googleapis/gnostic](https://github.com/googleapis/gnostic) | Go | Compile OpenAPI descriptions into equivalent Protocol Buffer representations. |
+| serverless-openapi-documentation | [github/temando/serverless-openapi-documentation](https://github.com/temando/serverless-openapi-documentation) | Typescript | Serverless 1.0 plugin to generate OpenAPI V3 documentation from serverless configuration |
+| zero-rails_openapi | [github/zhandao/zero-rails_openapi](https://github.com/zhandao/zero-rails_openapi) | Ruby | Provide concise DSL for generating the OpenAPI Specification 3 documentation file for Rails application |
+| slush-vertx | [github/pmlopes/slush-vertx](https://github.com/pmlopes/slush-vertx) | Java, Kotlin & Groovy | Generate server skeleton for [Vert.x Web API Contract](http://vertx.io/docs/#web) and API Client based on [Vert.x 3 Web Client](http://vertx.io/docs/#web)
+| WebSphere Liberty | [Download jar](https://developer.ibm.com/wasdev/downloads/) | Java EE | Generates OpenAPI v3 documentation from Java EE applications |
+| swagger-node-codegen | [github/fmvilas/swagger-node-codegen](https://github.com/fmvilas/swagger-node-codegen) | Node.js | Generates a Node.js/express server, but also has a template engine for creating any templates needed. |

MAINTAINERS.md

@@ -0,0 +1,11 @@
+## Active
+* Darrel Miller [@darrelmiller](https://github.com/darrelmiller)
+* Jeremy Whitlock [@whitlockjc](https://github.com/whitlockjc)
+* Marsh Gardiner [@earth2marsh](https://github.com/earth2marsh)
+* Mike Ralphson [@MikeRalphson](https://github.com/MikeRalphson)
+* Ron Ratovsky [@webron](https://github.com/webron)
+* Uri Sarid [@usarid](https://github.com/usarid)
+
+## Emeritus
+* Jason Harmon [@jharmn](https://github.com/jharmn)
+* Tony Tam [@fehguy](https://github.com/fehguy)