RFR: Requesting a change [v7]

[Iris Clark]

On Tue, 5 Aug 2025 19:19:07 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

>> Advice for people who would like to request an OpenJDK change to be implemented or backported.
>> Also added a note about having more than one noreg-label.
>> HotSpot issues in JBS must have a Subcomponent set.
>
> Jesper Wilhelmsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use bugreport

src/guide/contributing-to-an-open-jdk-project.md line 13:

> 11: ## Requesting a change
> 12: 
> 13: If you want to request a change to the JDK, but don't have the intention to implement/contribute to the change yourself, you should always go through [bugreport.java.com](bugreport.java.com). This is also the case if you find a change that you would like to see backported to an eralier JDK release. **Never** reach out directly to any developer. Also, please note that the [OpenJDK mailing lists](#mailing-lists) are intended for developers and contributors. These lists are not support channels or channels for requesting changes.

I like the revised text.  Maybe "always go through" -> "always report it at"

typo: "eralier" -> "earlier"

src/guide/contributing-to-an-open-jdk-project.md line 15:

> 13: If you want to request a change to the JDK, but don't have the intention to implement/contribute to the change yourself, you should always go through [bugreport.java.com](bugreport.java.com). This is also the case if you find a change that you would like to see backported to an eralier JDK release. **Never** reach out directly to any developer. Also, please note that the [OpenJDK mailing lists](#mailing-lists) are intended for developers and contributors. These lists are not support channels or channels for requesting changes.
> 14: 
> 15: Before you reach out, make sure you have read [Things to consider before proposing changes to OpenJDK code](#things-to-consider-before-proposing-changes-to-openjdk-code) and [Why is my change rejected?](#why-is-my-change-rejected) below.

In light of your revision in the previous sentence, perhaps "Before you reach out" -> "Before you file an issue"?

src/guide/jbs-jdk-bug-system.md line 217:

> 215: 1. If the issue is a duplicate, close it as such.
> 216: 1. If the issue belongs to a different area (it was filed in libraries, but it's an HotSpot issue), transfer it to the correct component/subcomponent making sure that the state remains [New]{.jbs-value}.
> 217:    * Please note that issues in the [hotspot]{.jbs-value} and [security-libs]{.jbs-value} components must have a [Subcomponent]{.jbs-field} set as well.

Are these the only components which require a subcomponent?  I know that client-libs and core-libs are quite large (https://bugs.openjdk.org/projects/JDK?selectedItem=com.atlassian.jira.jira-projects-plugin:components-page) so it wouldn't surprise me if there were similar recommendations there too.  Perhaps update to "issues in the hotspot, security-libs, and other components ..." to leave this possibility open without needing to survey all of the components?

-------------

PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2255205661
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2255228900
PR Review Comment: https://git.openjdk.org/guide/pull/155#discussion_r2255229005