Update template and checks

.scripts/check_proposals

@@ -25,6 +25,7 @@ end
 class MetadataChecker
   def initialize
     @categories = load_all_categories()
+    @stability_levels = ["experimental", "preview", "community", "default"]
   end
 
   def check pr_number, front_matter
@@ -37,6 +38,25 @@ class MetadataChecker
     else 
       system("gh pr edit #{pr_number} --remove-label invalid-categories")
     end
+    issue_errors = check_issue(pr_number, front_matter)
+    if issue_errors.length() > 0
+      errors << issue_errors
+      system("gh pr edit #{pr_number} --add-label missing-issue")
+    else
+      system("gh pr edit #{pr_number} --remove-label missing-issue")
+    end
+    begin
+      stability_level, err = check_stability_level(pr_number, front_matter)
+      system("gh pr edit #{pr_number} --remove-label invalid-stability-level")
+      # remove any previous stability-levels
+      @stability_levels.map { | level | system("gh pr edit #{pr_number} --remove-label stability-level/#{level}") }
+      system("gh pr edit #{pr_number} --add-label stability-level/#{stability_level}")
+    rescue => error
+      errors << error.message
+      system("gh pr edit #{pr_number} --add-label invalid-stability-level")
+      @stability_levels.map { | level | system("gh pr edit #{pr_number} --remove-label stability-level/#{level}") }
+    end
+
     errors
   end
 
@@ -54,6 +74,22 @@ class MetadataChecker
     errors
   end
 
+  def check_issue pr_number, front_matter
+    errors = []
+    unless (front_matter.key? "issue") && (front_matter["issue"] != nil)
+      errors << "Missing field: issue"
+    end
+    errors
+  end
+
+  def check_stability_level pr_number, front_matter
+    unless (front_matter.key? "stability-level") && (@stability_levels.include? front_matter["stability-level"])
+      raise "Invalid field: stability-level"
+    else
+      return front_matter["stability-level"]
+    end
+  end
+
   def load_all_categories
     yaml = YAML.load_file("_data/wildfly-categories.yaml")
     return yaml["categories"]

_includes/index-categories.html

@@ -28,7 +28,13 @@ <h2 id="{{ cat.id }}">{{ cat.name }} <small>[{{ cat.id }}]</small></a></h2>
     {% for page in site.pages %}
     <ul>
       {% if page.categories contains cat.id %}
-      <li><a href="{{ site.baseurl }}{{ page.url }}">{{ page.title }}</a></li>
+      <li><a href="{{ site.baseurl }}{{ page.url }}">
+        {% if page.stability-level != "default" %}
+        [{{ page.stability-level }}]&nbsp;
+        {% endif %}
+
+        {{ page.title }}
+      </a></li>
       {% endif %}
     </ul>
     {% endfor %}

_layouts/proposal.html

@@ -4,7 +4,12 @@
 
 <div class="post-page grid-wrapper">
   <div class="grid__item width-10-12">
-    <h1 class="title">{{page.title}}</h1>
+    <h1 class="title">
+      {% if page.stability-level != "default"  %}
+      [{{ page.stability-level }}]&nbsp;
+      {% endif %}
+      {{page.title}}
+    </h1>
   <div class="grid__item width-10-12 doc-content">
 
     {% unless pages.categories == empty %}
@@ -14,6 +19,9 @@ <h1 class="title">{{page.title}}</h1>
     {% endfor %}
     </div>
     {% endunless %}
+    <div style="padding-bottom: 2em;">Tracked by
+      <a href="{{ page.issue }}">{{ page.issue }}</a>
+    </div>
 
     {{ content }}
   </div>

design-doc-template.adoc

@@ -4,119 +4,96 @@ categories:
 # - core
 # - management
 # if missing, add it to _data/widfly-categories and use its id
+#
+# Specify the stability level of the feature.
+# Values can be one of: experimental preview community default
+stability-level: 
+#Specify the Feature Development tracker issue for the feature.
+# This must be an issue tracked in https://github.com/orgs/wildfly/projects/7/views/1.
+# To create a Feature Development tracker issue, go to  https://github.com/wildfly/wildfly-proposals/issues/new/choose 
+# and select 'Feature Development'
+issue: 
 ---
-= [Experimental|Preview|Community|default]Template <INSERT TITLE HERE>
+= <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]
-
-=== Stability Level
-// Choose the planned stability level for the proposed functionality
-* [ ] Experimental
-
-* [ ] Preview
+__<The entire document should be one to two pages long. We will write each analysis document as if it is a conversation with a future developer. This requires a good writing style, with full sentences organized into paragraphs. Bullets are acceptable only for visual style, not as an excuse for writing sentence fragments.>__
 
-* [ ] Community
-
-* [ ] default
-
-=== Dev Contacts
+== Overview
 
-* mailto:{email}[{author}]
+__<Define the requirement here. Be clear and succinct, you should be able to clearly define the context or problem in two or three paragraphs (if not sentences). Try to define the problem in the overall context and not to get into too much technical detail at this point.>__
 
-=== QE Contacts
+== Related Issues
 
-=== 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
+__<List the issues related to this feature>__
 
-* [ ] QE
+== Affected Projects or Components
 
-=== Affected Projects or Components
+__<List the projects or components that are affected by the feature. List them using their Git repositories.>__
 
 === 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
+__<List the installation types thar are relevant for the features and remove any that are not relevant>__.
 
-* [x] Bootable jar
+* Traditional standalone server (unzipped or provisioned by Galleon)
+* Managed domain
+* OpenShift Source-to-Image (S2I)
+* Bootable jar
 
 == Requirements
 
-=== Hard Requirements
-
-=== Nice-to-Have Requirements
-// Requirements in this section do not have to be met to merge the proposed functionality.
-// Note: Nice-to-have requirements that don't end up being implemented as part of
-// the work covered by this proposal should be moved to the 'Future Work' section.
-
+__<Describe the requirements that must be fullfilled by this feature.>__
 
 === Non-Requirements
-// Use this section to explicitly discuss things that readers might think are required
-// but which are not required.
+
+__<Use this section to explicitly discuss things that readers might think are required but which are not required.>__ 
 
 === Future Work
-// Use this section to discuss requirements that are not addressed by this proposal
-// but which may be addressed in later proposals.
+
+__<Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals.>__
 
 == Backwards Compatibility
 
-// Does this enhancement affect backwards compatibility with previously released
-// versions of WildFly?
-// Can the identified incompatibility be avoided?
+__<Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified incompatibility be avoided?>__
 
 === Default Configuration
 
+__<Does the proposed work change the default value of any current configuration attributes? Does it change the configuration generated by any current Galleon layers?>__
+
 === Importing Existing Configuration
 
+__<Does the proposed work affect the ability to run WildFly running an existing configuration? Is there anything else about the proposed work that may require changes to the WildFly server migration tool?>__
+
 === Deployments
 
+__<Does this feature change the behavior of deployments in incompatible ways?>__
+
 === 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.
-////
+__<Is this feature impacting interoperability?>__
+
+== Implementation Plan
+
+__<This section is optional. If you have a complex feature which can not be delivered all in one go, suggest the strategy.>__
 
 == Admin Clients
 
 __<Identify the level of compatibility this feature will have with the existing admin clients (JBoss CLI and the Admin Console / HAL). Identify any follow up work that will be required in the clients and link issues created to track this work.>__
 
 == 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.
-////
+__<What impact on security does this feature have?>__
 
 == Test Plan
 
-Depending on the selected stability level, the appropriate section below should be completed, including a brief description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections may be removed as needed.
+__<Depending on the selected stability level, the appropriate section below should be completed, including a brief description of how testing is to be performed in accordance with the selected stability level. The non-relevant sections may be removed as needed.>__
 ////
 Depending on the stability level, the test plan required may vary. see below:
 ////
@@ -134,16 +111,12 @@ Depending on the stability level, the test plan required may vary. see below:
 ** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise.
 
 == Community Documentation
-////
-Generally a feature should have documentation as part of the PR to wildfly main, 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.
-////
+
+__<Describe how this feature will be documented or illustrated. Generally a feature should have documentation as part of the PR to wildfly main, or as a follow up PR if the feature is in wildfly-core. In some cases though the feature will bring additional content (such as quickstarts, guides, etc.). Indicate which of these will happen>__
+ +** Default - This stability level is reserved and requires approval by a professional Quality Engineer with subject matter expertise.
+
 == 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>" 
-////
+
+__<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: https://www.wildfly.org/news/2024/01/25/WildFly31-Released/.__
+__This content will be edited, so there is no need to make it perfect or discuss what release it appears in.>__