Meeting minutes
<gb> /issues/78 -> #78
<gb> /issues/104 -> #104
<gb> /issues/103 -> #103
New Business
Dr_Keith: New accessibility tool, I am working on, could use feedback join potentially in a zoom call if anyone is interested.
… a11y roadmap planner, based on the maturity evaluation.
… I do want to bring it here but its not right ready.
Mark: I would love to be a part of that.
Jeff: I am interested as well.
Janina: could use the Public mailing list as well.
David: sounds like a great use case.
Mark: I could bring another person who does road mapping.
Dr_Keith: Sure, include them as well.
Github Issues 43 and 85 (Usability doc feedback) https://docs.google.com/document/d/1Wrhomdc2gJWIkDPOveiH3_ig1bddTMonEhIDZIzohrc/edit#heading=h.93exgeg396jg
Stacey: Not too many new items from last time. Chatted with Charles with regards to issue 78, would be resolved with these changes.
… I will be expanding for all dimensions. may be needed a proof point around K&S
… in Launch plans on training around K&S, then move through optimized.
… we could take some time to work on this as a working session.
David: Yes we can do that. once we have some more edits.
Charles: in future, can we try and add some extra notes/comments on suggested content edits, thought process, etc. so we have it documented in the minutes for reference (to help the people working on it move forward)
Janina: this happens all the time, we all need to be looking at the minutes especially when folks say they will do something is documented in the minutes.
Janina: it's up to all of us to comment/raise hands that enough has been captured in the minutes. Especially if someone is assigned to something, or if there are comments on something and the person working on it isn't there. They might need a little extra context.
… to take an extra minute. to make sure it is in the minutes.
David: once we get this edits in the editors draft we can close a number of issues.
… 104 is an editorial about language I believe.
Maturity Model Scoring Subgroup Update
jeff: we have a meeting schedule for next Wednesday. worked on a straw man and sent it to Mark and Charles so we can talk about it a
… its a work in progress, I will forward it on. I just didn't want to get too far ahead of Charles & Mark's involvement.
David: I hear that, just think the whole group should be given just a heads up.
Jeff: we can give an update on this at our next meeting.
Github Issue #78 3.3.2 Ratings for Evaluation - Support section: why is knowledge and skills mentioned (Update from Charles, stacey)
<gb> /issues/78 -> #78
Stacey: I made a comment in Github to Mary Jo. will be addressed in the next editors draft update.
Github Issue #104 Proof points = Written or tangible evidence, according to definition, not an 'or' / 'other' part / sub-section (will usability do address?)
<gb> /issues/104 -> #104
<Fazio> w3c/
<gb> Issue 104 Proof points = Written or tangible evidence, according to definition, not an 'or' / 'other' part / sub-section (by jake-abma)
Stacey: in 1.4 key terms the definition of proof point (this is something different)
Stacey: Tangible vs written evidence
David: if we can't figure it out, we need to clear this up to make it easier to understand.
… clear language would be great.
Mark: I would take out written.
Jeff: term I use is "credible evidence"
David: a form of evidence vs quality.
Stacey: maybe just go "evidence" instead make it even more general.
… specific to each dimension twice here.
Mark: the "OR" make it different than the proof point. what does that mean?
… written or tangible sounds like the issue.
Stacey: these proof points may not exist in your company. examples of evidence within your company.
Jeff: a proof point is a deliverable within a company perhaps.
Mark: written or tangible some qualifier.
Dr_Keith: To simplify this just say "tangible evidence" the "written" part isn't really needed.
Jeff: less looks like a definition, is proof point is the criteria that is supported by some kind of evidence.
Mark: whats written here is what would satisfy a proof point not the definition of a proof point.
Proof points are criteria on accessibility maturity that are supported by some kind of evidence.
Mark: take out "some kind of"
Jeff: supported by evidence.
Proof points are criteria on accessibility maturity supported by evidence.
David: section 2 of the document.
In key terms: Proof points are criteria for accessibility maturity supported by evidence.
David: 2. Maturity Model Structure
… Proof points, or tangible evidence, that can be used to demonstrate progress. Each proof point includes a high-level description. Deliverables are mostly self-explanatory, but in some cases, additional information is provided.
… 1.4 Key terms
… proof pointWritten or tangible evidence specific to each dimension that can be used to measure the maturity for that specific dimension.
The update in 2 Maturity Model Structure, first bullet would be: Proof points are criteria for accessibility maturity supported by evidence. Each proof point includes a high-level description. Deliverables are mostly self-explanatory, but in some cases, additional information is provided.
<Fazio> Written or tangible evidence specific to each dimension that can be used to measure the maturity for that specific dimension.
Charles: will make these two edits. as defined above.
Github Issue #103 Where are the "Outcomes" in the Maturity Model Structure?
<gb> /issues/103 -> #103
<gb> Issue 103 Where are the "Outcomes" in the Maturity Model Structure? (by jake-abma)
Jeff: proof points are very specific, the maturity stages are more generic.
… I don't think this is a real concern.
David: proof points are listed are optional as you may have other proof points.
Mark: were we wrote it should be outcomes and stages not proof points and stages.
… Outcomes (with possible related proof points...) Maturity stages (with specific Outcomes)
Mark: I get what he wants but not sure about the why here.
Jeff: there is flexibility with Proofpoints but Proof Points are required.
… you need to get to the final stage.
Stacey: outcomes is the end state.
David: is the Maturity model structure, Outcomes and Stages, Proof Points / stages, or other combinations.
… what is the structure of the model? does each dimension have 2 or 3 items (proof points / stages / outcomes)?
janina: Proof points are the specific evidence to figure out the current outcomes, and when you know your outcomes you can evaluate what stage of maturity you are at.
… issue is these two sub section (proof points / stages) maybe outcomes instead of proof points.
David: should we have 2 or 3 sub sections?
janina: proof points build up to outcomes.
… what stage are you at is what we are trying to find.
Jeff: we talk about outcomes / results but not part of the structure of the model.
David: what is each dimensions structure.
… what are the subsections for each dimension.
janina: 3 subsections.
David: I am ok with adding outcomes.
Stacey: I can see how this wraps into the rating section, it may or may not. outcomes.
David: please add #103 to your list Stacey.
<gb> /issues/103 -> #103
David: it will be informed by the usability document that Stacey is working on.