diff --git a/descriptions/template.rst b/descriptions/template.rst
new file mode 100644
index 0000000..b043b2c
--- /dev/null
+++ b/descriptions/template.rst
@@ -0,0 +1,85 @@
+# This is a template that can be used for creating new tags. At a minimum
+# the following information should be submitted when creating a tag.
+#
+# Each tag should have a the following structure:
+# - descriptions/<tag_name>.rst - Description of the tag
+# - <release_name>/<tag_name>.json - Tag definition
+#
+# All comment lines (marked with a '#') should be removed before submission.
+
+========================================================================
+ops:<tag_name>
+========================================================================
+
+# Introductory paragraph
+# Provide a short summary of what this tag will mean
+
+
+Rationale
+=========
+
+# Provide a detailed explanation of why the OpenStack ecosystem benefits
+# from having this tag defined.
+
+Requirements
+============
+
+# Provide a list of requirements for granting the tag to an existing
+# project.
+# All the criteria should be objective and predictable.
+# If a tag requires another tag, this should be mentioned here.
+#
+# - Requirement 1
+# - Requirement 2
+
+Tag application process
+=======================
+
+# Details of the process to follow to maintain the tag. Are additions/
+# removals regularly reviewed, or are they considered only upon request?
+# Which group is involved, and at which frequency ?
+#
+# The process may include requiring feedback from specific groups,
+# delegation of tag maintenance from the UC, minimum delays between
+# application and tag grant, timeframes where granting or removing the
+# tag is appropriate, etc.
+#
+# If the grant process is different from the removal process, this should
+# also be mentioned here.
+#
+# By default, you can use the following process:
+#
+# Anyone may propose adding or removing this tag to a set of projects by
+# proposing a change to the openstack/ops-tags-team repository. The change is
+# reviewed by the Ops Tags Group and approved using standard resolution
+# approval rules.
+#
+# - Step 1
+# - Step 2
+# - Step 3
+
+Tag updates and timing
+======================
+
+# Ops Tags are typically made on a per-release basis.  Near the end
+# of a release cycle, a new directory to contain the JSON files for
+# the release is created, and tags are re-assessed.  Information is
+# either removed or copied from the previous release as appropriate.
+#
+# Some tags may have a deprecation period (where a project retains the
+# tag but only until a certain announced date). If the proposed tag has
+# a deprecation period, its duration (and any other specific rules) should
+# be listed here.
+#
+# - There is no deprecation period required for this tag.
+# - It can be added or removed at any time.
+
+Attributes
+==========
+
+# Tags may have attributes which provide extra information. Those attributes
+# (and their values) should be described in this section
+#
+# - attribute1  - attribute1 description
+# - attribute2  - attribute2 description
+# - attribute3  - attribute3 description
diff --git a/kilo/template.json b/kilo/template.json
new file mode 100644
index 0000000..70de661
--- /dev/null
+++ b/kilo/template.json
@@ -0,0 +1,14 @@
+# This is a template that can be used for creating definitions for new tags.
+# The attributes and the values defined here will match those defined in the
+# corresponding descriptions/<tag_name>.rst file.
+#
+# Each tag should have a the following structure
+# {
+#   "<Product_Name>":
+#   {
+#    "attribute1": "value1",
+#    "attribute2": ["value2", "value3", "value4"]
+#   },
+# }
+#
+# All comment lines (marked with a '#') should be removed before submission.