Vision TF meeting

ACTION: Amy to extend the Vision TF calendar until 9 November

Chris: I sent out an agenda yesterday. Mostly I want to use the time today to examine what we need to resolve as a group to publish a next Draft and get to a Statement and what to defer to v2.
… Getting to a Statement is important. Florian also noted the 2 items marked as agenda+

Open PR on pointing to Web we are leading to

<cwilso> w3c/AB-public#128

Chris: This is an attempt to raise an issue Elika brought up, to point out the web we are trying to build toward.
… We talk about W3C but not the web. I did not have a lot of content. Elika, I'm not sure you've gotten to look at this.
… I'm happy to defer but I'd like to get eyes on it for ways to improve it
… I saw DanA added a suggestion but I'm not sure what it does.

Wendy:  It restructures a sentence so it's easier to parse.

Charles:  It chops it into 2 clauses, it's not a bad thing.

<tantek> +1

<cpn> +1

Chris: Ok. I am ambivalent but I hear 2 voices saying they like it.
... I'd like to ask Elika to review.

fantasai:  It's a good direction, it just needs to connect the sentences of the paragraph together better. I'll try to figure out how to do that better.

Chris:  Ok. if you can figure that out,  other things put in PR. I'll merge before the next meeting.

Tantek: I agree. I looked at that PR and it looks good. I'm ok to leave issue 118 open pending on feedback from Elika. I agree with more time for review.

Chris:  Great, thanks.

Examine issues marked as needed for Statement

<cwilso> https://github.com/w3c/AB-public/issues?q=is%3Aissue+is%3Aopen+label%3A%22needed+for+Statement%22

Chris: I took a stab at issues which need to be addressed; whether discussed and resolved or changes made.
… It's up for grabs. I'm not making any decision on what needs to be done. They just need to be done.
… I didn't see anything blocking the next draft, just publishing the Draft.
... If you have a pet issue to raise before publishing draft be ready to send that.
… I don't necessarily want to go through issues in depth. I want to walk through but don't expect to resolve.
… If people feel we should resolve before a statement or more important or prioritize; it's hard to get a sense of the broader group so I'm grasping for input.
... Consensus based editing is challenging.

<cwilso> w3c/AB-public#126

<amy> +1 to publishing draft

fantasai: I think all open issues need to be closed before we push to Statement.
... The next step is not Statement but Note which represents AB consensus.
… Before we can put this in front of the W3C either by addressing it or before review.

<fantasai> https://www.w3.org/2023/Process-20230612/#formal-address

<Ralph> [the selector currently returns #126, #120, #118, #115, #113]

Chris: I think every issue has been examined. One is on DRM and copyright. We discussed it.
... We agreed at the last Vision TF that this is something for the future but not near future. We'd defer to future version of Vision or in EWP.
… We're not closing or resolving it as we didn't agree it shouldn't be looked at.
… The Note stage is an important one as well.

Max:  A question on protocol: we keep coming to points where we want to publish. New issues come up, new readers.
… Is there a function to say "This is the last issue we review before publishing"?  Do we say "these are the issues, what we've considered, there will be more"?  Is this functionally allowed?

<chaals> [Yes, for the same "maturity level"]

<Zakim> fantasai, you wanted to react to gendler

fantaasi: There's a question of next publication on TR. That will be the consensus of W3C.                 
… For the question of TR, as soon as we're happy w/ changes we should publish.
… We just did a significant rewrite, so are deferring publication until we're sure we didn't regress anything. But once we get this edition on TR, we should publish everything as soon as we accept changes, so that the Editor's Draft is only used for our internal discussion and review of Chris's proposed changes.
... There should be no need to go to versions to see what's live.
... For each edition of the document that's different. Let's address most things but there might be specific issues like Chris just brought up to defer.
… But it will be few issues in that category. Most should be in the final edition.
…  It shouldn't be "the wording is off" but "we won't address this topic."

<tantek> +1 fantasai

Chris:  Capturing what category issues fall into is how we lock that down. In the next few weeks we'll start not adding new things for Note.
… Unless the group agrees they are high priority.

<Zakim> tantek, you wanted to agree with Elika and suggest taking up issue 113 since we nearly resolved it in our TPAC f2f

Tantek:  I strongly agree Elika and Chris. Per Elika publishing work mode, we should propose to make a Note.
… Let's see if that goes. I don't see anything as a Note blocker before we move onto issues.

Chris: Yes I do want to end this meeting or somewhere with a call for publishing a Draft. It's a draft not at Note.
… We published a Draft.

fantasai:  It's a Draft Note. When we have AB consensus it can be an AB Group Note to say it's as done as the AB gets.

Tantek:  Not requesting status change but republishing.

Chris:  That's exactly what I want.

Tantek:   Maybe we don't need to review issues before proposing republishing with current status as previously published. So like Elika said, any changes.

<fantasai> https://www.w3.org/2023/Process-20230612/#formal-address

<Zakim> Ralph, you wanted to comment on Elika's question of "addressing"

Ralph:   My question was similar to Max. To be clear in the minutes, what addressing means, Elika, I understand that acknowledging we see the issue and deciding to defer to a later version is one way to "address" the issue; i.e.. we saw the issue and addressed it for now.
… Is that what you intended?

fantasai:   There's a concept of formally addressing issues and that's what I want.
… Addressing can be changes, rejecting issues or saying we plan to do it later.

Florian:  That's part of what I wanted to say. Not only should we do this; we must.
… It's a Process requirement to become a Statement. As Elika just described, every issue raised must be addressed.
… We can say it will be done next time but we must respond.
… To elevate to Statement we will have wide (horizontal) review. We should publish frequently.
… Depending if we go to publishing now or other issues I might have a statement.

Chris: I planned to build to this. Is there anything that stops us publishing a Draft Note?

<cwilso> (that's issue https://github.com/w3c/AB-public/issues/105)

<Zakim> chaals, you wanted to react to florian

Charles: I'd be unhappy if we published without unlinking claimed history.
... I think that's contested. I've written an issue. Depending on how we think of it,  my objection might be resolved but right now that's an issue.

<Ralph> [I tend to concur with Chaals re: the "history" bits]

Florian:   I see three issues to be addressed. As set up, history has been published as an appendix of the previous version.
… There's a draft that would allow us to publish as addendum. Something at the bottom of the document.
… Options are: just keep link to old thing and keep moving, or remove link. No one is saying we should maintain history.
… Given the combination, maybe keep link or no. Charles is insisting on removing the old link. I suggest we remove link from new version and if they want to discuss they can link to the dated version.

<tantek> sounds like we are taking up w3c/AB-public#131 as a draft note blocker

<fantasai> wfm

<tantek> +1 wfm too

Chris: I don't know why you filed two other issues. I want to use issue 105 for publishing or not.
... I'll ask a specific question to resolve that. Issue 105:  what we do with history? The option we've been moving toward is "this is not relevant for ongoing versions" and we can leave in GitHub.

<florian> https://github.com/w3c/AB-public/issues/131, https://github.com/w3c/AB-public/issues/130, w3c/AB-public#105

<Ralph> [w3c/AB-public README claims HIstory.md as a "live editor draft"]

fantasai:  We already removed it from the appendix, currently it's just a link now.

Florian: Charles is arguing for removing the link too. I think unless we're maintaining this we can remove  it from GH.
… We don't need an Editors Draft.

Chris:  Did you remove from appendix since the last Draft Note?

fantasai:  When I prepared it I noted it was linking to a GitHub document called History. The problem was I can't publish to TR linking to GH.
… I inlined into an appendix of the new document and published into the first public Draft Note, with an explicit note that it will be removed in the next publication (and only exist in dated space). It's now in TR and will be there but I noted we'll remove it when we publish even for a typo.
… I shoved it in an appendix with the objective of removing it.

Chris:   Anyone object to removing this?

<fantasai> PROPOSAL: Remove link to History

Florian:  The text has been removed. We're asking to remove the link to the dated version.

<fantasai> +1

<cwilso> PROPOSAL: remove link to dated version of text

<wendyreid> +1

<AramZS> The markdown doc is gone too, not sure if that matters

<chaals> +1

<AvneeshSingh> +1

<AramZS> +1

<tantek> +1

<florian> +1

<cwilso> +!

<cpn> +1 to removing the link

<koalie> +1

<Dingwei> +1

<amy> +1 to removing the link

<Ralph> +1 to remove the link to the unmaintained "history"

<gendler> +1

Chris: I'm not seeing anyone object to this.

Florian:  As soon as this passes, I have a question.

RESOLUTION: remove link to dated text of history

Chris:  Let's call that Resolved.

<florian> https://github.com/w3c/AB-public/tree/main/Vision/History.bs

<chaals> [I am satisfied that RESOLUTION closes https://github.com/w3c/AB-public/issues/131]

<fantasai> PROPOSAL: Remove ED of the History, in favor of copy on TR

Florian:  Given we're not publishing and not maintaining, the equivalent of an Editor's Draft does not need to exist. And so I think we should delete the Draft we're not maintaining. The dated version is enough.

<fantasai> +1

<cwilso> +1

Chris: Let's ask that question. Anyone object to removing that?

Ralph:  What's the social understanding of deleting something from GH? As someone who hates to delete any conversation to how we got to this state, what does delete mean here?

Chris:  In the current repo you can still read it but it's clear it's not a maintained piece.

Ralph:  It's different than saying "historic value."

Chris:  We're declining saying "historical value." For archival value you can find it.

<AramZS> So removing the file from the tip of main is what we're talking about

<cwilso> yes

<AramZS> Got it. Thanks for confirming cwilso

Charles: I share Ralph's concern. There's a difference between rip up and throw away and change it to say "we don't stand by this" with an empty document.
... I'm not sure we say what those things mean. We do on TR have this. I'm not terribly concerned by Tantek's point. We can resolve later.

<Ralph> [I don't consider the question of whether to remove history.md from the repo is a blocker to publishing]

<fantasai> +1 Ralph

Chris: I want to resolve Tantek's question. I'd have said I want to resolve 130 and 131 which is to remove this. As the person who filed these is that acceptable?

Charles: 130 is resolved. 131 it's not clear. We should replace with a document to say we don't agree enough to leave as a draft. Do we disappear the document from GH or leave a stub is a question worth thinking about.
… In TR you don't just delete but say where you can find it.
… Echoing Ralph's concern, I'm not particularly worked up about which we do. It's a W3C wide and perhaps AB issue to say.
… It would be good to say what this means, to remove a document from GH.

fantasai:   I think we're going way too far.

Charles:  We're in the weeds.

Tantek:  Let's stay on target: Draft document.
… We don't need to fully clean everything up.

Chris:  I request to not use terms like "claiming something is bunk."
… I think we have resolution.

<chaals> [fair point about issue title]

<tantek> PROPOSAL: Close 131 as resolved by removal of the link

<Zakim> tantek, you wanted to ask if this resolves 131 and to also ask is this a draft note publishing blocker?

Tantek:  First, let's close 131.
… Second, back to topics that are Draft Note publication blockers. Charles said further discussion of 130 is not needed. Let's move on to publish.
… No one else said they have publican blockers.

Chris:  Let's pause on putting resolutions in irc without saying them. I think that 131 is a duplicate of 135.
… I don't think we need a resolution. We have a path forward. Any Draft Note blockers?

<cwilso> PROPOSAL: We should issue another draft Note after resolving #105

Chris:  A different proposal: we should issue a draft note after resolving 105.

<fantasai> +1

<wendyreid> +1

<chaals> +1

<florian> +1

<cwilso> +1

<gendler> +1

<tantek> +1

<cpn> +1

<Dingwei> +1

<Ralph> +1 to publishing an updated draft Note

<amy> +1 to issuing a draft note after resolving 105

<koalie> +1

<AramZS> +1

RESOLUTION: we should issue another draft Note after resolving #105

Chris:  Not seeing any dissent, I'll call this resolved.

[Tantek leaves]

<Zakim> florian, you wanted to respond to tantek

Florian:   Sorry for creating a side track. I thought deleting this was trivial so let's discuss later.
… Just to note there's not full agreement about what should happen to an Editors Draft of discontinued TR documents.

fantasai:  That's a question for Process CG.

Florian:  I'm not proposing to discuss, just to get on the record we're not sure this is true.

<fantasai> Fwiw, the Process says that documents intended for consumption outside the group maintaining them are supposed to live on w3.org

<fantasai> So deleting things from GH should be fine because nobody should be publishing there :p

Chris: I believe you're correct, we don't have a policy on this.
... With that I think we have one other agenda issue.
... Nigel is not here so I won't raise it. I thought we could clear it out.
… We have no Draft Note blockers. We're resolved to publish. The next question is how to use the time.
… Should we go through issues from the top, to resolve before publishing a non Draft Note?
… Is there a difference between publishing what we need for Note and Statement?
... If we have the ok and AB consensus we can take to the AC.

<Zakim> chaals, you wanted to react to florian

Charles:  The AB can publish what it wants to Statement. Whether the AC agrees is another thing. If the AB agrees but not AC that's the obvious difference.

<AvneeshSingh> +1 Chaals

Chris:   There's a difference in consensus. I'm not sure the AB would publish a Group Note, not Draft Note, that they don't expect the AC to have consensus on.

<Zakim> Ralph, you wanted to discuss delete

Ralph: Charles pointed out a process question. I think the decision for this group is what additional work might we think we want to do before publishing a "final" version on the Note,
… to be considered for proposal as Statement.
… I see a few issues marked as "needed for Statement". We might look at those before we publish final best effort Note for consideration.

Chris:  Ok.

Coralie:  I think issue 126, smoke testing, is unlikely to resolve in time for a "needed for" Statement.
… I don't think we can label as "needed for" Statement. We haven't progressed enough to label it as that. The others are fine.

<Zakim> cwilso, you wanted to react to koalie

Chris:  I will respond. I don't think we will fully, it's an ongoing test. How will it apply in real world? I was trying to capture, as is suggested, take whatever static level we get to in the Vision,
… apply to challenges and see if it's useful and presuming it helps, we move on. I think we should try it out once before going to Statement.

<koalie> [Coralie agrees with the concept of the issue]

Ralph:  If i understand what you just said, Chris, it makes sense. I'd interpreted the name of the label as marking blockers.

<koalie> ditto Ralph

Chris:  I think we should block going to final Note until we do this.
… If we're not going to do that though I can close the issue.

Coralie:  What Ralph just said. I thought it was a blocker. Smoke testing is a good idea but not for this revision.
… Having read comments on this issue it seems we are not close to having a resolution. Therefore we should defer and not close
... or narrow our definition. If we close it we might need to reopen as it's a good principle.

<amy> +1 to koalie

<Zakim> chaals, you wanted to react to koalie

Charles: I don't think we're ready to smoke test the document now. I do think that it's unlikely the AC will accept anything as a Statement without running that test for themselves.
... It's unwise to convince them to do so without doing exercise and showing we did it. I suggest we leave this open
… and say we expect to do this.

<cwilso> +1 chaals

Aram:  I agree it's good to leave open. It's a good process to do. I think some confusion is whenever the process is not well defined.
... Maybe because I'm new but it might be good to define what we want to compare to and it would be good to write out. The process of the smoke testing could be better defined.

<cwilso> +1 Aram

<amy> +1 to Aram

<chaals> [+1 to Aram - would be good to be clearer about how we expect this to work before we claim we've done it. That seems like I am volunteering for an action item :S ]

<cwilso> https://github.com/w3c/AB-public/issues?q=is%3Aissue+is%3Aopen+label%3A%22propose+closing%22

Chris:  I propose a different tack to this. Please go through and mark any issues. Comment on them because I will go through and refactor labels as appropriate. The more input that goes into it the more I can guide.
... I would like to start cleaning things out that we've not looked at in a while.
… There are at least 2 that are easily handled. First, 115.
... This is about reference to UNDHR in the Vision. As DanA said, he filed it, since rights didn't make into Vision anchoring in EWP is good enough.
… If anyone objects, now is your chance.
... I think this is a good idea.

<cwilso> w3c/AB-public#115

<cwilso> PROPOSAL: close #115 with no action

<cwilso> +1

<amy> +1 to close 115

<koalie> +1

<fantasai> +1

<cpn> +1 to closing and leaving this to EWP

<Dingwei> +1

<Ralph> +1

<AramZS> +1

<wendyreid> +1

<florian> 0

<chaals> 0 (If we are leaving this to EWP, then I have a different issue as foreshadowed in issue comment, thus I'm not concerned about closing this one)

<koalie> https://github.com/w3c/AB-public/labels/propose%20closing

RESOLUTION: close #115

Chris:  Ok I'll close that.
... I want to skip around a small amount and go to #81.
… This was suggestion by JamesR we remove reference to EWP.
… I think it's important we do link to EWP and show we are having a progression of values in the Vision.
… I think we should refer to EWP and build on them otherwise we'll have to pull them into the Vision.

<cwilso> w3c/AB-public#81

<amy> +1 to close 81 (keep link to EWP)

ChrisN:  Does EWP also need to be a statement/? Linking to a Draft might not be appropriate.

Charles:  If we rely on EWP, including by reference, we need to be explicit that's what we're doing. It's a bit hand-wavey. The EWP is published on authority of TAG not W3C.
… If you close this it'll raise an issue to say we should incorporate EWP to say how we handle that.

Florian: EWP is informative of Vision. I do not believe it's required that they be statement. As opposed to @.

<Zakim> chaals, you wanted to react to florian to reply to Florian

Charles:  Procedurally that's fine. Conceptually we've resolved we wouldn't do stuff in this document because we rely on it being in EWP.
... We include EWP as if it's normative. It should be in a state where it's normative.
… Because we can't say this is covered in EWP,  pointing at a document vaguely isn't sufficient.

<Ralph> [in this case I concur with Florian; I find the Informative Reference to be both useful and appropriate]

<cpn> +1 chaals

Aram:  It makes sense to close this if we have a process for formality of EWP as a separate issue. We know the TAG is to produce this and will be a formal state
… and that is supporting the Vision. We can understand the TAG will produce this and it informs how W3C operates.
… If there's a problem with formality of the EWP this isn't what the issue addresses so it should be new issue.

<cwilso> +1 to Aram: if we want an "EWP should be a Statement" issue that is separate

Chris: I know TAG has the goal of publishing it as a Statement.

PLH:  It's a little awkward to have this reference. Out of 7 points, this is the only external reference.
… We don't try to define what it means to be royalty free, nor PP.  Here's it linking to one definition of EWP,
… trying to make sure it's precisely defined.
… For other items we don't try to say what we mean. We don't need to say every detail of the web to define Vision. We shouldn't try to define the @ platform.

fantasai:  You're referencing the older version. The new one doesn't reference the definition of sustainability.
... I think that's the confusion but it applies to a previous version.
… The reference in the intro is fine. It's awkwardly phrased, could be redone, but it's ok

<wendyreid> https://w3c.github.io/AB-public/Vision

<Zakim> chaals, you wanted to react to plh to note that the issue isn't about defining what EWP means, it is about whether we agree that those principles as written are effectively part of the vision.

Charles:  The point is that the issue is not whether EWP is defined or clear but whether we agree all stuff in EWP is part of this document.
… This document sort of says it is. We need to be more explicit about that. We need to make a decision.
… We can rely on the TAG to do it. We can say we'll copy and paste it here.
… The AC might argue on EWP. We can say let TAG argue. One way or another we'll need to address it before AC agrees to make a Statement.

Aram: I do think it's the core of issue 81. Do we trust the TAG to produce EWP we feel comfortable including in this document? If we do, we should close this issue and raise other procedural issues.

<cwilso> +1 Aram

<koalie> +1 Aram

<Ralph> +1 to Aram

Florian: I heard people saying "including EWP" that's not it. We're referring to it. It's not normative.
… We are not including it.

fantasai:  It's ambiguous.

<fantasai> Vision currently states "These core values will be clearly demonstrated by how W3C leads the Web forward: by being inclusive, principled, and continually striving to make the Web better through these principles and the Ethical Web Principles. "

<cwilso> PROPOSAL. Close #81 with no action; vision will refer to EWP at least informatively.

Chris:  We are referencing it, saying it exists. I'd like to suggest that want to get at the core of this, leave as is, or remove EWP.

<AramZS> Apologize for my phrasing, I did mean referring to it.

<amy> +1 to referencing EWP

<koalie> +1

fantasai:   Two points: intro and Vision of W3C.
… Both references need work need work but I don't think we need to remove them,  It's ok to close issue.
... We did remove references that might have triggered the issue to be filed.

<cwilso> +1

<Dingwei> +1

<plh> +1

<amy> +1

<Ralph> +1 to retaining the text and reference as-is for publishing a new draft Note

<florian> +1

<wendyreid> +1

<fantasai> +1

<AramZS> +1 to closing the issue

<chaals> -1 IIMHO there is a clear assumption that the EWP underpins this document. That either means "it's vaguely interesting but we don't stand by it", which IMHO is very poor document structure, or "we mean the thing in its entirety" which is the essence of a normative reference

<cwilso> RESOLVED. Close #81 with no action; vision will refer to EWP at least informatively.

Chris:  I will call that resolved.
… Charles I think you're asking for a better defintion of how this builds on that. I'd rather file that as a separate issue. No one is saying remove the issue but we will need to deal with formality of the document.
... We are over time so let's call this adjourned. thanks all!

<fantasai> +1 to filing follow-up issue to improve the way that EWP is referenced

<AramZS> Agree chaals concern makes sense to address as a separate ticket.

<chaals> thanks all

<cwilso> Chaals: works for me.

Amy: I think this is a great document. Thanks everyone for the work.