Categorization of user stories

[laurensdeb]

Background

During the WG meeting of 06/01/2024, we discussed the need for a more granular categorization of user stories than what's currently defined in README.md. A refined categorization system would help:

1. Better cluster user stories around higher-level capabilities
2. Identify target audiences more effectively
3. Group user stories impacting related classes of actors (e.g. client applications, server implementations, …)
4. Highlight potential duplicates or overlapping scenarios
5. Facilitate distillation of overarching use cases and requirements

Initial Proposal

One suggested approach is to categorize around higher-level capabilities:

• Authentication
• Authorization
• Notifications
• Data Management
• Data Discovery

Discussion Points

1. Do we see the added value of such a categorization at this point?

2. What additional categorization dimensions should we consider?

3. How can we structure these categories to best support:

   • Identification of duplicates/overlaps
   • Requirements gathering
   • Use case prioritization

4. How can we ensure this system remains maintainable?

Next Steps

1. Review and refine proposed categories
2. Establish criteria for categorization
3. Begin mapping existing user stories to categories

cc @hzbarcea - Would particularly appreciate your thoughts on this approach.

[hzbarcea]

A quick note before getting into more details. Authn and authz are related to identity and trust. We could debate if we want a more hierarchical structure, like id-authz or identity/authorization, but I don't think it's worth debating that now. I would just err on a random side and add as many labels as we want and organize them later. We could keep this issue open for a while until a pattern emerges.

[hzbarcea]

Comprehensive list of categories, updated as changes are made:

• Identity
• Authentication
• Authorization
• Infrastructure
• Notifications
• Data Management
• Data Discovery

[termontwouter]

Hi, @laurensdeb, and all. Thanks for the detailed effort you're putting into this. Here my two cents:

• Categorization will definitely prove an added value: it allows us to detect related (and possibly duplicate) use cases, which we can bundle in overarching user stories, and from which we can distill common requirements.

• I would not pick one kind of categorization over the other. A thematic one as proposed here can work perfectly alongside an architectural or business-level classification as initially proposed in the README. To be maintainable, each category should be clearly defined, though!

• For a better overview, I would also add labels indicating the main agent, and whether the use case is a general or a sector/application-specific one.

Here are a few groups I'd consider.

Requirement class

• Functional: specific features or capabilities
• Non-Functional: related to qualities of service, such as performance, security, scalability, reliability, maintainability, and (especially) usability
• Business: related to business operations, administration, management, specific business roles ...
• Technical: infrastructure tasks, operating constraints, platform constraints, proxies, caches ...
• Interoperability: related to other frameworks (e.g. Data Spaces), portability of data/policies/preferences, transition from/to different (possibly legacy) systems/versions, integration of services ...
• Exploration: used to explore or research an unknown aspect of the project

Thematic category

• Storage (~ data management): data types/granularity, querying interfaces, time series, streaming, asynchronous operations, encryption ...
• Identity/Authentication: profiles, claim, credentials, issuers, signatures ...
• Authorization: policy modeling languages, evaluation/decision engines, policy management, sharing, delegation ...
• Notifications: events, subscriptions, asynchronous interaction, (error) messages ...
• Data Discovery: user-specific endpoints, broadcasting/catalogs, aggregation, automation ...
• Applications: sector/application-specific use cases
• Legal: use cases having to do with legal considerations, micro-contracts, auditability ...

[bjdmeest]

To make it a bit a middle ground, I suggest to just have a big bag of categories (and, as Hadrian suggested, not introduce too much hierarchy for now), but I do like the more detailed descriptions of Wouter, as for me personally, it was hard to grasp what was meant by, e.g. 'Infrastructure', whereas the 'Technical' category as introduced by Wouter reads as quite clear

[kaefer3000]

As explanations are being written, I want to propose the following input, such that the categories ring the right bells. Remember that we are specifying interfaces and data models for protocols such that components can communicate, not the actual back-ends.

Comprehensive list of categories, updated as changes are made:

• Identity
• Authentication
• Authorization
• Infrastructure

Sounds to me too much like "AWS", thus with @hzbarcea s explanation from the lws call, maybe "Architecture Components" could be better.

• Notifications
• Data Management

Sounds to me too much like specific data management techniques like "a relational database", "a triple store", or "a file store", thus I would propose "r/w interface".

• Data Discovery

[w3cbot]

This was discussed during the #lws meeting on 13 January 2025.

View the transcript

Initial label set for user stories

acoburn: Hand over to Hadrien for user storie

hadrian: Authn and Auth are different. we should note this. I added the relevant labels. Labels are not exclusive.
… Question: when can I remove the triage from stories, and when should we close issues?
… Also another comment about keeping labels more coarse. I'm neutral to that.

acoburn: We will use labels to help categorize issues. We can start categorizing the issues already.

csarven: I think when we understand an issue well enough, we can remove triage. We don't need to worry to much for closing, as long as it's still relevant.

<bendm> +1 on csarvens comments

csarven: We just need a marker to denote we have already seen it and discussed it. Not necessary need to close it.

<Zakim> csarven, you wanted to suggest that no UC issue needs to be closed until much later e.g., when all issues are taken into account in the UC Note or postonned. Remove triage label when some specific labels are assigned (categorisation)

hadrian: One possibility is to allow issuer to remove triage mark. Otherwise it may be too difficult to manage.

acoburn: What if we leave the issue open, but if we agree the issue is well-disscussed, we remove triage.

hadrian: Yes. My question is: who should be responsible to remove the triage mark.

acoburn: Technically anyone can. I suggest editor can add/remove labels as appropriate. If it's not your issue, feel free to add labels.

hadrian: Thus I propose to add another label named "review", and assign it to original author. Give it 1-2 weeks. Then, move it to triage. If no response, close it.

acoburn: Writing that as a proposal

<acoburn> PROPOSED: add a new label, called "review", when the triage label is removed. Assign the issue to the author of the issue and provide 1-2 weeks for review

hadrian: I think that would satisfy anyone's needs

<TallTed> +1

hadrian: Yes, I second the written proposal

<hadrian> +1

<bendm> +1

<acoburn> +1

<balessan> +1

<laurens> +1

<ryey> +1

<kaefer3000> +1

<eBremer> +1

<jeswr> +0

RESOLUTION: add a new label, called "review", when the triage label is removed. Assign the issue to the author of the issue and provide 1-2 weeks for review

hadrian: Plus, anyone, if they are not satisfied with the assigned label, can change it
… This has addressed all my questions at the beginning of the call.

<acoburn> Proposal for labels

<gb> Issue 91 Categorization of user stories (by laurensdeb) [needs-discussion]

acoburn: For issue #91 in UCS repo. Can we do a quick poll for if we are happy with the current initial proposal? (Just a poll, not a resolution.)

<gb> Issue 91 not found

acoburn: (proposal by Hadrian)

bendm: We need the labels with descriptions

<TallTed> list of labels with descriptions

hadrian: Data management has to do with management of data. Infrastructure has to do with manage of system.

kaefer3000: In an issue, xxx3 is roughly equivalent to data management. I don't know if it's a misrepresentation.

hadrian: I think there is a difference. E.g. for portability, do we care about the underlying storage?

kaefer3000: I would say "data management" means "do we have a triple store, or file store"? Thus similar to infrastructure?

hadrian: Some people may still have issues, and there will still be some new proposals. But I think the current main item is whether the current category is a good start thing to use already or not.

csarven: Maybe we can expand the description of categories when needed. The issue author should also check if the assigned labels are indeed correct.

hadrian: Absolutely. Also, we should also add some links to README

<acoburn> csarven: yes, an initial list. not set in stone

csarven: I believe the list is not fixed. We will always update them. Point is: we use it to help us manage use cases. They are good starting points for me.
… If someone is assigned editor, they need to maintain uniformity. Hadrian should be in a better position to have the better say when needed.

TallTed: Agree current list is a good starting one to use, and we can refine things as we go.

kaefer3000: "Infrastructure" sounds to me like architecture, like what components we have. "Data management" sounds like what storage components are there. So somewhat non-clear, and needs clarification.

acoburn: It seems we generally agree the current list for now, and start using.
… Any further comments? No.
… We still have 10 minutes. we can start to add labels to some now, to do some demonstration.
… Hadrian, do you think we should try that now, or end early?

---