A few words about the overall issue being discussed here
Some notes about using this template:
-
Your spec should be in markdown syntax
-
Please wrap text at 79 columns
-
Markdown addons are available for many web browsers so that you can easily view your formatted document
-
Any section which does not require content can just say "None"
-
The filename for this spec should have something to do with the content (i.e,
myspec.md
is not a good title) -
Cheatsheet (one of many) for markdown https://github.com/adam-p/markdown-here/wiki/Markdown-Cheatsheet
A detailed description of the problem to be solved or the use case for a new feature
What do you propose as the solution to the problem stated above?
Brief description of alternate solutions and an explanation of why they have been rejected or are considered inferior
What major components are affected? oshinko-rest, oshinko-s2i, oshinko-web, etc.
If the REST API will change as a result of this spec, it should be described here. A simple description of the endpoint and method should do, along with a JSON description of the request/response data
How will this be tested, unit tests or additional end-to-end tests? Any special considerations?
How will documentation need to change when this is implemented?