Meeting minutes
<gb> /issues/228 -> #228
<gb> /issues/193 -> #193
<gb> /issues/228 -> #228
<gb> /issues/193 -> #193
New Business
janina: IRC problems will hopefully be fixed tomorrow. Report disconnects after tomorrow to Janina and Mathew
Publication Strategy
janina: made a few changes to the messaging
Fazio: also made some changes and sent PR to janina
janina: to proceed to management, we need a date that we anticipate being ready
Fazio: that largely depends on the spreadsheet.
janina: for 1.0 they have to be in sync (the spreadsheet and the narrative)
jkline: we should be able to do it in the next couple of sessions
janina: that sounds like mid-Feb
jkline: added a new issue about financial planning and budgeting
Fazio: Stacey and Jason had previously mentioned that also.
jkline and Fazio: we can review as new business at the next meeting
Github Issue ##226 Add an explanatory section on dimension goals and metrics
<Fazio> w3c/
<gb> Issue 226 Add an explanatory section on dimension goals and metrics (by jasonjgw)
Fazio: came from Jason, we have previously discussed it. Stacey has a proposed result
response*
Fazio: read the issue out loud
<Fazio> We're talking about adding a short message about the subjectivity of setting goals and metrics.
<Fazio> Here's a starting place. Wondering if this is on the right track to address the concern? Would love feedback and more insights to what you'd want to have added for clarity (especially for those who wouldn't be accessibility experts):
<Fazio> Creating accessibility metrics and goals is subjective. Similar to creating goals and metrics for products and features, you must consider the organization type, needs, maturity, staffing, funding, and yearly objectives.
Sheri_B-H: Notes Jason was asking for dimension specific definitions
Sheri_B-H: Might we want to abstract this up earlier in the doc? So it shows up once and not multiple times in each dimension?
Sheri_B-H: Original goal was that this model would work from a single person shop to a multinational
Sheri_B-H:
We need to stay vague for that reason
Mark_Miller:
Agree
Sheri_B-H: Looking to make a proposal ...
Section 1.1 About
jefMuch in the About that won't be familiar -- perhaps a one line
Sheri_B-H: keep it vague, don't make it dimension specific
Jeff: Agree we don't want to be dimension specific
jkline: has some language in his book he can donate
Sheri_B-H: Also comes down to org type: corporation departments also will have differences
Fazio: goal definition best left to the people doing the assessment
Sheri_B-H: Ex: Someone could use our model and create say "Health" maturity model--but that's not us
<Fazio> Sheri and Jeff will write up an explanation
Github Issue #228 Determine if the proof points in the MM document and the assessment tool should be synced
<gb> /issues/228 -> #228
<gb> Issue 228 Determine if the proof points in the MM document and the assessment tool should be synced (by jeffkline)