Create a template blueprint - EP000 (#1129)

Co-authored-by: Gleyberson Andrade <gleybersonandrade@gmail.com>
Co-authored-by: Rogerio Motitsuki <rogerio.motitsuki@gmail.com>
Co-authored-by: Antonio Francisco <antonio@ansp.br>
Co-authored-by: Carlos Magno <cmagnobarbosa@gmail.com>
Co-authored-by: Humberto Diógenes <hdiogenes@gmail.com>

docs/blueprints/EP000.rst

@@ -0,0 +1,156 @@
+:EP: 0
+:Title: Enhancement Proposals
+:Authors:
+    - José Mauro Ribeiro <zemauror@gmail.com>
+:Reviewers:
+    - Antonio Francisco <ajoaoff@gmail.com>
+    - Carlos Magno <cmagnobarbosa@gmail.com>
+    - Gleyberson Andrade <gleybersonandrade@gmail.com>
+    - Humberto Diógenes <hdiogenes@gmail.com>
+    - Rogério Motitsuki <rogerio@ansp.br>
+:Created: 2020-05-14
+:Kytos-Version: 2020.1
+:Status: Draft
+:Type: Standards Track
+
+
+########
+Abstract
+########
+This blueprint is proposed to clarify what blueprints are, their purpose, list the types of blueprints, explain which sections should be included in a blueprint, the information that should be included in each topic and the workflow involving a blueprint proposal. Therefore, this blueprint is intended to work as a meta blueprint.
+
+##########
+Motivation
+##########
+
+The Kytos Project uses the word 'blueprint' to refer to a specific type of document that plays a very important role in the development process. Anyone who is not familiar with the concept should be able to understand and start a draft blueprint using the EP0 (blueprint 0).
+A blueprint is a document used to specify the details of any process, features and anything else that is desirable to be implemented in Kytos Project and cannot be reduced to a GitHub issue or a meeting to be outlined, although a blueprint could start as an issue and become a blueprint after some discussion.
+This blueprint is intended to help anyone who wants to start a new blueprint. Besides that, the standard proposed here could save time for the author of a blueprint who doesn't have to think about the structure of the project and avoid that different authors write blueprints in a very different way. Separate blueprints with common sections between them could help even the readers who are familiar with the structure once they could search for specific sections in it.
+
+#########
+Rationale
+#########
+This meta blueprint is intended to make the contributor's workflow more clear about how to write a new blueprint.
+
+#############
+Specification
+#############
+
+Workflow
+**************
+Every blueprint should follow the steps below in order to be finished:
+
+Outline the subject
+===================
+The process for writing a blueprint should begin by describing a new idea, a specification to something that has been defined to be implemented. It is recommended that a single blueprint contain a single proposal. The more focused the blueprint, the more successful it tends to be. The Kytos team have the right to reject or approve any proposal. If in doubt, create an issue in the Kytos Project on Github and add a comment asking if the issue could be a blueprint.
+
+Submitting a blueprint
+======================
+After creating a first blueprint by adding every necessary section (check the sections under "Sections that a blueprint should have") you are encouraged to create a pull request in Kytos repository attending the following criteria:
+
+    - The status of the blueprint should be "draft";
+    - The file containing the proposal must follow the naming convention "EP[number].rst", where [number] is a sequential number, e.g. "EP001.rst";
+
+    - The file must contain a header following the template available in Blueprint Header section;
+
+    - The file must be written in restructured text (RST) format like the other blueprints (as you can see at 'kytos/docs/blueprints').
+
+
+Blueprint review
+================
+In the following days after you submit your pull request, the Kytos team will review the document adding comments and suggestions. So the author of the pull request must pay attention to the Kytos team feedback to make the review a quick process.
+
+
+Sections that a blueprint should have
+*************************************
+
+Header
+======
+Every blueprint proposal should use this template to build their own header:
+
+:EP: <\*EP number>
+:Title: <EP title>
+:Authors: <list of authors' names and email addrs>
+:Reviewers: <list of reviewers' names and email addrs>
+:Created: <date created on, in yyyy-mm-dd format>
+:Kytos-Version: <kytos version, in yyyy.v>
+:Status: <Draft | Accepted | Rejected | Final | Superseded>
+:Type: <Standards Track | Informational | Process>
+:\**Replaces: <EP number>
+
+\*EP number: should be fixed by Kytos team after the author submit the PR.
+
+\**Optional field.
+
+
+Abstract
+========
+A short (~200 word) description of the technical issue being addressed.
+
+Motivation
+==========
+It should clearly explain why the blueprint is being proposed describing any technical issue that is intended to be covered by the proposal.
+
+Rationale
+=========
+The rationale fleshes out the specification by describing why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other environments or scenarios.
+
+Specification
+=============
+The technical specification should describe the aspects of what is being proposed.
+
+Backwards Compatibility
+=======================
+All EPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EP must explain how the author proposes to deal with these incompatibilities.
+
+Security Implications
+=====================
+If there are security concerns in relation to the EP, those concerns should be explicitly written out to make sure reviewers of the EP are aware of them.
+
+Rejected Ideas
+==============
+Throughout the discussion of an EP, various proposed ideas end up not being accepted. Those rejected ideas should be recorded along with the reasoning as to why they were rejected. This both helps record the thought process behind the final version of the EP as well as preventing people from bringing up the same rejected ideas again in subsequent discussions.
+
+References
+==========
+References -- A collection of URLs used as references through the EP.
+
+Copyright/license
+=================
+
+Types of blueprints
+*******************
+
+Standard: Describes a new feature and its implementation.
+
+Process: Guidelines or information for the community and developers, but does not propose a new feature.
+
+Epic: Describes a problem and its solution.  
+
+#######################
+Backwards Compatibility
+#######################
+At the moment that this blueprint is being proposed Kytos Project have the total of 21 blueprints created. The standard proposed in EP0 should be followed by any new blueprint proposed after the blueprint 21, and is established here that the update of the previous blueprints are not mandatory.
+
+#####################
+Security Implications
+#####################
+Not applicable here
+
+##############
+Rejected Ideas
+##############
+Not applicable here
+
+##########
+References
+##########
+
+[1] https://www.python.org/dev/peps/pep-0001/#pep-audience
+
+#########
+Copyright
+#########
+
+This document is placed in the public domain or under the
+CC0-1.0-Universal license, whichever is more permissive.