Education and Outreach Working Group Teleconference -- 28 Feb 2017

<Sharron> James: Next steps: Top tasks, content mapping

<Sharron> ...Draft final IA

<Sharron> ...Naming strategy

<Sharron> ...Fit/Rename Existing

<Sharron> ...Edit/Create Content from gaps

<Sharron> ...Roadmap - MVP ->V2 -> V3

<Sharron> ...Recruiting Plan

<Sharron> James: Immediate tasks. HTML mocks, Font Issue resolutions, Finalize design

<Sharron> James: MVP amy be only 60 of the 100 pounds. No links to old stuff from new site. Incentive to get additional 40# into shape.

<Sharron> Eric: Objects to no links to old stuff from new site

<Sharron> Sharron: resource management has not succeeeded in getting things inshape

<Sharron> James: Because of groups crushing your incentive

<Sharron> Denis: +1

<Sharron> Robert: Why so much process?

<Sharron> Shawn: to quote Caleb: if on WAI site must be right

<Sharron> Sharron: But difference between incorrect information and wordsmithing.

<Sharron> Andrew: Yes could say "technically correct AND would like to see this and such down the road."

<Sharron> James: example of Perspective videos

<Sharron> Shadi: lots of support, engagement from the group.

<Sharron> Denis: if we could have made more changes, we would have discussed for months.

<Sharron> Shawn: Part of it, is when ready for thorough review and it does not happen.

<Sharron> James: Caleb's comment is about code snippets, not wordy documents.

<Sharron> Laura: we have the same risk at the library that someone did not wiegh in who should have. We still publish and if it needs to be fixed, we fix it.

<Sharron> Sarah: Clear content publishing process, with smaller groups and larger group review. Framework around feedback, our reputation vs the editorial efficienty. Need guidelimes to have a consistent voice.

<Sharron> ...if the videos can be made equivalent to the content in the MVP may need to be realistic about the goal. Need to find the point and do we have analytics?

<Sharron> Adina: Process using two week sprints. At the deadline and you ahve go/no time which creates buy-in.

<Zakim> shawn, you wanted to ask scope and to note single RMs vs. small groups

<Sharron> James: Could take long time to get to the MVP will not solve that now but should do it while we wrap up visual redesign and IA.

<Sharron> Shawn: Individual RM did not work, small groups work better.

<Sharron> ...still don't have a shared understanding of the ideal so we can figure out what is MVP. Could be solving these problems at the next f2f

<Sharron> Shadi: I agree that we don't want to put old pages in the new IA. Would hurt our reputation. Don't understand the reason why.

<Sharron> ...what would we drop?

<Sharron> Sharron: We don't know yet.

<Sharron> Shadi: Here is a frsh look, these are the pages we have rewritten and here are the older resources that we are still working on.

<Sharron> James: From a users perspective. If we are going through this effort, we don't know yet what the result will be.

<Sharron> ...most important goal is to change the way we perceived and affect accessibility across the world more effectively.

<Sharron> ...we would be encouraged to work more efficiently if we left the older stuff behind

<Sharron> Adina: What if we did a user journey map. Once we make top 10 user journeys, put the other into staging, build in sprints.

<Sharron> ...after these 5 are solved for, we take that live, switch the live lever, leave some things behind?

<Zakim> shawn, you wanted to say 2 of 3

<Sharron> Shawn: Thread last tweek on WCAGs decsion to publish - we have 3 things we want to accomplish, we can only do two of them.

<Sharron> Denis: The 40# we will not address at first, we will be prioritizing. It will be the less visted ones that would get left behind, correct?

<Sharron> Eric: What do we do with links in the content, what do we do with the inter-related content?

<Sharron> James: Existing content does not fit into the IA

<Sharron> Shawn: I do there is an interim approach. First page is good, next page is good, third page has the wordyness but new design.

<Sharron> Laura: How do you incorporate new IA into olf content? Doesn't really work.

<Sharron> James: Some will fit one to one, not just to clean it up and make less wordy, but to make it fit into the IA.

<Sharron> Shawn: Can we get out of the theoretical and into the proactical?

<Sharron> Robert: We are having a crisis of confidence about what the redesign will leave us with, need a content audit

<Sharron> Charlotte: I did that and will rethink based on the work we did today.

<Sharron> Howard: Can we get as much done as we can and make that decision later. I don't feel like we are moving toward agreement.

<Sharron> James: If we move toward creating an ideal IA and naming strategy to fit within it that is alot of work. But if we cannot agree on the project plan.

<Sharron> Sahwn: Putting the existing content into new IA and visual design. Other is to wait until everything is done before we launch a new site.

<Sharron> ...no one is suggesting either of those extemes.

<Sharron> Shadi: It sounds to me as thought the ideal IA is beyond our reach, if there are too many resources that need to be redone, we may need to to use that.

<Sharron> Howard: what about the idea of using the optimal IA and then a tab or something to the archive?

<Sharron> Charlotte: Yes I thought of somehthing like that from the footer

<Sharron> KrisAnne: and we can see how many people actually use it.

<Zakim> shawn, you wanted to say those top tasks not necessarily

<Sharron> Eric: Define ideal IA, define sprints to get there step by step, publishing iteratively.

<Zakim> Andrew, you wanted to mention alphe/beta/live

<Sharron> Andrew: What about the idea as an alpha or beta, we are still building it, and running in parallel under wre happy enough to fully switch?

<Sharron> Sharron: Next steps should be to move toward the ideal and do this practically

<Sharron> Charlotte: Can we see the real, multi-month numbers?

<Sharron> Eric: Take off line

<Sharron> Shadi: We are not dicussiong the ideal IA but the ideal web site?

<Sharron> Shawn: To meet these tasks vs the organization of the existing content

<Sharron> Shadi: Could wither start with exisiting content or based on the tasks that people defined.

<Sharron> Sarah: My understanding is mapping is to the IA?

<Sharron> Charlotte: No it is to map the top tasks to the existing content and identify gaps.

<Sharron> Shawn: If we do the work, we may find we are not so far apart

<Sharron> Howard:

<Sharron> Howard: If close enough to a resolution, I would like to make these guys happy. Suggest that we do that

<Sharron> Eric: Propose a resolution to do the mapping for existing content to identified tasks, agree on deprecated content, gaps, and re-titling.

<Sharron> Adina: Did I hear one idea to not do anything until it is all perfect, second launch in user journey sprints, finally the idea to provide links to the old site compromising look and feel.

<Sharron> ...what about the possibility to search the archive

<Sharron> Howard: Similar to the footer idea and may be good to do both.

RESOLUTION: To do the mapping for existing content to identified tasks, agree on deprecated content, gaps, and re-titling.

<Sharron> trackbot, end meeting

<Sharron> chair Brent

<Sharron> Scribe: Sharron

Brent: Thanks for good participation yesterday, let's continue to express your persepctives. Hoping to get through these initial agenda items quickly,
... ground rules for conversation, try to use IRC for the cue
... direct response to comments OK as long as we stay on topic.
... to the agenda. In trying to get participants more involved in the group and given the fact that we lost significant commitment from editors, tried to move the resources into the oversight of EO participants as Resource managers (RMs) and struggled with trying to make that work through out the year.
... heard from Shadi the staff perspective, heard from Denis about being discouraged by lack of true owenrship of the Resoeuces, and from myself about the improtance of working with a partner.
... many think the RM process is valuable but needs work, and how to balance the meetings with time spent on RM.

<shawn> Sharron: When have a survey and and few people answer it, that's also discouraging to the editors and all. Also think about our responsibility as an EOWG participant. (There is a pllace in the survey to mark that you didn't ahve time.)

<shawn> James; you don't HAVE to comment (can check OK)

<shawn> Sharron: But when you get survey and people OKed it -- but then you find there are errors. :(

<shawn> Sharron: ... hard when don't get feedback

Laura: Sometimes it feels like it is just not open long enough, Fri to Tue not long enough

Andrew: And some have so much content, it is difficult to comment in a meaningful way.

Shawn: One of the issues, and I am one who push for longer time, chairs feel like everyone waits to the last minute.

Eric: Probably we could have the way to say if you feel strongly about it please comment early but leave it open for two weeks. Not sure.

James: part of the issue may be that we are working on more resurces. Maybe working on a resource in small groups. Instead of everyone being responsible for everything, have assignments of small groups working on a resource together.

Shadi: What is the approval process? I like working in small groups alot, what is the final approaval process?

<Zakim> shawn, you wanted to say ask for moree time and to

James: Sending something out for the whole group for the early review it makes much more work for the RM.
... final review from the full group.

Shawn: Maybe something in between that, similar to the Perspectives video. One early review, comment on a robust review, and a final review

<shawn> Sharron: RMs, we've made very little progress so far. heard Denis perspective

<shawn> Andrew: some things maybe do. but even things like policy, we do need to bring to the group early.

Shadi: Used the same approach for the WCAG report tool, the before and after demo, and the etc

Eric: In some cases, RMs bring to t he planning group and they are not ready for the full group. And recall that I tried to have a small group for the Tutorials and got little traction, so it was disappointing.

<Zakim> shawn, you wanted to say ask for moree time and to

Shawn: As we're looking at how things are working. I think ideally a little more od the Policies work would have gone on in smallgroup&chairs& staff before it came to all EOWG. (We just had time on Friday and hadn't gotten feedback on GitHub, so

Shadi: Sarah suggested yesterday that we may need Editorial guidelines. There is a lot of work involved and you must be prepared for your work to be torn apart and often the evolution of the docmuent may be different from any one perspective. RM is key in moving it forward

<Zakim> yatil, you wanted to react to shadi

<shawn> brought things to all on teleco.)

Eric: The RMs have opportunities and ricks and need to find how to make it work.

James: I am not sure if I heard a lot of resistance to my suggestion and wonder then where are we?

Shawn: We may need to do it more often.

Brent: How many think the RM would benefit from having more than one?
... everyone. OK, if it was a group of two or more and we allow that small group more autonomy, they work until it they are content with it and then brng to full group.

Andrew: Group should approve the concept of what will be changed before the work of rewrign and resturcuting begins. Direction must be approaved at the goup level.

<shawn> +1 to andrew that need earlier input from EOWG

Brent: Are you referring to an exisitng resource

Andrew: Yes

Brent: What if the direction is set before the group has formed?

<shawn> Andrew: too much work for plannning team without others contributing

Brent: between planning team and RM

Sharron: Why pretend that the full reviews are really full reviews when most of the group does not respond.

Brent: 4:30 on Wednesday, found 11 issues no one else had mentioned, grammar, basic things.

<shawn> [ interesting way to think of it - EOWG is the owner or resource and client of the small group. think about how you would handle updatess, reviews, etc. ]

Shadi: Yes, the Tutorials review was unfortunate, does the small group do all the work and what if it is not acceptable.

Keving: seems like a need to work smarter not harder. some things can be automated.

<Zakim> yatil, you wanted to say resource development life cycle

Brent: In this case it is not caught by automation. For example 8 of the 11 would not have been caught, but appreciate the idea.

Eric: More often that not, grouop feedback is really good, especially when we get many voices in the survey. If there is no small group to depend on, you muat bring to the larger group.

<Andrew> something like http://www.hemingwayapp.com/ could be used to check our writing

<shawn> [ https://www.w3.org/WAI/EO/wiki/Resource_Development_Life_Cycle]

Eric: Maybe the approval process should be split so that the subgroup dedicated to it does that level of approval and allow others only show stopper status.

Denis: It would show some level of ownership and level of control as well. I get the consensus process at the end, but if everything must go through this bottleneck I will not do it. What Eric suggests has value. if the work is done the small group should be able to develop it to the point where it is ggod enough, we expect to iterate in any case.

Shawn: have we have gotten to the point where we agree to have more work done in small groups.

SHarron: Because we are about to do wholesale content revision in preparation for the new website, we must be more efficient.

<rjolly> Eric: We have a good mechanism for asking for and getting/traiging feedback using GitHub.

<Laura> Scribe: R Jolly

<Laura> Scribe: rjolly

Denis: Worried about how much the open feedback aproach might hinder progress on work that’s happening if the discussion bogs down.

James: Perhaps we need to simplify the categories of feedback (e.g. editor’s discretion, high, med, low, etc.)

Andrew: Should we have a standard set of tags/labels in GitHub?

Robert: I think we should have a standard set of feedback labels as well as actions/responses like “bug” “feature request” fix, won’t fix, etc.

James: In effort to keep discussion efficient and most needed, let’s ensure we are clear on marking the feedback appropriately.

<shawn> +1 that we need clearer distintionns / levels for type of comment

James: We need to create a culture of self-censorship/discretion and raise issues that are really important and not bog down editors with discussions that aren’t important.

Shadi: Group discussions are only for when we have differences of opinion that can’t be resolved easily with decisions/updates in the small group

Shawn: Small groups working like this will help make the work more efficient for everyone.

James: The problem we need to address is the culture of allowing anyone with an objection to hold up publishing/shipping work

<Zakim> wseltzer, you wanted to discuss consensus

<wseltzer> https://www.w3.org/2015/Process-20150901/#Consensus

Wendy: The questions of how we get and interperet consensus is important. Want to point back to the W3C Process Document and the goal of consensus. Reminds people that consensus isn’t unanimity.
... Sometimes chairs in groups will help lead the group to consensus where there is some disagreement in the group.

James: I’m asking us to come up with some ground rules to help us come to consensus faster than we currently are.

<dboudreau> I respect the core value that is consensus, but I don’t see how it would conflict with the idea of being way faster and more iterative. We can also reach consensus over time - not everything needs to be perfect on the first try, every single time.

Sharron: We have not been able to iterate because we are so process heavy.
... We’re not writing specifications.
... When something hangs out there with “Draft” on it for three years, we have a problem with process
... As Andrew said, if it’s “good enough” we can publish it and then revisit it in iterations to continue improving our work

<Zakim> yatil, you wanted to say only unresolved objections need to the group and to say expectation of update and to say draft status and to say comment on process-heavyness and to say

Eric: At the moment, we don’t publish rapidly due to the extensiveness of the reviews.

<shawn> [ Shawn notes the issue in the past has been that we just haven't had editor time to continue to refine resources after they are published. ]

<Sharron> Scribe: Sharron

Denis: Why not, that indicates broken process

Eric: Yes, we want to change it.
... the RM process should help.

Shawn: The reason we do not revise things more often is that we have not had enough editor time. With this new process of having small groups fulfill the editor role, this is a thrilling prospect.

<Andrew> https://www.w3.org/WAI/intro/w3c-process.php

Denis: So can we acknowledge a certain level of ownership. Editorial chiefs for each document, working on them in small groups. Small groups -> editorial board -> full group has final approval.
... people who are interested, make sure we have a single voice for everything, final check before publication.

<Zakim> yatil, you wanted to say final approval only for objections? and to comment on editorial review

Eric: The process where KrisAnne did editorial review of the tutorials was very helpful. I learned from it and used in other resources. Second thing where the final review by the full group is only for objections.
... gatekeeper role and go back and forth to see if really works.

Brent: What would you like to change about the meetings?

Robert: If we see we are going down the rabbit hole, take it off line to the small group and come back.

<James> +1

Denis: more focus and shapards of that from the chairs.

shadi: not sure every other week is good, but given the amount of work we have maybe phase it o surveys run for two weeks and planning is more ahead. To keep momentum going.

Howard: Maybe shorter meetings, every week.
... maybe send out repeated reminders, because cannot always respond.

Andrew: Request that surveys have only one subject.

Policies List

<Andrew> https://w3c.github.io/wai-policies-prototype/

<Andrew> Policies issues page - https://github.com/w3c/wai-policies-prototype/issues

,,,with Silver we want to come up with processes that include marginilzed groups and maintain measurable, clear standards.

Would like to hear what is working well in current processes, what needs improvement, how we can work togther.

Shadi: Chairs are to be commended for getting 2.1 out on schedule despite charter delays. Moving toward greater transparency

Andrew: Good progress on timelines and laying it out proposed time frames, etc defintely a plus
... more open to get people involved

Shadi: and clear about what to expect

Jan: anything more on what is going well?
... how about what is not going so well?

Eric: with 2.0 Techniaues lacked the group resources to stay up to date.
... abit of disconnect between what techniaue provide and what people really need.

Jan: could EO help?

Eric: defintely

Andrew: will the Techniques for 2.0 be separate from those for 2.1

all: discusion....maybe not sure

Shadi: Turotials and Quick Ref good examples of how EO can support
... previously WCAG closely focused on guidelines and not so about supporting docs.

Jan: So more clearly planned coordination between eo/agwg?
... and waht about disenfranchised groups?

Andrew: We may need to do better messaging about how very specific needs may be detrimenatal to others.

Shawn: Very hard, as Gregg Van Derheinden says, we need to have best practices but some of thise things just do not fit into standards.

MaryJo: But from industry perspective, we look for MVP, testability, etc

Eric: When easy to do, people will do it.

MaryJo: unless it is folded into how they are trained as baby programmers, they will not.

Eric: But most will not learn programming (such as HTML) will learn frameworks and the point is to make the frameworks support accessibility.

Shadi: Standardization is hard. Regardless of different disability groups, there are more than 400 member organizations in W3C and coming to accessibility very few with skills and ability to contribute. No matter how good is the process unless you do significant outreach, you will not be meeting all needs.
... some grooups won't even know to follow the AGWG and comment

Shawn: Some people wven now involved cannot use the tools even though they are fairly technically literate.

Jan: In terms of research, Silver TF i trying to identify research interest areas and topics for research. Things lik usability fo the standards themselves, the supporting docs, etc.
... what kinds of research do you all think is necessary?

James: WCAG was written with people with disabilities in mind. But the real users were developers and designers who implement them. The biggest barrier is the way the information is presented to the technical staff can't read and understand them.
... we are a not really very diverse group. Seems to lean more toward advocacy and academia rather than the industry that has to use it.

Shawn: The real issue is that the Guidelines are not written for developers but for policy makers, for legal reasons of measurability and validation.
... has been on EO's wish list for years. We need document to meet the needs of developers, designers, evaluators.

Denis: Not how those documents are writtne then but how a group like us can translate these policy documents into a guideline and test manual for technologists.

James: We have done that at VISA where we translate WCAG into an implementers set of steps.

Shadi: Two levels of translation - how can I understand it, second way is to know how to do a spacifc task in an accessible way.

Jan: So I am fascinated by the idea of this other document, how do we get it done?

Shawn: We have been brainstorming about this for years.
... currently many compnaies working on this internally

Jan: If we can organize within WAI to standardize this, that could be tremendously valuable in advancing accessibility. Because it always comes back to WCAG and it may be useful to help people do this.

James: Yes, it will be useful to show how to take WCAG 2 and create an internal set of standards that will meet and ditill the WCAG requirements in a way they can use.
... I seem we have ignored all the developers who already have too much on thehir plate and don't want to think about this. if we help them, we advance the cause.

Shadi: What if the Techniques were written differently with a different approach that really speaks to the developers?

James: Yes, could be great. Going back to developers, do some research about that group what they need, how they consume materials.

Denis: To that point in training for instance, we did training by the guideline which bored everyone, now do it more interpretively and by actual examples, helping designers understand what to do.

<Zakim> shawn, you wanted to comment on what Jan asid as member value for this (for rechartering!)

Denis: using more visual aspects that meet them where they are.

Shawn: Developer have not been the primary audience of EO up until a few years agao.
... we should figure out as W3C members, AGWG, and EOWG want to make that a change in focus.
... if we can IBM, Pearson, and VISA's perspectives on why this matters

James: If our goal is an accessible web, it is key to get developers on board.

Eric: Good discussion, like that and can make a simple change with Silver is going back from minimal and advisory techniques and promote them to developers.

Shadi: Back to the topic of the pendulum swong from a developer document wcag1 to a policy document wcag2 and now must find the ballance that meets more stakeholder needs.

Brent: I like the developer approach that James is talking about but let's not forget that Accessibility Specialist, that person also needs to understand it.
... need a conduit to get it to them and the justifucation.

Denis: Mentioned ealry the sufficient techniques and how most developers want to do the minimum but should make them understand they will fail to meet user needs.

<Zakim> dboudreau, you wanted to highlight explaining what bare compliance means

Denis: the conduit is the idea I had for quick tips

<Andrew> Sharron: need todemonstratehow the techniques help meet user needs - most devs are proud of their work and don't want to prevrentpeople from user their product

<shawn> ... that's something EOWG can help with

KrisAnne: I am of the opinion that asking people what was their experience and listening to that.

<Andrew> s/need t /need to

<inserted> scribe: Sharron

<yatil> i/James: Next steps: Top tasks, content mapping/scribe: Sharron

- DRAFT -

Education and Outreach Working Group Teleconference

28 Feb 2017

Attendees

Contents

Policies List

Next EOWG Charter

Summary of Action Items

Summary of Resolutions

Scribe.perl diagnostic output