Skip to content

Latest commit

 

History

History
142 lines (101 loc) · 8.95 KB

2022-10-12.md

File metadata and controls

142 lines (101 loc) · 8.95 KB

W3C Solid Community Group: Weekly

Present

Announcements

Meeting Recordings and Transcripts

  • 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.

Participation and Code of Conduct

Scribes

  • Virginia Balseiro

Introductions

  • name: text

Topics

  • SC: This meeting follows #458 .
  • SC: Today's agenda is intended to help us (re)align a bit as a group.
  • SC: Please note that unless there is a decision to change the meeting datetime, it is always on UTC time (and daylight savings time is not observed as it stands).

Topics of Interest

  • SC: The CG weekly meeting will take up topics that are generally of interest to multiple or between contributors.
  • SC: Such as announcements, process, guidelines, feedback, as well as all Work Items.
  • SC: We are mindful of the available time. Deep and detailed discussions are encouraged to continue elsewhere.

Panels, Task Forces, and Getting Stuff Done

  • SC: We've discussed the state of Panels as well as considerations on forming Task Forces to carry out specific assignments provided that there is commitment, e.g., #458 (and links from there).
  • SC: Minor case in point: https://github.com/solid/webid-profile/ initially formed with a group to address a specific need. Similar initiatives could also work out with small or informal charters.
  • SC: Any brief additional feedback on this topic?
  • TH: Very useful to have a weekly meeting. Panels are too frequent, with overlapping discussions (authorization, authentication, interop, etc.) which make it difficult to advance.
  • SC: This doesn't mean panels are gone. This meeting is to check in as a group.
  • TBL: If panels are not working, why?
  • TH: Too many to make time for them. Implementing and prepping/attending meetings takes a lot of time, difficult to participate.
  • eP: Hard to pinpoint which topic belongs to which panel (overlap).
  • TH: Bundling all meetings in one helps ensure participation for those who have limited time.

Expected Completion of Work Items

URL: https://solidproject.org/TR/

  • SC: The Expected Completion column for the Work Items is updated to reflect information in Charters and based on Current Stage of the Work Item.
  • SC: I'd like to once again ask the contributors of the Work Items to submit PRs to update the table columns. They should take into account the goals of the Work Item, as well as test coverage, implementation reports, "adequate implementation experience", and so on.
  • eP: Question on meeting frequency of Editors. Seeing 2 minuted in last 3 months: https://github.com/solid/specification/tree/main/meetings
  • SC: Weekly. Some meetings have been skipped/not minuted for different reasons.
  • HS: +1 on it sometimes being difficult to work out where to make proposals because of the many overlapping panels. For example, the topic of #325 could be in Authorization, spec, WAC, ACP, ...
  • SC: Use the authorization/specification channels. If it's a topic of interest, we can pick it up, but for now engage in sub-groups.
  • SC: For future meetings, topics can be proposed. Issues can be raised when new task forces are needed.
  • PAC: Re: completion dates — useful, also would be useful to suggest reading order/prerequired readings.

Contribution Guidelines

URL: https://github.com/solid/specification/blob/main/CONTRIBUTING.md

  • SC: All feedback and improvements welcome.
  • SC: On a related note, are things and activities of interest findable? How can we improve?

Current and Former Editors of Work Items

  • SC: Revisit Work Items to see what needs updating. Here is one:

Update authorization-ucr's editors

URL: solid/authorization-panel#309

  • SC: This is a Call for Editors for authorization-ucr.
  • SC: The document can advance to TR if there is commitment from editors. Needs a serious update.
  • SC: Please follow-up on the issue.
  • eP: We should probably work on authorization as a protocol, as it encompasses everything else.
  • TH: Requirements are useful, but if we have an extensive list before implementing, it becomes a thought experiment. The requirements we currently have are mostly covered by WAC.
  • TBL: Agree that there are too many things to discuss. What we need is to reduce the issues so that we have a small number. Brainstorming phase good to map the space, but we need the minimum number of features that we need to begin with. If people say WAC is good enough, good. If there is a need for something else, document and specify.
  • HS: Advantage of having big picture (i.e., a number of more ambitious UCRs) is that gives you arguments when making decisions that might close future doors (if we do X, all these use cases will no longer be possible). Of course, one then needs to limit oneself to a subset of the UCRs when working on a particular spec.
  • MB: Do people agree UCRs should be worked on to clarify minimum and future use cases we want to cover? Is it possible for a task force to focus on UCRs in the near future (whether we think use cases focus on Authorization or Solid)?
  • SC: UCRs or solutions do not need to cover every possible scenario.
  • SC: Re: authorization being central — same can be said about authentication and other things. We need to listen to what application developers need. We can raise these topics in these meetings. Yes, pick up UCRs.
  • MB: Can I suggest action items here?
  • SC: If on topic, yes.
  • MB: The authorization panel has been quiet lately. It would be great if anyone interested in picking up the authorization UCRs would signal on the issue. We can coordinate a time (authz panel time clashes with this one). UCRs would be a great base for implementation feedback; see where we are and understand where we're going.
  • SC: UCRs do need a proper review. It's been labelled as good and useful or too hypothetical in other aspects. We have many contributors but we need a few dedicated editors who are committed.

Quality Assurance

  • SC: As the Work Items progress, we need to ensure QA.

  • SC: Synchronizing QA activities with specification milestones.

  • SC: Using the Test Suite Panel Charter as start: https://github.com/solid/process/blob/main/test-suite-panel-charter.md

    operate with a mutual understanding between contributors to technical reports, test suite software maintainers, and software implementers by following a cooperation process

  • SC: Please familiarise yourself with the aims there as that will be integral to how we communicate level of adoption.

  • SC: See also #402 and https://github.com/solid/test-suite-panel/ .

  • SC: Defining the QA process is one of the things we need to do.

  • SC: At some point, when a TR reaches a recommendation/maturity level, we need to signal that there are tests and that implementations conform to the specs. We need those reports linked from the specs. It is a stamp of approval that an implementation conformed to these rules; tests and reviews were approved.