feat: Update issue templates & process docs

[ADubhlaoich]

Proposed changes

This commit updates the issue templates into the repository, converting them from plain Markdown templates to interactive forms. It also updates the process documentation, re-organising them into topic groups and adding guidance on the level of desired detail for requests.

Checklist

Before sharing this pull request, I completed the following checklist:

• I read the Contributing guidelines
• My branch adheres to the Git conventions
• My content changes adhere to the F5 NGINX Documentation style guide
• If my changes involve potentially sensitive information¹, I have assessed the possible impact
• I have waited to ensure my changes pass tests, and addressed any discovered issues

Footnotes

1. Potentially sensitive information includes personally identify information (PII), authentication credentials, and live URLs. Refer to the style guide for guidance about placeholder content. ↩

[github-actions]

✅ Deploy Preview will be available once build job completes!

Name	Link
😎 Deploy Preview	https://frontdoor-test-docs.nginx.com/previews/docs/1287/

---

[mjang]

I read "operable state" and I think "Oh, the software is still working with these docs, we can address the issue later"

Suggested change

	- If an issue leaves users in an operable state, it requires intervention immediately
	- If an issue leaves users with broken software, it requires intervention immediately

[danielledeleo]

Inoperable?

[travisamartin]

"If an issue leaves users in an inoperable state," or the system/product/whatever? I'm guessing the users are probably ok, operable.

Maybe: If the system or product breaks and users can’t do their work, the issue should be fixed right away.

That breaks the "If an issue ..." pattern, but that might be repetive.

[mjang]

General comment:

IMO, it'd help focus the person who creates the issue to write this in the 2nd person / active voice

[travisamartin]

Suggested change

	It's written from the perspective of a user, whose priorities are often different from your own.
	The users for each story may map to specific user personas dependent on the required content design complexity.
	A user persona reflects a broad set of demographic criteria, representing a type of person who may have different levels of experience, domain knowledge or priorities.
	Acceptance criteria are used to determine whether or not the need identified as part of a user story is fulfilled.
	Much like the user story, it is the user perspective that defines how acceptance criteria are written.
	Write user stories from the user’s perspective. Their goals may not match yours.
	For each user story, think about which user persona it maps to. A persona represents a type of person with shared traits like experience level, domain knowledge, or goals. A user story written for a DevOps persona will look different from one written for SecOps.
	Use acceptance criteria to define what needs to be true for the story to be complete and the user’s need to be met.
	Just like user stories, write acceptance criteria from the user’s point of view. Focus on what they expect, not what you want to build.

Taking a stab at second-person voice, speaking directly to the reader completing the form. Also, lowered the reading level from 13 --> 7 (style guide recommends 8-9).