feat: add a use cases template for github issues

[laurensdeb]

This is a proposal for a Github issues template for use cases for the LWS WG, all feedback is welcome.

The template was loosely inspired on
VC Use Cases
DID Use Cases
WOT Use Cases

[acoburn]

LGTM

[renyuneyun]

First of all, great to see this moving. More than happy to convert my existing ones following a template.
But I do have questions (see below) on the template itself, from a newbie's perspective. Hope more explanations or examples are added, or template being revised.

1. Does "precondition" refer to preconditions in terms of features or other use cases, or precondition of the exact use case (e.g. what types of data are stored in the Pod, and then the use case exists)?
2. What does "trigger" really mean? Why and how is it different from the scenario itself?
3. What should be included in "alternative cases"? In particular, do they refer to "alternative use cases (which may fulfil the same / comparable functionality of this use case)"?

[csarven]

Added some clarifications and suggestions for group's consideration.

Perhaps instead of or in addition to "assignee", the proposer should indicate things along these lines. So this could be integrate into the template:

• will implement potential solutions
• will share implementation experience
• will share code implementing the requirements that come out of this use case

[csarven]

I'm not sure I understand this in the template.

Suggested change

	assignees: ''
	assignees: ''

[chrisn]

LGTM, and support csarven's suggestions

[laurensdeb]

@renyuneyun This is still a first revision of the use case template, I'm sure when actually using it for the concrete use cases it will still need some refinement.

To answer your questions:

Does "precondition" refer to preconditions in terms of features or other use cases, or precondition of the exact use case
(e.g. what types of data are stored in the Pod, and then the use case exists)?

I would interpret preconditions quite broadly, these could also refer to other use cases. For example, "a user must have a LWS-compliant storage server" or "a resource must have been created in the storage server".

What does "trigger" really mean? Why and how is it different from the scenario itself?

Typically I see a use case as something which is triggered by a particular event. For example, a user stores a resource in a LWS-compliant storage server such that it can be shared or retrieved later on (the use case) by performing an HTTP request to the storage server (a possible trigger for the use case, of which there can be several).

What should be included in "alternative cases"? In particular, do they refer to "alternative use cases (which may fulfil the
same / comparable functionality of this use case)"?

Alternative cases are instances of a use case which differ from the "happy case" scenario in a significant way, because some exception has occured during the happy scenario for example. For example, an IdP is unavailable for the storage server when trying to authenticate a client, how might we handle such a scenario.

[laurensdeb]

@csarven I've updated the pull request to reflect your proposed changes.

@hzbarcea I've understood from @acoburn that you would be finalizing the template, so I've added you as assignee. If you need any further input from my side, let me know. Else, I will leave this PR for you to merge or close.

[renyuneyun]

Maybe add a clarification for the mandatory status for each section (either here or at the section heading)? Or are all fields mandatory for the first draft?