<LisaSeemanKest> https://github.com/w3ctag/design-reviews/issues/476
<scribe> scribe: becky
<LisaSeemanKest> 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
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
Lisa: stakeholder feedback and references and acknowledgments - TAG said those sections could be removed
<LisaSeemanKest> 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
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
<LisaSeemanKest> 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].
JF: would be good to get expressions of support from Athena - it would be good to include in the document now
Lisa: agree, perhaps the Easy reading folks, as well
JF: I don't think we can link with WCAG 2.2 - we are on different timetables
Lisa: hopefully we can work on the feedback from I18N next week
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: CharlesL Roy becky janina JF sharon Found Scribe: becky Inferring ScribeNick: becky WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 20 Apr 2020 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]