---
categories:
# Add any category for this proposal
# if missing, add it to _data/widfly-categories and use its id
---
= Template <INSERT TITLE HERE>
:author:            Your Name
:email:             your.email@redhat.com
:toc:               left
:icons:             font
:idprefix:
:idseparator:       -

== Overview

== Issue Metadata

=== Issue

* https://issues.redhat.com/browse/WFCORE[WFCORE-XXXX]

=== Related Issues

* https://issues.redhat.com/browse/WFLY[WFLY-XXXX]

=== Dev Contacts

* mailto:{email}[{author}]

=== QE Contacts

=== Testing By
// Put an x in the relevant field to indicate if testing will be done by Engineering or QE. 
// Discuss with QE during the Kickoff state to decide this
* [ ] Engineering

* [ ] QE

=== Affected Projects or Components

=== Other Interested Projects

=== Relevant Installation Types
// Remove the x next to the relevant field if the feature in question is not relevant
// to that kind of WildFly installation
* [x] Traditional standalone server (unzipped or provisioned by Galleon)

* [x] Managed domain

* [x] OpenShift s2i

* [x] Bootable jar

== Requirements

=== Hard Requirements

=== Nice-to-Have Requirements

=== Non-Requirements

== Backwards Compatibility

// Does this enhancement affect backwards compatibility with previously released
// versions of WildFly?
// Can the identified incompatibility be avoided?

=== Default Configuration

=== Importing Existing Configuration

=== Deployments

=== Interoperability

//== Implementation Plan
////
Delete if not needed. The intent is if you have a complex feature which can 
not be delivered all in one go to suggest the strategy. If your feature falls 
into this category, please mention the Release Coordinators on the pull 
request so they are aware.
////

== Security Considerations

////
Identification if any security implications that may need to be considered with this feature
or a confirmation that there are no security implications to consider.
////

== Test Plan

== Community Documentation
////
Generally a feature should have documentation as part of the PR to wildfly master, or as a follow up PR if the feature is in wildfly-core. In some cases though the documentation belongs more in a component, or does not need any documentation. Indicate which of these will happen.
////
== Release Note Content
////
Draft verbiage for up to a few sentences on the feature for inclusion in the
Release Note blog article for the release that first includes this feature. 
Example article: http://wildfly.org/news/2018/08/30/WildFly14-Final-Released/.
This content will be edited, so there is no need to make it perfect or discuss
what release it appears in.  "See Overview" is acceptable if the overview is
suitable. For simple features best covered as an item in a bullet-point list 
of features containing a few words on each, use "Bullet point: <The few words>" 
////