– DRAFT –
WAI Adapt Task Force Weekly Meeting Oct 3 2022

<Github> https://github.com/w3c/adapt/issues/203 : Unclear how the Bliss symbol examples should work with i10n/i18n.

<Github> https://github.com/w3c/adapt/issues/203 : Unclear how the Bliss symbol examples should work with i10n/i18n.

CR updates for new spec focused only on symbols

janina: believe we need to reorganize our approach; think we need a new FPWD and follow process

MichaelC: we have not entered CR; we are blocked on moving forward for with data- (or at least advised not to use).

Lionel_Wolberger: item symbols passed FPWD but originally there were 7 items; can we go to CR with just one item

MichaelC: content can get removed as working towards CR. We may need wide review but removing content after CR review can cause issues if someone is concerned about needs not being met/covered

janina: there may be people who have issues with removing info but we are narrowing the scope, we will get back to those other parts at a later date

CharlesL: wondering about our charter, will modifiying what we go to CR with break/invalidate our charter

<MichaelC> https://www.w3.org/2021/08/apa-wg-charter

MichaelC: the charter does allow providing additional modules

janina: July 2023 is when charter runs out; APA will have a new charter

Lionel_Wolberger: we do not need to republish a FPWD because we are mostly removing content

janina: we need to provide reorganization and fuller documentation as we introduce more features

Lionel_Wolberger: what is the CR update: we want to focus on symbols only, will remove simplification, distraction, action, purpose, destination

Lionel_Wolberger: will end up with an updated FPWD with only symbols

janina: I'm not convinced the current organization of the draft is the appropriate

janina: where is the tag explainer, I can't find it in github

sharon: I believe tag explainer is in the wiki

Lionel_Wolberger: propose we focus on symbols and get the TAG explainer for that and move forward.

<Lionel_Wolberger> * Rewrite [1] WAI-Adapt Content Module, [2] Content Module Explainer, [3] TAG Explainer

janina: have to rewrite the TAG explainer and the general explainer to focus only on symbols; we will end up with multiple explainers, multiple modules. We need to take the parts in smaller digestible chunks. Will likely look more like CSS

janina: needs to be renamed (it isn't content) proposing WAI-Adapt Symbols module

Lionel_Wolberger: content module becomes archived; build symbols module; Is there an issues changing the name

MichaelC: we can change name of specs but if it becomes something entirely different it is better to change the name so the history is still valid

janina: we will mostly be removing content but we do need to archive that material since we will use it in the future

janina: we want the material archived to become the basis for future modules

matatk: if we rename to just symbols module, we can't really add additional modules into the same spec without changing the name again

matatk: thus, do we want to rename? We think we will have additional modules? We may need that to justify asking for a prefix

janina: I think we will have separate modules for simplification, destination, but I'm not sure we will have distraction

janina: isn't technical approach of distraction and simplification similar?

matatk: example I made is changing the content to be less distracting but not removing it

janina: I think stopping motion can fall under simplification

Lionel_Wolberger: we should focus on how to get a module for symbols and the necessary explainer

<Zakim> janina, you wanted to propose approach

CharlesL: if we aren't planning to combine symbols with other modules, we can clone the repository and have the history retained for the future

janina: concern is that current github has generic subdirectory names - content, comment, how do we distinguish what content, etc if we want to address additional modules

janina: was thinking of creating a branch of current explainer, FPWD and stripping out content that is not symbols

janina: then brining it for review

CharlesL: branching generally implies you are putting the changes back into the main tree;

CharlesL: cloning creates a new repository but may be easier to preserve the history

janina: does anyone understand the CSS structure? I haven't looked at github tree but CSS has been following this multi-module structure for some time

Lionel_Wolberger: the title of our spec is WAI-Adapt: Content Module, can we call it WAI-Adapt: Content, symbols module. Future can be Content, <other type> module

<Lionel_Wolberger> +1 to naming later, editing now

matatk: not sure we need to decide this right now, rather concentrate on stripping out everything that is not symbol; then hopefully we will understand what other modules we need; then concentrate on naming later on

Janina: we need some kind of name; we at least need something provisional

matatk: I'm proposing leaving it as content module; if once we get closer to CR we can consider the name; if there is only symbol we will rename but if decide we can other items, we can leave at content

Lionel_Wolberger: Is anyone uncomfortable keeping wai-adapt content module for now?

janina: yes, but I am willing to go along with the keeping the wai-adapt content module for now

Lionel_Wolberger: draft resolution: We will keep the current name while we do the first round of edits

RESOLUTION: We will keep the current name of WAI-ADAPT Content Module while we do the first round of edits

Lionel_Wolberger: we are rewriting explainer and tag explainer and trimming the current module

<Zakim> matatk, you wanted to suggest git approach

matatk: I don't think we need to clone, etc. but just edit in place and put a tag on the repository before we start the edits

<Lionel_Wolberger> +1 to putting a git tag

CharlesL: I like putting in a tag as a "snapshot"; but suggest Janina works in a branch so we can see and review the changes easier

<matatk> +1 to CharlesL

Lionel_Wolberger: Janina will put a tag on the current branch, and make edits in a branch

matatk: I can add a marker on the current branch; marker/tag will go onto the latest commit on main. Creating a branch won't affect it.

matatk: do we care what the name is?

<Lionel_Wolberger> * Rewrite [1] WAI-Adapt Content Module, [2] Content Module Explainer, [3] TAG Explainer

Lionel_Wolberger: tag name isn't important (group throws out a few names)

Lionel_Wolberger: see 3 rewrites above; let's start with TAG explainer

<matatk> The tagging is done: https://github.com/w3c/adapt/releases/tag/before-symbol-split

some confusion about TAG explainer vs general explainer - looking for links

<matatk> GitHub says the URL for the wiki's git repo is: https://github.com/w3c/adapt.wiki.git

<sharon> https://github.com/w3c/adapt/wiki/Explainer-for-Personalization-Semantics

<matatk> https://github.com/w3c/adapt/blob/main/explainer-tag/explainer.md

matatk: not sure if this is TAG or TR expainer; There is an explainer in the wiki that says TR explainer but also says it is for the TAG; but version in github also references both TAG and TR

matatk: need to find the versions and clarify

matatk: the one in the wiki says it was created for the TAG;

matatk: but there seems to also be a TAG explainer in the github repo

janina: believe the TR explainer is in our github repo but it has an odd name that doesn't make it clear

janina: index.html in the adapt repository is the TR/public explainer

matatk: and we have two tag explainers - one in repo and one in the wiki; believe the one in the repo is old (3 years); the one in the wiki is last modified in 2021 so seems the most recent

janina: the TAG one in the repository is only a template - I don't see any content

becky: don't we have to follow a specific format for the TAG explainer

<Lionel_Wolberger> * TAG requires a specific format in a wiki that is intended for TAG consumption

sharon: yes, looking at the TAG issue, one of the things they ask for is the correct TAG format

Lionel_Wolberger: can we start on TAG explainer changes this week?

matatk: the one in the wiki follows the correct format; suggest moving it into the repository if that is acceptable

matatk: not sure the one in the wiki follows the format but it has the content so should start with that

Lionel_Wolberger: can we start writing the tag explainer? Who will do that

janina: I volunteered for that but need to make sure I am working on the correct one. I will start on the public/TR explainer

sharon: I will sort out the status of the TAG explainer

matatk: I will cull the spec (Content module rewrite)

janina: will work on the TR/public explainer

sharon: will sort out the TAG explainer history