W3C home > Mailing lists > Public > public-personalization-tf@w3.org > April 2020

Meeting minutes for Personalization TF - April 23, 2020

From: Becky Gibson <becky@knowbility.org>
Date: Mon, 20 Apr 2020 16:21:28 -0400
Message-Id: <8C5EB84C-6909-46EE-BCF5-3E2F9BE0899F@knowbility.org>
To: public-personalization-tf <public-personalization-tf@w3.org>
The meeting minutes for the April 23, 2020 meeting are found at:  https://www.w3.org/2020/04/20-personalization-minutes.html <https://www.w3.org/2020/04/20-personalization-minutes.html>.

Text version below.

-becky

- DRAFT -

Personalization Task Force Teleconference

20 Apr 2020

Attendees <>
Present
CharlesL, Roy, becky, janina, JF, sharon
Regrets
Chair
SV_MEETING_CHAIR
Scribe
becky
Contents

Topics <https://www.w3.org/2020/04/20-personalization-minutes.html#agenda>
explainer See https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://www.w3.org/2020/04/20-personalization-minutes.html#item01>
Summary of Action Items <https://www.w3.org/2020/04/20-personalization-minutes.html#ActionSummary>
Summary of Resolutions <https://www.w3.org/2020/04/20-personalization-minutes.html#ResolutionSummary>
<LisaSeemanKest> https://github.com/w3ctag/design-reviews/issues/476 <https://github.com/w3ctag/design-reviews/issues/476>
<scribe> scribe: becky
explainer See https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer>
<LisaSeemanKest> https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer>
Lisa: I did a draft, John restructured - think it looks good. Added the pictures with the symbols in the beginner to help people understand
<janina> it's me
<janina> looking for my unmute button ...
<janina> don't disconnect me!
<LisaSeemanKest> who is zte?
<LisaSeemanKest> great...
<LisaSeemanKest> https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer>
Lisa: I made a few changes - mainly adding content; main issue is to explain what we are doing
... added more screen shots for language impairment
<JF> URL?
<LisaSeemanKest> https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer>
Lisa: stakeholder feedback and references and acknowledgments - TAG said those sections could be removed
<LisaSeemanKest> https://github.com/w3ctag/design-reviews/issues/476 <https://github.com/w3ctag/design-reviews/issues/476>
Lisa: issues from TAG at above link; they asked for exampled and screen shots; wanted considered alternatives later in doc.
JF: I moved it higher up because they are looking for an API and we don't have one - I wanted that to be clear
Lisa: but that is in the non-goals section that was moved higher; believe it is clarified that no APIs
... want to move down the section on vocabulary and other design considerations to be moved down
JF: I think part of the problem was overwhelming them with the use cases but no explaining the problem; we have a problem (which is well documented below in use cases) and they want to see solution first
Lisa: I feel the opposite - they are asking for more use cases; brief summary of solution and then use cases to explain the problems
<LisaSeemanKest> The Vocabulary Structure section is unnecessary in this context, as is Stakeholders
Janina: TAG needs to understand the problem we are solving. There is a balancing problem; make the use case stories terse so people get it; Until they get it the use cases may seem too long
Lisa: they said they don't need vocabulary - so I think we should take it out
JF: since this will ultimately be viewed by a wider audience - I think more information is better; put it later in the document
Janina: order is critical; everyone wants to top read
Lisa: I think we should take it out (but keep it); TAG said to take it out and if they ask about it we can add back in
... comment from JF about info in module 3 - I can put in those links; info about working memory and short term memory are addressed in module 3
JF: I couldn't find more examples in the wiki
Lisa: will remove sections that TAG asked to be removed - either out or to the end
JF: Stakeholder and feedback is still a bit confusing - I think TAG wants feedback, good and bad; Can we get that - show positive and negative feedback. Our section just has who this is for
... Heading says, "Stakeholder feedback and opposition" - not who this is for; List expression of interest from Athena and from Mozilla developer who built proof of concept
Lisa: we are late to our deadline - can we just remove this section
JF: if that is TAG recommendation, remove
... vocabulary IS What we are doing - the modules are the vocab. implementations; I think removing is defeating the purpose
Janina: maybe needs a quick comment that the vocabularies are the core of this work, but understanding the details in not critical to understand why - then link to those at the end
<LisaSeemanKest> The Vocabulary Structure section is unnecessary in this context, as is Stakeholders
JF: if we move vocabulary to deeper in the document, we haven't provided enough detail
<LisaSeemanKest> The "Technology Summary" should be framed in terms of "Considered alternatives", and included later in the document (and we weren't sure what things like "Authoring" were doing in that list)
Lisa: TAG says that vocabulary is not necessary
Janina: we want them to understand what we are doing without having to dive into details
JF: their template is focused on APIs - we don't have that; feel that moving vocabulary to the end of the doc. is self defeating - people understand by seeing the vocab. that is what we are creating
Lisa: Add the top two paragraphs about vocabulary but not the whole section (or rewrite)
JF: I thought about questions being asked - I thought I edited the document to best answer those questions. TAG doesn't understand what we are trying to do - we need to explain it to them
Janina: Do we need to say at the top that this is not an API;
JF: I had added some bold formatting that got removed
Charles: I added back in
Lisa: Then leave in vocabulary implementations and explain why to the TAG
Janina; if you are grokking what we are doing, you'll see that vocab. is essential
Lisa: asked for name change: design alternatives should be considered alternatives and move to the bottom - any issues with moving or renaming that section?
JF: but I moved it up because the folks reading this will think of the alternatives and we need to show that we considered those - thus put it up in the document
becky: but they should know to look for the section for Considered Alternatives, it is their document format
Charles: have a compromise - have a section at the top that refers to more detailed sections as necessary
<LisaSeemanKest> The Vocabulary Structure section is unnecessary in this context, as is Stakeholders
Charles: they are going to see data dash in our examples; but tell folks up front that we have the reasoning behind using that
Lisa: one of the main comments is that we are not using their template
<LisaSeemanKest> Would it be possible to have a document more closely based on our Explainer template?
<LisaSeemanKest> https://w3ctag.github.io/explainers#explainer-template <https://w3ctag.github.io/explainers#explainer-template>
JF: disagree - they just wanted it better restructured to make better sense or to follow a template? I restructured to make it more understandable - if you disagree then rearrange
... my goal was the streamline the story for TAG; I believe the order of the info meets that goal: Big picture --> into the weeds
Lisa: I agree that the structure is good but they specifically asked us for something else
JF: thinks they asked for two things that conflict
Lisa: who wants to move the considered alternatives to the end of the document (after renaming as requested)
<LisaSeemanKest> do we move and lable the altervices as asked
<LisaSeemanKest> +1
Janina: we want TAG to understand and have their support
Lisa: but don't want to annoy the group by not following their recommendation
JF: but they stated it is an informal document
Lisa: I think they just wanted some of the more formal stuff at the beginning removed AND to follow their template
Janina: perhaps we should get some feedback - we shouldn't go in guessing what is wanted and we shouldn't have to
Lisa: Keep JF's structure - take out the stakeholder (we don't have the content, yet); explain that we didn't follow instructions exactly but we think they will understand this structure better - please let us know
Janina: yes, do this informally to a few people
Lisa: am worried about delays with that approach
charles: what if we present it as just the headings to let them see the structure
Janina: yes and allow them to be expand/collapsed
Lisa: want to keep the structure and just move forward - explaining the structure?
Janina: think the extra time is necessary to not get it thrown back at us?
Lisa: but want to get it published before WCAG 2.2
... we are already late for CFC for WCAG 2.2
JF: why do we have to be inline with WCAG 2.2
Janina: there is a SC that was going to point to our module
Lisa: am willing to go with John's structure but don't want it thrown back in our face
<LisaSeemanKest> The "Technology Summary" should be framed in terms of "Considered alternatives", and included later in the document (and we weren't sure what things like "Authoring" were doing in that list)
Janina: we don't know - because it seems they didn't get it
JF: but the request was because they were looking at this as an API which it is not
Janina: getting TAG support is more important than keeping with WCAG timeline
... still believe that we need to run this by a few people first before the entire TAG
Lisa: agree
... a few cleanup issues and then take it forward to a few reviewers
Janina: will take up with Michael first
<LisaSeemanKest> https://github.com/w3ctag/design-reviews/issues/476 <https://github.com/w3ctag/design-reviews/issues/476>
<LisaSeemanKest> https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer <https://github.com/w3c/personalization-semantics/wiki/restructure-of-the-explainer>
Lisa: would like another editorial review
... Sharon and Janina will review again - thanks
<LisaSeemanKest> action sharon and janina to reread the explainer. gramer, spelling and does it explain what we are doing
<trackbot> Created ACTION-53 - And janina to reread the explainer. gramer, spelling and does it explain what we are doing [on Sharon Snider - due 2020-04-27].
Summary of Action Items <>
Summary of Resolutions <>[End of minutes]
Received on Monday, 20 April 2020 20:21:46 UTC

This archive was generated by hypermail 2.4.0 : Monday, 20 April 2020 20:21:46 UTC