Define "Feature Request" terminology

[mmccool]

Proposal for process in meeting on Oct 9 was as follows:

• Separate use cases and feature requests.
• Feature requests can be in the form of user stories, and link a feature to a purpose.
• The purpose can be a single use case or a category of use cases (e.g. use cases needing efficiency).
• If accepted, a feature request becomes a requirement.

It would be good to create clear definitions of these terms, e.g. "Feature Request" (and use case, and requirement, and category). Will do so in the discussion part of this issue (or maybe make a PR for an MD file...).

See also:

• https://github.com/w3c/transitions/issues/new?assignees=plehegar&labels=Awaiting+Team+Verification%2C+Entering+CR&projects=&template=6.3.07-candidate-recommendation.md&title=CR+Request+for+%3Ctitle%3E+-+%3Cspecification+shortname%3E
• https://www.w3.org/policies/process/#transition-cr

[relu91]

I'm totally in favor of this new definition of streamlining "developer-oriented" requests. About "If accepted, a feature request becomes a requirement" I think it might be useful to have "acceptance criteria" as a field in the Feature Request proposal to extract actionable requirements because sometimes it might not be obvious from the user story.

In the end, we could have this simple template:

[Title]

As a [user type/persona], I [want to], [so that].

Use cases

• [Link to use case]
• [Short description of a range of use cases]

Acceptance criteria - optional

• Given [ some precondition]
• When [ some action or event occur ]
• Then [ some expected outcome ]

One thing that we might have to do is to prepare a list of readable personas or user-types (but the issuer might add new user types or personas if they want).