added files

Author: fehguy

CONTRIBUTORS.md

@@ -0,0 +1,6 @@
+Darrel Miller (@darrelmiller)
+Jason Harmon (@jasonh-n-austin)
+Jeremy Whitlock (@whitlockjc)
+Marsh Gardiner (@earth2marsh)
+Ron Ratovsky (@webron)
+Tony Tam (@fehguy)

DEVELOPMENT.md

@@ -0,0 +1,50 @@
+## Objective of this Document
+
+Establish guidelines which build a transparent, open mechanism for deciding how to change the specification.  The TCB will initially follow these processes when merging changes from external contributors or from the TCB itself, and adjust them as it makes sense.
+
+## OAI Specification Driving factors
+
+The spec should be use-case driven.  We can write support for hypothetical use cases as we see fit, but they should be backed by realistic scenarios
+
+## Specification change criteria
+
+The specification _will change_ from the 2.0 version.  We should typically do so when any of the following criteria are met:
+
+ - Clarity.  The current "way" something is done doesn't make sense, is complicated, or not clear
+ - Consistency.  A portion of the specification is not consistent with the rest, or the industry standard terminology
+ - Necessary functionality.  We are missing functionality because of a certain design of the specification
+ - Forward-looking designs.  As usage of APIs evolves to new protocols, formats, patterns, we should always be considering what the next important functionality should be
+ - Impact.  A change will provide impact on a large number of use cases.  We should not be forced to accommodate every use case.  We should strive to make the _common_ and _important_ use cases both well supported and common in the definition of the OAI Spec.  We cannot be edge-case driven.
+
+
+## Tracking Process
+
+ - Use GitHub for all spec designs, use cases, etc.
+ - 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.md for example).
+ - The `master` branch shall remain the current, released OpenAPI Specification (i.e. 2.0).  We will work in an OpenAPI.next branch, which shall be described and linked to on the **default** README.md on master
+ - Examples of how something is described _currently_ vs. the proposed solution should accompany any change proposal
+ - New features should be done in feature branches which, upon approval, be merged into the OpenAPI.next branch.
+ - Use labels for the workflow of specification changes.  For example, this may be labeled as `proposed`, `needs migration review`, `needs tooling review`, `needs documentation`, `rejected`, `needs approval`.  These labels must be assigned by project committers
+ - An issue will be opened for each feature change.  Embedded in the issue OR ideally linked in a file via PR, a document should be supplied for use cases for the change
+ - A PR will be used to describe the _proposed_ solution, and linked to the original issue
+ - Not all committers will contribute to ever single proposed change.  There may be many open proposals at once, and multiple efforts may happen in parallel
+ - When the OpenApi.next spec is complete and approved for release, the branch will be merged to master.
+
+## Approving Changes
+
+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?
+ - Tooling.  Strive to support code generation, software interfaces, spec generation techniques.  Some features may be impossible to support in different frameworks/languages.  These should be documented and considered if the change should be approved.
+ - Visualization.  Can the specification change be graphically visualized somehow in a UI or other?
+
+Spec changes should be approved by a majority of the committers.  This can be done by commenting on the issue itself ("Approved by @fehguy" for example).  Once 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.
+
+## Transparency
+
+We should always be as transparent as possible.  Sometimes there will be discussions that use customer names, sensitive use cases, etc.  These must be anonymized, discussed in a private repository, or offline
+
+ - Offline Discussions should live in issues.
+ - Realtime discussions should be in a public chat such as IRC or Slack

README.md

@@ -1,55 +1,21 @@
-# The OpenAPI Specification (fka The Swagger Specification)
+# The OpenAPI Specification
 
-[![Build Status](https://travis-ci.org/swagger-api/swagger-spec.svg?branch=master)](https://travis-ci.org/swagger-api/swagger-spec)
+This is the working branch for the next version of the OpenAPI Specification. You can read more about the Open API Initiative (OAI) at [https://openapis.org](https://openapis.org).
 
-![](https://avatars3.githubusercontent.com/u/16343502?v=3&s=200)
+The current, released version of the OpenAPI Specification is 2.0, through donation of the Swagger Specification to the OAI by SmartBear Software.  If you are interested in the release specification, please see the [master branch](https://github.com/OAI/OpenAPI-Specification/blob/master/README.md) of this project.
 
-The goal of The OpenAPI Specification is to define a standard, language-agnostic interface to REST APIs which allows both humans and computers to discover and understand the capabilities of the service without access to source code, documentation, or through network traffic inspection.  When properly defined via OpenAPI, a consumer can understand and interact with the remote service with a minimal amount of implementation logic.  Similar to what interfaces have done for lower-level programming, OpenAPI removes the guesswork in calling the service.
+Development of the next version of the OpenAPI Specification is being guided by the [OAI Technical Contributors Board](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/CONTRIBUTORS.md).  This group of committers will be bring their API expertise, incorporating feedback from the community, and expanding the group of committers as appropriate.  All development activity on the future specification will be performed as features and merged into this branch.  Upon release of the OpenAPI Specification, this branch will be merged to master.
 
-Use cases for machine-readable API interfaces include interactive documentation, code generation for documentation, client, and server, as well as automated test cases.  OpenAPI-enabled APIs expose JSON files that correctly adhere to the OpenAPI Specification, documented in this repository.  These files can either be produced and served statically, or be generated dynamically from your application.
+You can see the current process for development inside the OpenAPI Specification [here](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md).
 
-Without going into a long history of interfaces to Web Services, this is not the first attempt to do so.  We can learn from CORBA, WSDL and WADL.  These specifications had good intentions but were limited by proprietary vendor-specific implementations, being bound to a specific programming language, and goals which were too open-ended.  In the end, they failed to gain traction.
+## Participation
 
-OpenAPI does not require you to rewrite your existing API.  It does not require binding any software to a service--the service being described may not even be yours.  It does, however, require the capabilities of the service be described in the structure of the OpenAPI Specification.  Not all services can be described by OpenAPI--this specification is not intended to cover every possible use-case of a REST-ful API.  OpenAPI does not define a specific development process such as design-first or code-first.  It does facilitate either technique by establishing clear interactions with a REST API.
+The OpenAPI Specification is a community driven, open project hosted by the Linux Foundation. It encourages participation from individuals and companies alike.  If you wish to participate in the evolution of the OpenAPI Specification, please consider the following:
 
-This GitHub project is the starting point for OpenAPI.
-Here you will find the information you need about the OpenAPI Specification, a simple static sample of what it looks like,
-and some general information regarding the project.
-
-
-## Current Version - 2.0
-
-The current version of the OpenAPI specification is 2.0 - and you can find it [here](versions/2.0.md).
-
-### [OpenAPI 2.0 Specification](versions/2.0.md)
-
-This repository contains the existing Swagger 1.2 specification as well as proposals for the 2.0 version.
-
-## Structure
-
-Each section should contain v1.2 and v2.0 folders to avoid confusion between the versions.
-
-Please keep in mind that the other projects under OpenAPI use an independent version system.
-As such, don't confuse the version of the OpenAPI Specification they support and the version of that given library.
-
-## The Wiki
-
-Check out the [wiki](https://github.com/OAI/OpenAPI-Specification/wiki) for additional and relevant information about the project.
-
-This includes:
-- Static sample tutorial.
-- List of known deployments.
-- Revision history.
-
-## See it in Action
-
-If you just want to see it work, check out the [pet store sample](http://petstore.swagger.io/).
-
-## Tools and Libraries
-
-Looking to see how you can create your own OpenAPI definition, present it or otherwise use it? Check out our [list of tools](http://swagger.io/open-source-integrations/) over at [http://swagger.io](http://swagger.io/open-source-integrations/).
-
-(Yes, there used to be a really long list here, we just moved it to the main website)
+* Review the [current specification](). The human-readable markdown file _is the source of truth_ for the specification.
+* Review the [development](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md) process so it's clear how the spec is evolving.
+* Check the [issues](https://github.com/OAI/OpenAPI-Specification/issues) and [pull requests](https://github.com/OAI/OpenAPI-Specification/pulls) to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by adding a comment to the existing issue or PR.
+* Create an issue to describe a concern and/or a pull request to provide a solution. If providing a pull request, please ensure you are adding comments regarding the **Approving Changes** section of the [development](https://github.com/OAI/OpenAPI-Specification/blob/OpenAPI.next/DEVELOPMENT.md) guideline.
 
 ## License