Gap Analysis of Milestone

[Mitzi-Laszlo]

This week we'll hit the next deadline for delivery of a milestone.

This issue is a place to do a gap analysis to compare actual performance with potential or desired performance. This is important so that we understand what works and what doesn't work so we know how to improve.

Please write down general comments but also asses specific issues and pull requests associated to this milestone.

This information can be used to decide which issues and pull requests to put into the next milestone. If you have specific suggestions about this please to raise that too.

[michielbdejong]

Can someone write down what the breaking changes are compared to what NSS currently implements? From what I heard through the grapevine, it's something like:

• Restructure JWT in Authorization header Bearer token
• Add AUTH command to WebSockets protocol
• Remove SPARQL-on-GET
• Remove Globbing

[Mitzi-Laszlo]

Let's definitely write down the breaking changes for NSS, but not necessarily mixed in with the gap analysis of the spec milestone. Perhaps open a specific issue for this? and link it here so people know where to go @michielbdejong?

[michielbdejong]

Ah right sorry, I had misinterpreted the term gap analysis. So I think one thing that went wrong during this process is that the team didn't publish a changelog document that compares the Dec-2019 version with the roughly-0.8 version. We can still try to fix that in #135.

[kjetilk]

Yeah, but that is because there is no document, since we were told it was more important to reach rough concensus on as much as possible rather than produce a document.

[csarven]

I generally agree that we should have some sort of an analysis and so useful to kick that off in the next group call as mentioned in https://lists.w3.org/Archives/Public/public-solid/2019Dec/0000.html .

We don't need to move issues to the next milestone. The first milestone was intended to round up issues pertaining to the ~FPWD (First Public Working Draft). If the community would like to see smaller milestones, we can look into that.

Perhaps we need to be more firm on the dates for milestones, preferably and more specifically the dates for each topic area per spec. We should also clarify the connection and expectations - information flow - between the Spec and Panels.

I agree that a document about spec diffs would be useful to (roughly) situate things. It can eventually emerge around the time FPWD is released. It may not have full coverage because some of the issues pertaining to the diff are intended to be addressed in later milestones.

[michielbdejong]

So then you mark them as 'at risk' or 'may change in a future milestone'.

[Mitzi-Laszlo]

Thank you everyone who joined the W3C Solid Community Group call today and joined the conversation. Here are some notes I made on points that were made over the call:

• The project currently covers multiple milestones. Let’s agree on how to track the long and short term targets (milestones vs. projects).
• Define the end game of the issue, for example, are we aiming for rough consensus or does it need to be written down as a draft
• There are some conversations on issues that have repeated a certain agreement or consensus but it would be good to record them. (5 identified major changes by @michielbdejong). More one-stop-shop documentation of the conversation needs to happen.
• Before we moved the spec to a new repo, we had one text and now we don’t. We need more text to work with, really hard to follow the conversation via the issues. Ok if single text is a draft version and clearly stated to be one.
• Perhaps we shot ourselves in the foot with the v1.0 because it's useful to have a draft version with open issues pointed to inline with the spec
• `Would be good to recap how the panels and the editors work together and make sure that the process reflects the reality
• Some work is happening on the panel repos and is doubled up on the spec repo, would be good to agree and document where what is being done by who
• Need to improve the bidirectional communication between the panellists and the editors to make sure both are aware of what the other is doing
• Positive experience with another project and in the end, it was decided to use one repo. Panels and editors should perhaps be working in the same place. Could also remove the gitter channels.
• If we don't use one repo we should really make sure that the project board is up to date at least
• Need to also make sure to get an overview of the work done pre panel and not think we are starting from scratch
• A lot of the issues are interrelated, how to cope with that?

Because next weeks W3C Solid Community Group call is cancelled due to the holidays, let's pick up this conversation on the following W3C Solid Community Group call to continue this conversation to translate them into action items:

1. how to improve the process
2. defining the next milestone for the 19th March

Saw that we ran out of time on the call and that lots of people had points to make. Great to see that this conversation was lively and useful. If you have any thoughts please do jot them down here to make sure we can respond to them and take them into account for the next sprint.

Thank you, everyone, for all the hard work getting here and feedback on how to improve going forward :) Great team effort!

[elf-pavlik]

👍 to using single spec writing repository with addition to

• already existing teams plus Github Code Owners feature to connect smaller specs to teams and improve notifications and code review assignments
• already existing labels which already seem to match panels

I think we should also consolidate all the use cases into common use cases document and use them as common reference for all the panels.