Merge branch 'main' into feature_process

.github/ISSUE_TEMPLATE/feature-development.yaml

@@ -0,0 +1,26 @@
+name: Feature Development
+description: Define an issue for the feature development of a WildFly RFE.
+labels: ['feature']
+projects: ['wildfly/7']
+body:
+  - type: markdown
+    attributes:
+      value: |
+        Create an issue for tracking development of an RFE. Please enter a description for this issue and a point of 
+        contact for this issue.
+        > :warning: **This is not where a request for enhancement would be filed. This is for developing already defined RFE's.**
+  - type: textarea
+    id: description
+    attributes:
+      label: Description
+      description: A description of the feature.
+    validations:
+      required: true
+  - type: input
+    id: issue-contact
+    attributes:
+      label: Issue Contact
+      description: The GitHub id of the person who is the point of contact for moving this feature forward.
+    validations:
+      required: true
+

.github/workflows/check_process.yml

@@ -19,7 +19,7 @@ jobs:
       - name: Setup Ruby
         uses: ruby/setup-ruby@8575951200e472d5f2d95c625da0c7bec8217c42 # v1.161.0
         with:
-          ruby-version: '3.1' # Not needed with a .ruby-version file
+          ruby-version: '3.2' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically
           cache-version: 0 # Increment this number if you need to re-download cached gems
       - name: Get all proposals files that have changed
@@ -40,4 +40,4 @@ jobs:
           PR_NUMBER: ${{ github.event.number }}
         run: |
           echo "Check all proposals files that have changed: $PROPOSAL_FILES"
-          ./.scripts/check_proposals $PR_NUMBER $PROPOSAL_FILES
+          ./.scripts/check_proposals $PR_NUMBER $PROPOSAL_FILES

FEATURE_PROCESS.adoc

@@ -21,19 +21,19 @@ Feature development proceeds in five stages:
 
 When a developer intends to begin work on a feature they should do the following:
 
-* If one doesn't already exist, file an issue in the relevant project JIRA, typically https://issues.redhat.com/projects/WFLY/summary[WFLY], https://issues.redhat.com/projects/WFCORE/summary[WFCORE] or https://issues.redhat.com/projects/HAL/summary[HAL]. These issues are important as they allow users and developers to see follow what has happened in a particular code base.
+* If one doesn't already exist, file an issue in the relevant project JIRA, typically https://issues.redhat.com/projects/WFLY/summary[WFLY], https://issues.redhat.com/projects/WFCORE/summary[WFCORE] or https://issues.redhat.com/projects/HAL/summary[HAL]. These issues are important as they allow users and developers to follow what has happened in a particular code base.
 * [[planning_issue]]File an issue with the https://github.com/orgs/wildfly/projects/7[WildFly Feature Planning project]. To do this create an issue using the https://github.com/wildfly/wildfly-proposals/issues/new?assignees=&labels=feature&projects=wildfly%2F7&template=feature-development.yaml[Feature Development issue template]. This issue is important because:
 ** It is what allows effective coordination of overall feature development for a WildFly release from a single, publicly visible, point.
 ** It allows users to see an overall roadmap for WildFly features.
 * Draft a minimal feature analysis, based on the current https://github.com/wildfly/wildfly-proposals/blob/main/design-doc-template.adoc[design-doc-template]. This should include the expected stability level, links to the issues above, and enough Overview and User Story information to give people interested in being part of the feature team a sense of what would be involved.
 * Submit a draft analysis PR to the https://github.com/wildfly/wildfly-proposals[`wildfly-proposals`] repository.
-* Send an email to the mailto:wildfly-dev@lists.jboss.org[`wildfly-dev@lists.jboss.org`] mail list telling people about the upcoming work and asking for volunteers to participate in the feature team. (If you don't have a `wildfly-dev` list subscription, visit the https://lists.jboss.org/admin/lists/wildfly-dev.lists.jboss.org/[list subscription page] to create one.)
+* Send an email to the mailto:wildfly-dev@lists.jboss.org[`wildfly-dev@lists.jboss.org`] mail list telling people about the upcoming work and asking for volunteers to participate in the feature team. (If you don't have a wildfly-dev list subscription, visit the https://lists.jboss.org/admin/lists/wildfly-dev.lists.jboss.org/[list subscription page] to create one. Posting is restricted to subscribers.)
 
 When the above tasks are complete, change the `Status` field of the WildFly Feature Planning project JIRA to `Planning`.
 
 === Planning
 
-The `Planning` stage of a feature consists of <<feature-team,feature team>> formation and enough discussion of the feature among the team that they can agree on a target feature stability level and target WildFly release in which they expect to complete the feature.
+The `Planning` stage of a feature consists of <<feature-team,feature team>> formation and enough discussion of the feature among the team that they can agree on a target feature stability level and the target WildFly release in which they expect to complete the feature.
 
 NOTE: The target WildFly release is just a target and is not a commitment.
 
@@ -49,15 +49,15 @@ IMPORTANT: Changes to the `Iteration` field of a WildFly Feature Planning projec
 
 === In Progress
 
-The main work on the feature happens in this stage. The feature team works to meet the <<requirements>> that apply to the feature's target stability.
+The main work on the feature happens in this stage. The feature team works to meet the <<requirements,requirements>> that apply to the feature's target stability.
 
 When the team believes all development work on the feature is complete, change the `Status` field of the <<planning_issue,WildFly Feature Planning project issue>> to `Review`.
 
 NOTE: Developers should not move an issue to `Review` status as a means of asking other team members to do routine code review. Such intra-team coordination should be handled in some other way. Moving an issue to `Review` is a signal to WildFly release coordinators that work on the feature is about to conclude.
 
 === Review
 
-In the Review stage the team formally validates that the <<requirements>> have been met.
+In the Review stage the team formally validates that the <<requirements, requirements>> have been met.
 
 This should be a relatively quick stage, as the team should have a belief that the requirements are met before the feature issue is moved to `Review`. The work in this stage should simply be a formal check and signoff.
 
@@ -69,6 +69,18 @@ If the formal review reveals issues that will take more than three days to resol
 
 The release coordinator moves the issue to `Done` status when all work associated with the feature has been merged.
 
+== Feature Promotion
+
+If a feature has been included in a WildFly release at a lower stability level and then a developer wishes to promote it to a higher stability level in a later release, the promotion should be done following the same processes as are followed for any other feature. There will of course be differences in the details of the work to be done, but the process steps are the same.
+
+=== Special Requirements for `preview` Stability
+
+When a feature is brought in at `preview` stability, this implies a commitment to our users that we expect to eventually move it to `community` stability or higher. To help ensure we keep that commitment, during development of the `preview` feature, the feature team should discuss with the leaders of the relevant technology area a rough plan for how that promotion will happen. Some information about that plan *must* appear in the `Future Work` section of the feature's analysis document.
+
+The primary goal here is to either identify a particular person who intends to carry the work forward, or at least get a commitment from a team that someone will. A brief description of the expected future work will help clarify what may be required.
+
+There is no requirement to do this for `experimental` features, although developers are strongly discouraged from introducing experimental features they don't intend to personally take to at least `preview` if the experiment is successful. There is also no requirement to do this for `community` features, as `community` is a valid final stability level for a feature.
+
 [[feature-team]]
 == The Feature Team
 

Gemfile.lock

@@ -1,23 +1,29 @@
 GEM
   remote: https://rubygems.org/
   specs:
-    addressable (2.8.5)
-      public_suffix (>= 2.0.2, < 6.0)
-    asciidoctor (2.0.20)
+    addressable (2.8.7)
+      public_suffix (>= 2.0.2, < 7.0)
+    asciidoctor (2.0.23)
+    bigdecimal (3.1.8)
     colorator (1.1.0)
-    concurrent-ruby (1.2.2)
+    concurrent-ruby (1.3.4)
     em-websocket (0.5.3)
       eventmachine (>= 0.12.9)
       http_parser.rb (~> 0)
     eventmachine (1.2.7)
-    ffi (1.15.5)
+    ffi (1.17.0-arm64-darwin)
+    ffi (1.17.0-x86_64-linux-gnu)
     forwardable-extended (2.6.0)
-    google-protobuf (3.24.3-arm64-darwin)
-    google-protobuf (3.24.3-x86_64-linux)
+    google-protobuf (4.28.2-arm64-darwin)
+      bigdecimal
+      rake (>= 13)
+    google-protobuf (4.28.2-x86_64-linux)
+      bigdecimal
+      rake (>= 13)
     http_parser.rb (0.8.0)
-    i18n (1.14.1)
+    i18n (1.14.5)
       concurrent-ruby (~> 1.0)
-    jekyll (4.3.2)
+    jekyll (4.3.3)
       addressable (~> 2.4)
       colorator (~> 1.0)
       em-websocket (~> 0.5)
@@ -33,8 +39,8 @@ GEM
       safe_yaml (~> 1.0)
       terminal-table (>= 1.8, < 4.0)
       webrick (~> 1.7)
-    jekyll-asciidoc (3.0.0)
-      asciidoctor (>= 1.5.0)
+    jekyll-asciidoc (3.0.1)
+      asciidoctor (>= 1.5.0, < 3.0.0)
       jekyll (>= 3.0.0)
     jekyll-feed (0.17.0)
       jekyll (>= 3.7, < 5.0)
@@ -51,33 +57,32 @@ GEM
     kramdown-parser-gfm (1.1.0)
       kramdown (~> 2.0)
     liquid (4.0.4)
-    listen (3.8.0)
+    listen (3.9.0)
       rb-fsevent (~> 0.10, >= 0.10.3)
       rb-inotify (~> 0.9, >= 0.9.10)
     mercenary (0.4.0)
-    minima (2.5.1)
+    minima (2.5.2)
       jekyll (>= 3.5, < 5.0)
       jekyll-feed (~> 0.9)
       jekyll-seo-tag (~> 2.1)
     pathutil (0.16.2)
       forwardable-extended (~> 2.6)
-    public_suffix (5.0.3)
+    public_suffix (6.0.1)
+    rake (13.2.1)
     rb-fsevent (0.11.2)
-    rb-inotify (0.10.1)
+    rb-inotify (0.11.1)
       ffi (~> 1.0)
-    rexml (3.2.8)
-      strscan (>= 3.0.9)
-    rouge (4.1.3)
+    rexml (3.3.7)
+    rouge (4.3.0)
     safe_yaml (1.0.5)
-    sass-embedded (1.66.1-arm64-darwin)
-      google-protobuf (~> 3.23)
-    sass-embedded (1.66.1-x86_64-linux-gnu)
-      google-protobuf (~> 3.23)
-    strscan (3.1.0)
+    sass-embedded (1.78.0-arm64-darwin)
+      google-protobuf (~> 4.27)
+    sass-embedded (1.78.0-x86_64-linux-gnu)
+      google-protobuf (~> 4.27)
     terminal-table (3.0.2)
       unicode-display_width (>= 1.1.1, < 3)
-    unicode-display_width (2.4.2)
-    webrick (1.8.1)
+    unicode-display_width (2.5.0)
+    webrick (1.8.2)
 
 PLATFORMS
   arm64-darwin-22
@@ -92,4 +97,4 @@ DEPENDENCIES
   minima
 
 BUNDLED WITH
-   2.4.19
+   2.5.18

_layouts/proposal.html

@@ -20,7 +20,7 @@ <h1 class="title">
     </div>
     {% endunless %}
     <div style="padding-bottom: 2em;">Tracked by&nbsp;
-      <a href="{{ page.issue }}">{{ page.issue }}</a>
+      <a href="{{ page.issue }}">{{ page.issue }}</a>
     </div>
 
     {{ content }}

design-doc-template.adoc

@@ -90,6 +90,8 @@ __<Use this section to explicitly discuss things that readers might think are re
 
 __<Use this section to discuss requirements that are not addressed by this proposal but which may be addressed in later proposals.>__
 
+__<Proposals for `preview` stability features *must* include information on expected work to be done to bring the feature to `community` stability.>__
+
 == Backwards Compatibility
 
 __<Does this enhancement affect backwards compatibility with previously released versions of WildFly? Can the identified incompatibility be avoided?>__