Create a feature request issue template. #588

jamezp · 2024-07-17T17:11:17Z

Add a new template for feature request issues.

This is currently a draft as I want to make sure we encapsulate everything first.

jamezp · 2024-07-17T19:07:16Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+description: A feature request for WildFly
+title: "[RFE]: "
+labels: ["feature"]
+projects: ["wildfly/7"]


We may want to consider using a workflow to add the project if not everyone create an issue will have write access. See https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/syntax-for-issue-forms.

jamezp · 2024-07-17T19:13:56Z

.github/ISSUE_TEMPLATE/feature-request.yaml

@@ -0,0 +1,32 @@
+name: Feature Request
+description: A feature request for WildFly
+title: "[RFE]: "


Should we prefix with "[RFE]: ", nothing or something elese?

jamezp · 2024-07-17T19:14:20Z

.github/ISSUE_TEMPLATE/feature-request.yaml

@@ -0,0 +1,32 @@
+name: Feature Request


Do we want to use the term "Feature Request" or is there something better?

"Enhancement Proposal"? "Enhancement"?

Enhancement has a meaning that's not relevant here. In JIRA we use it for improvements that bring direct user benefit but are not user controllable. I'd prefer not to confuse that.

'Feature' seems reasonable

BTW 'Feature Request' seems ok to me too if we want to follow KISS principles and align with JIRA. But I get how the 'Request' part is odd here as these issues are never requests that someone do something, they are statements of intent to do something.

jamezp · 2024-09-11T17:21:08Z

jamezp · 2024-09-11T17:23:02Z

Note that outside perspective is required for the template. We could make the other ones required as well, but we don't have to. The question becomes what we want to see in the issue vs what we want on the actual proposal document.

jmesnil · 2024-09-12T14:37:13Z

.github/ISSUE_TEMPLATE/feature-request.yaml

@@ -0,0 +1,32 @@
+name: Feature Request


"Enhancement Proposal"? "Enhancement"?

jmesnil · 2024-09-12T14:44:39Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+      description: A link to the main feature request JIRA.
+      placeholder: ex. https://issues.redhat.com/browse/WFLY-XXX
+    validations:
+      required: true


Is it really required to propose a new feature enhancement?

It's needed for the analysis document but for proposing something that might be too early. It might not be necessarily known beforehand which projects would be impacted by the proposal (WFLY, WFCORE, WFMP, etc.)

No, this doesn't really need to be required I suppose. The idea here is we use this for RFE's that are effectively already in progress. This will not be meant to track features we want to have, just features we're actively working on for a release.

This data is necessary in the proposal, so repeating it here is added overhead.

jmesnil · 2024-09-12T14:45:00Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+      options:
+        - community
+        - preview
+        - experimental


do we want to add default too?

I think this data should come from the proposal adoc

We can definitely remove this.

jmesnil · 2024-09-12T14:45:36Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+    id: sme
+    attributes:
+      label: Subject Matter Expert
+      description: The name of the person who is the subject matter expert.


maybe specify the person with their GitHub handle (e.g. @jamezp)?

We could do that. There isn't really a field type for that.

jmesnil · 2024-09-12T14:46:44Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+    id: outside-perspective
+    attributes:
+      label: Outside Perspective
+      description: The name of the person who is the outside perspective for this feature.


maybe let the user proposing the enhancement know that they can put themselves as the "Outsider"?

If we can validate this based on the stability level that would be ideal. It's N/A for 'experimental', otherwise required.

I don't get the overall 'validation' pattern. We always need the SME and the developer, while requiring the outside perspective depends on the stability level.

TBH I think this feature team stuff should be in the proposal as well, as front matter. We talk about the 'required' feature team, but those are really minimums. There's one person who's the primary assignee (the default person to contact), then there are 1..n SMEs, and then [0|1]..n outsiders. This latter two are modeled as lists, which is doable via adoc front matter.

Recording that here is ok, if we remove it from the proposal and the feature team itself will be able to maintain it in the issue.

Note: I'm really thinking out loud here; I think we can iterate on this and not block too much.

I don't get the overall 'validation' pattern. We always need the SME and the developer, while requiring the outside perspective depends on the stability level.

But I realize this validation is about the initial filing, and for that we need to know the assignee and the rest is optional.

Sure, we can do whatever really. Making all or none of them required seems reasonable. Maybe for now, just none of them required.

Probably the Developer is required (which AIUI is the person we call the 'assignee'). The issue filer may not be that person, particularly early on when those of us working on tooling / process may be doing the paperwork.

jmesnil · 2024-09-12T14:52:39Z

.github/ISSUE_TEMPLATE/feature-request.yaml

+title: ""
+labels: ["feature"]
+projects: ["wildfly/7"]
+body:


we could add a markdown type to give more contextual information for the user submitting the proposal (without polluting the created issue with this blurb of text).

This would give the user more info about what we are expecting for them when they fill the form.

Sure, we could do that.

bstansberry · 2024-09-12T16:52:56Z

.github/ISSUE_TEMPLATE/feature-request.yaml

@@ -0,0 +1,53 @@
+name: Feature Request
+description: A feature request for WildFly


A new feature for WildFly

Signed-off-by: James R. Perkins <jperkins@redhat.com>

jamezp · 2024-09-25T16:22:51Z

@jmesnil @bstansberry @darranl I've updated the template to be more simplistic and not duplicate attributes. You can see an example of what it would look like here https://github.com/jamezp/wildfly-proposals/issues/new?assignees=&labels=feature&projects=wildfly%2F7&template=feature-development.yaml

darranl · 2024-09-25T16:27:33Z

FYI for anyone reviewing, we have discussed if we can get a simplified issue template introduced and merged and we will continue to evolve as we experience using it so reviews here are not a last change to make updates etc...

Maybe we can use this data in some way.

bstansberry · 2024-09-25T19:22:27Z

Thanks @jamezp @jmesnil @darranl

jamezp commented Jul 17, 2024

View reviewed changes

jamezp marked this pull request as ready for review July 17, 2024 19:14

jamezp force-pushed the feature-request-issue-template branch 3 times, most recently from d9ce5db to 8d9a9aa Compare September 11, 2024 17:20

jamezp requested review from jasondlee, bstansberry and darranl September 11, 2024 17:21

jmesnil reviewed Sep 12, 2024

View reviewed changes

bstansberry reviewed Sep 12, 2024

View reviewed changes

Create a feature request issue template.

100d978

Signed-off-by: James R. Perkins <jperkins@redhat.com>

jamezp force-pushed the feature-request-issue-template branch from 8d9a9aa to 100d978 Compare September 25, 2024 16:21

darranl approved these changes Sep 25, 2024

View reviewed changes

Try to gather github ids instead of names

4f19d66

Maybe we can use this data in some way.

bstansberry approved these changes Sep 25, 2024

View reviewed changes

bstansberry merged commit b4f7756 into wildfly:main Sep 25, 2024
1 check passed

jamezp deleted the feature-request-issue-template branch October 8, 2024 02:36

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Create a feature request issue template. #588

Create a feature request issue template. #588

jamezp commented Jul 17, 2024

jamezp Jul 17, 2024

jamezp Jul 17, 2024

jamezp Jul 17, 2024

jmesnil Sep 12, 2024

bstansberry Sep 12, 2024

bstansberry Sep 12, 2024

jamezp commented Sep 11, 2024

jamezp commented Sep 11, 2024

jmesnil Sep 12, 2024

jmesnil Sep 12, 2024

jamezp Sep 12, 2024

bstansberry Sep 12, 2024

jmesnil Sep 12, 2024

bstansberry Sep 12, 2024

jamezp Sep 12, 2024

jmesnil Sep 12, 2024

jamezp Sep 12, 2024

jmesnil Sep 12, 2024

bstansberry Sep 12, 2024

bstansberry Sep 12, 2024

bstansberry Sep 12, 2024

bstansberry Sep 12, 2024

jamezp Sep 12, 2024

bstansberry Sep 12, 2024

jmesnil Sep 12, 2024

jamezp Sep 12, 2024

bstansberry Sep 12, 2024

jamezp commented Sep 25, 2024

darranl commented Sep 25, 2024

bstansberry commented Sep 25, 2024

		@@ -0,0 +1,53 @@
		name: Feature Request
		description: A feature request for WildFly

Create a feature request issue template. #588

Create a feature request issue template. #588

Conversation

jamezp commented Jul 17, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamezp commented Sep 11, 2024

jamezp commented Sep 11, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jamezp commented Sep 25, 2024

darranl commented Sep 25, 2024

bstansberry commented Sep 25, 2024