Skip to content

Latest commit

 

History

History
151 lines (119 loc) · 15.4 KB

2022-12-14.md

File metadata and controls

151 lines (119 loc) · 15.4 KB

W3C Solid Community Group: Use Cases

Present

Announcements

Meeting Guidelines

  • No audio or video recording, or automated transcripts without consent. Meetings are transcribed and made public. If consent is withheld by anyone, recording/retention must not occur.
  • Join queue to talk.
  • Topics can be proposed at the bottom of the agenda to be discussed as time allows. Make it known if a topic is urgent or cannot be postponed.

Participation and Code of Conduct

Scribes

  • Jeff Waters

Introductions

  • name: text

Topics

  • SC: This is a special topic meeting focusing on reviewing the existing material, and identifying areas to improve towards the development and integration of Use Cases.

Previous Meeting

URL: https://github.com/solid/specification/blob/main/meetings/2022-12-07.md

Next Meetings

  • SC: The next meetings in December are scheduled for 2022-12-21 and 2022-12-28.

Process

  • SC: Intended to identify areas for integration of use cases. We won't be talking about specific use cases; this is about process, documentation, discovery, guidelines, surveys, and so forth. Basically covering material that we have, and how we can put it together to make people more aware of it and how they can contribute. Nothing here is written in stone. There is room for improvement. I'll share some things we have, topic by topic, and people can share how they found that information, and whether it is useful for them. First, https://github.com/solid/process/ describes stakeholders, documenting use cases, and encouraging adherence to the W3C Web Platform Design Principles' Priority of Constituencies.
  • SC: Put users first; we look at what users need before other stakeholders.

Technical Reports

  • SC: User stories: https://github.com/solid/user-stories/
  • SC: There are 122 user stories submitted there, and we can pull a story as needed for the work item.
  • SC: Call to deliver Use Cases and Requirements (UCR) documents alongside Technical Reports (TR):
  • SC: Current UCRs:
  • SC: Involving the DEIT (Diversity, Equity, Inclusion Team) to review UCs:
  • WT: Two small questions; one is the user stories issues list: who manages that? Who puts on the labels and so on?
  • SC: Anyone can submit a user story. It's for the organization of it, the tagging, I'd have to double-check the access controls, should be open to anyone in the community. If issues labeling, I can circle back with you.
  • TBL: I suppose ... high level roles .. for solid in general, ... they want to, not just produce a list at one level, but recognize some are, I should be able to like somebody's stuff, high level, social media to collaborate, why we are doing all this, ... point to high level one that when you try to match them up to low level ... encourages to long term ...???
  • SC: You are cutting out a bit. Those who have high level view on user stories, some people who tag it initially, but people need to have awareness of all the user stories so they can manage it that way. Maybe this is something we can follow up on. Most labels do not have a description, but we could improve that. Some are clear enough.
  • TBL: We also have a roadmap we could tie this to, things like media.
  • WT: Thanks Sarven and Tim. Useful to have a more clear understanding of the structure of the user stories, so we don't expect everyone to go through them all, but some indication "this might be useful to me cause I'm working on X or Y."
  • SC: The readme hints at a general form, As a User ...
  • WT: The form is good but if just users could label them in a few ways, then someone else could go through them and add some more useful labels or categorization. Just a thought.
  • SC: We need people to take on that task. We don't have to decide now. At low level, anyone can provide some labels. Then peer review to have others help with labeling.
  • TBL: Some projects, developers don't know much about, developers and users different groups, producing user cases could be well understood, how much trouble to also do this, so if being raised by users, they become use cases and justifying them not by going through some big triage, user feedback is valuable for bugs, requests, enhancements, to determine where to put effort into project. So these are things you could pick up quickly.
  • SC: The questions that Wouter raised could be framed as an issue to help improve the readme?
  • WT: I can do that myself, I'll make an issue of that.
  • SC: Thank you and feel free to share in Solid anywhere to draw attention. I'm not sure everyone is aware of the repository or using it.
  • WT: Yeah, I didn't know about it, it's great.
  • SC: Perhaps next topic? Anything more on this? (no)

Contribution Guidelines

  • SC: How to contribute to user stories/cases (documentation and in meetings):
  • SC: Describes participants proposing topics before or during meeting:
  • SC: Topic proposals following the meeting template:
  • SC: I'm not sure if there are other guides or documents that exist and where people can get hold of them. I'm just laying out what material we have and what we need to improve. There are meeting guidelines and template.
  • TBL: Is he person who originally brought up the importance of use cases on this call?
  • SC: No. But I can reach out to them and point them to the minutes.
  • TBL: Would be good to know what areas she thought we were missing.
  • WT: I just wanted to say, since you mentioned pointing to minutes of the meeting. The template to the meeting provides a nice overview and maybe we can save it and use it as a back reference. The one you filled in for this meeting. Also I was browsing Sold project website and I don't see a contributing page. You can click on the specification itself and through to the github repo, but no nice page with these links, you have to discover them through github.
  • TBL: Good point. I agree.
  • SC: There is a Solidproject.org repo. https://github.com/solid/solidproject.org/
  • SC: To enable PR's to address issues.
  • TBL: Change the website to add a link to contribute.
  • WT: I'll propose that.
  • SC: Thank you for volunteering to do that. I like the idea to turn info in these minutes into its own document somewhere. How you can contribute on Solidproject.org
  • WT: I can start from these minutes
  • SC: Other info out there if comb through chat or whole Solid organization, though some may be outdated. Anything else on contributing guidelines? (none)

Surveys

  • SC: There is WIP on Solid Community Survey that will be published on solidproject.org - by VB / Solid Diversity, Equity and Inclusion Team (DEIT).

    Through the survey, we wanted to learn about the members who comprise the community, discover issues people might be facing within the community, and how to make the community stronger, more welcoming, and ultimately, larger.

  • SC: Results of survey published on this link.

  • SC: Is the survey collecting what we need? We could put together survey to collect information about where people are finding info, how people are being notified about meetings, etc. I could create an issue on that, and we can come up with survey questions and look at it in follow-up meetings. Any ideas on that? The scheduling, whether meeting time is ok, languages that user stories are available in... I'm just looking through the survey and thinking of how it applies to use cases.

  • WT: This is so broad, it's hard to pin something down. You are just talking about a survey, not something already delimited in a way?

  • SC: In context we are talking about, which use cases may be of interest to implementors.

  • SC: Let me pull this link up, I've been pushing this for a while, but then we put it aside.

  • SC: One survey to collect some data about proposed use cases, commitment to implement, or already implementing. This is quite important before dividing into actual requirements in a spec. It is also good signal to the community whether a feature will actually be implemented — toward "adequate implementation experience" as per W3C Process.

  • SC: We did a similar survey in the W3C Social Web Working Group. Issue #9 from earlier mentions this as well.

  • SC: Use case being proposed, anyone contributing can say "yes it is worth doing", "I'm kind of for it", "can live without it", and other options. This is the template I was proposing for our understanding of the use cases and how it maps to a requirement in a spec.

  • WT: Seems like a good thing to do. Then which use cases, right? If we agree this is a good format, then which use cases do you want to provide to do the survey with? The given UCR, there are a lot of use cases surveyed.

  • SC: This is one of the steps just before writing a line of the spec. Just because someone proposed a use case, doesn't mean there has to be a requirement from it. It's to get a signal from the community that there is a significant number of parties interested in a requirement of this use case.

  • PA: I see in Issue #9, one issue document per spec, I'm not sure this is the right granularity. For example, for SPARQL, specifications are focused on a particular use case, might be transversal. My gut feeling is it might be more efficient to have use cases pointing to the specification they touch on, not necessarily to segregate use cases per specification.

  • WT: +1

  • SC: That's interesting. The practice I was following was LDP working group. I understand different groups may work differently. LDP UCR does not have a back reference to a requirement from the LDP spec. I don't know if another document somewhere that maps functional requirement #1 with a requirement in the spec. No link from either document to the other. Is that the connection you were looking for? UCR to requirement?

  • PA: My point was that the scope of each specification might be too narrow to justify use cases about that specification. I would feel more comfortable with one use case document, maybe not for whole Solid, but for core portions. There is a use case document from RDF Access working group that produced SPARQL. They don't point to specific recommendations they produced, but they have one document for use cases that covers a number of specifications.

  • SC: Good point. I don't think we have that. The user stories come close to that as a collection of things. As you can see, only two or three attempts at having UCR documents in context of authorization and notifications. Anything from Solid Protocol wasn't thought through more than institutional knowledge, derived from lessons learned from LDP. Are you suggesting we should have one overarching use case document? For all work items in Solid ecosystem?

  • PA: Yeah, it's a gut feeling, it would make more sense.

  • WT: I think I second that. We do have two big files with use cases now but even in those, there are subdivisions into sub-specs, so why not make one file of it and have different sections and label accordingly. I think that would be nice.

  • SC: We could. Accidental bottom-up that we have general need for a component like authorizations or notifications, some spec is needed focused only on that. You can take a requirement like creating a container by(???) listening to updates to a container, they could go in same use case document, the approach here was that they are specific enough so you could have different solutions, so notifications could be a solution to listening and left in its own document. Since this is somewhat bottom-up, we could merge or create a document that touches these different areas.

  • WT: Don't stop on account of me. I wanted to say to give the example about notifications, a use case involving notifications is never completed without also some implementation of authentication and authorization. So people from authorization have to know to look there as well that involve authorization but are not in our use cases, so if in one document, easier to find.

  • SC: Good clarification. Thank you for raising that. We should have a closer look at how we make it more obvious. We could have SeeAlsos, but I suppose in case of authorization, you would need use cases around notifications or considerations of how spec would need to advise while direct access may not be enabled through the spec, information can be shared in other ways, implementors may need to be aware. A spec could expose info not intended by authorization spec. Something we need to discuss in panels as well.

User Testing

  • SC: Getting users involved early on before we come up with specs, for example whether authorization system should provide 3 or 4 access modes or 27. And what the UI might be like. Any thoughts on that? Do we need to do user testing and so on?
  • PA: I think that's a great idea. I'm not skilled in that area but sounds like having user tests and usability feedback is important so +1
  • SC: Perhaps that's something we can integrate into the spec development process if people are willing to run early tests on approaches. I'm thinking out loud here. Perhaps other W3C groups/initiatives like the Accessibility or Internationalization have experience with this. Is this something you could look into for us, PA?
  • PA: Yes. One remark, I was surprised to see that EARL was created by Accessibility of W3C and user tests and reporting results in structured way. I'll look into what process is used in those groups.
  • SC: Thank you. I think we can wrap up for today. If other thoughts, please do chime in. I'll try to reach out to people who should be aware of the minutes and Wouter you can glean what you want for links and other information. Thank you. Have a nice week everyone.

Propose Topic Title

URL:

  • Proposed by: name
  • name: text