Meeting minutes
PRs
<brent> https://
w3c/process#1021
<brent> Github: w3c/
Brent: I believe 1021 is ready to merge
… following lots of discussion
Florian: Last pending comment from @chrisn appears to have been addressed.
Ian: +1 to the text
Florian: +1
(No objections)
RESOLUTION: Merge pull request 1021
w3c/process#1129
<brent> Github: w3c/
Florian: Last time I said I would combine comments into a canonical text (done) and sent to PSIG (done). Now we await PSIG replies so let's leave open.
w3c/process#937
<brent> Github: w3c/
Florian: I'm still awaiting data from the Team.
Issues
<brent> https://
w3c/process#700
<brent> Github: w3c/
Florian: Yes, revisions are complicated. I have some ideas for simplification. One is easy, one complex.
… the easy one is to drop the distinction between Recs that can have new features once published and those that can't once published.
… the different scenarios create terminology explosion, so the simplification is to say "All Recs can have new features once published" but that would break old problems.
… but my suspicion is that, in practice, people don't rely on the historical promise.
… people who refer to dated versions will be ok since we don't update dated versions in place.
Brent: This is part of the AB's active discussion on process refactoring
… my inclination is to label this to indicate that this is a topic of active discussion.
Florian: Issue 700 is a general issue on "complicated process" but I think there may be a specific issue as well. We can label both as pending AB feedback.
Brent: I am ok with "pending AB feedback" but also "topic simplification"
Ian: How is the AB handling this (e.g., principles, use cases, etc.)?
Brent: We had a conversation at our face-to-face.
Florian: The related issue is #938
… I have a proposal for how to make it less confusing.
Ian: It would be great to identify promises/guarantees and work from there.
Florian: +1 to that comment. I think we can make some changes that "don't change promises" and create less friction.
Ian: It would be great to articulate guarantees and then have a strategic discussion of adjusting the dials (e.g., to get more streamlined approach)
Brent: That is approximately how we are proceeding.
… and when discussed, the conversations are in the AB's minutes
… I hesitate doing a PR before the AB has made progress.
w3c/process#714
<brent> Github: w3c/
Florian: There was not agreement on the 714 thread to make a change.
Proposed: Close issue 714
(No objections)
RESOLUTION: Close issue 714
w3c/process#712
<brent> Github: w3c/
Florian: Statements are being used. @mnot think that the checks can be abused and there's a risk of overstating the level of community endorsement.
Ian: Can someone characterize why Recs may be ok and Statements less so?
Florian: I think the thinking is that there are more occasions on the Rec track (in practice) for feedback
… see issue 712 for more detail.
Brent: Have concerns been validated through the processes leading to some Statements (e.g., Vision)
… I did not have the sense that it was pushed through without review.
Brent: What action might we take?
Ian: When we proposed a Sustainable Web WG, there was pushback against guidelines on the Rec track.
… I pointed out that there was a path.
… Through statements, which would seem a good fit for an IG deliverable, with enough opportunities for wide review and feedback.
… There is value that the boarder community has a chance to review documents before they become Statements.
… You could say that the TAG and AB bodies only get internal review as part of the Process, and we should add an explicit call for review from the rest of the community.
Florian: I believe that is already what the Process requires, but I believe that Mark is not confident that the verification that this has happened are sufficient
Ian: What are the signals that wide review was sought, say for the Vision Statement?
Florian: Blog posts, communication at various events, feedback on a public repository.
… Was it enough? We can argue about that. I would say yes.
… A possible step forward is that no one else seems to be complaining about Statements. Maybe we could give people a last opportunity to weigh in, and close the issue afterwards.
Ian: We don't have a way to easily reach all members of the community. Should we do that on occasion? IETF seems to be doing this once in a while. Could be used to seek feedback on specific proposals.
… We have opportunities for the community to gather around. TPAC. Breakout Days. Can we think of a community wide approach to do some of this?
florian: We have a way to reach to *anybody*, but only those who opt into it see the announcements.
Ian: Yes, public-review-announce.
https://
brent: My inclination is to say that this is a good question if a Statement comes through that has not been sufficiently been vetted. People can formally object to the publication in any case. It doesn't feel that there's anything for us to be doing here.
… My suggestion is that we propose to close this. Everyone who has commented on the issue will see the proposal and today's minutes, and may provide additional feedback.
Ian: I do note that the statements went through public-review-announce mechanism.
PROPOSED: Mark issue 712 as Proposed to Close
Florian: I don't think Statements are fit for purpose *when a very timely response is required* (e.g., call for review of CRA; but for the purpose where they have been used in practice, I think they are fit for Purpose.
w3c/process#727
RESOLUTION: Mark issue 712 as Proposed to Close
<brent> Github: w3c/
Florian: I think the requirements are against the most recent working draft (not the FPWD) but also if that's the case, then it's not a useful requirement.
… there are tradeoffs here as well: more documentation is onerous to produce, but presumed to inform reviewers
Florian: The priority of constituencies is important to consider here.
Brent: I think I agree with the assertion that the issue mischaracterizes the process. I do think that change logs are important to reviewers. Perhaps there's something to look at here more closely about the two points to consider when creating a change log.
Florian: Many changes happen between CR and FPWD and I can imagine diff is not helpful.
Brent: in the IETF, every internet draft goes through a series of changes and at some point the editors decide to publish a new version. With every new published version there is an expectation that major changes will be captured in a change log.
(No action on this issue at this meeting)
Florian: The appropriate thing might be to require it since FPWD and observe that it pointing to the GitHub log is probably sufficient.
Brent: I may not care about change log pre CR
Florian: class 4 changes may be useful for IPR reasons.