EOWG Participation Info

From Education & Outreach

Welcome to the W3C Web Accessibility Initiative (WAI) Education and Outreach Working Group (EOWG)!

W3C Working Group information: Accessibility Education and Outreach Working Group (EOWG)

The Basics

Most EOWG information is linked from the main wiki page: https://www.w3.org/WAI/EO/wiki/Main_Page

The EOWG home page has some high-level information: http://www.w3.org/WAI/EO/

Work and agendas

E-mail Lists

The following e-mails lists are currently used by EOWG. All are publicly archived, unless indicate otherwise.

  • w3c-wai-eo@w3.org (public archive)
    — main EOWG list. Goes to all participants (and about 100 lurkers, mostly past participants).
  • public-eo-plan@w3.org (public archive)
    — for planning EOWG work, including meetings. Goes to Chairs, W3C Team Contact, and sometimes others). EOWG participants use this list when you want to bring work to the planning team and are OK with it archived.
  • public-eo-archive@w3.org (public archive)
    — place to archive stuff without cluttering other lists and mailboxes. Editorial Teams folks should CC this list when they are communicating with their teams directly. (If you use a Project-specific list below, then just send to that list; don't need to also send to this list :-).
  • wai-eo-editors@w3.org (public archive)
    — purpose: for public and others to get messages to the WG on things that need edits -- for those who don't want to do it through GitHub. Goes to Chairs, W3C Team Contact, and active editors.
  • group-eo-chairs@w3.org (not publicly archived)
    — purpose: to reach Chair(s) and W3C Team Contact(s).

Active Project Lists

  • public-wai-wcag-videos@w3.org (video archive) — for work on the videos (was videos on WCAG SCs, now How People with Disabilities Use the Web)
  • public-eowg-roles@w3.org (roles archive) — for work on Roles and Responsibilities Mapping (ARRM)

Note: You can choose to have a separate list for a project — just ask Shawn.

Telecons

The main meetings page has Teleconference logistics with Zoom info and IRC info, list of upcoming EOWG meetings, and more.

Availability for telecons

Please indicate your Availability for Upcoming EOWG Teleconferences in the form at:
http://www.w3.org/2002/09/wbs/35532/availability/
You can change your answers at any time. The link to this form is on the EOWG Meetings wiki page under "Work for this week", Availability Surveys and Missed Meetings.

IRC

We use IRC during the teleconference to take minutes, share links, indicate support or not for proposals, etc. You can join IRC through a web browser or IRC client:

  • Information on using W3C IRC from a browser is here: IRC
  • Most people download an IRC client
    To join the EOWG IRC:
    • Server Address: irc.w3.org
    • Port: 6667, 6665, 21 (choose one)
    • Channel: #eo

IRC non-minute comments:

  • By default, what you type in IRC shows up in the minutes.
  • To type something that you do not want recorded in the minutes, preface it with:
    /me
    For example:
    /me apologizes for the construction noise in the background
    It will show up in IRC with an asterisk and will not be in the minutes:
    * shawn apologizes for the construction noise in the background

Lots more info: Zakim IRC Bot

Code of Conduct

All participants are required to follow the W3C Code of Ethics and Professional Conduc.

Tips

  • Surveys — You can edit surveys the whole time they are open. So you can complete some questions now and others later, change your answers later, etc.
  • GitHub - GitHub training, GitHub W3C info
  • Minute Taking Tips
  • To create a new wiki page:
    • Start from the Main Page
    • Login if you're not (you'll get "[edit]" next to headings if your're logged in)
    • Figure out which heading you want your new page to be under, and click "[edit]" after it
    • Type the new page title in double brackets, e.g.: 
      [[XYZ Resource Revision 2020]]
    • Save page.
    • Your new page link will appear with (create new page), e.g.:

      XYZ Resource Revision 2020

    • Click it, edit it, save it, done!

screen readers

Comments

Here are some tips to provide comments and input in a way that supports the editor.

Understand the background and context

  • Know the background, such as in the Requirements Analysis (that has goals, audience, etc.), before commenting.
  • If you have not been involved in the discussions on the resource, please read relevant meeting minutes before commenting. You can find where the topic is covered from past agendas and links to minutes. Before posting comments publicly, consider checking them with the editor &/or chairs to make sure the comments take into account past EOWG input.

Use GitHub, Pretty Please

Even when we have a survey, it's much easier for the editor if you put comments in GitHub.

Open a new issue for each point, instead of putting multiple points in a single GitHub issue.

(optional) If you have specific suggestions, you can make it even easier on the Editor by creating a pull request:

  • GitHub fork, edit, pull request's:
    Video on how to suggest edits with GitHub (~4 minutes): on YouTube, on Zoom (sign-in required)(unedited captions)
    1. Fork and make the suggested change
    2. In the comment area,
      • Put a short description of the change (e.g., "introduction copyedits") in the box replacing "Update index.html.erb.md". Preface it with the comment level (below)
      • Put the rationale in the box replacing "Add an optional extended description..."
    3. Submit pull request
  • Usually do separate Pull Requests for each comment or suggestion. (Typos and other corrections can go in a single pull request.)

Provide specific, clear, succinct comments

Provide specific, clear, succinct comments that are:

  • easily action-able by the editors
  • quickly understandable to other EOWG participants

Usually include proposed re-wording and rationale for it. Rationale can be longer as needed.

Template for comments

Include the location of text you're commenting on, ideally with a link to it.

  • level: (low, med, high for draft reviews)
  • page: [page title](URL)
  • location: (such as: "under Introduction heading, third paragraph")
  • current wording:
  • suggested revision:
  • rationale:

Include level

Help the editor know if you think this is super important, or just an idea for them to consider.

For draft reviews:

  • (low)
  • (med)
  • (high)

For butterfly approval to publish reviews:

  • [ED-low] = Editors' Discretion, low importance for this publication or later version
  • [ED-med] = Editors' Discretion, medium importance for this publication or later version
  • [HIGH] = High importance - must address before publication (not necessarily must make the change, but must work it out to the commenter's satisfaction, which sometimes means additional EOWG meeting discussion)

(In Progress) EOWG GitHub Contribution Guide

Review Stages and Levels

"animal handles" for EOWG reviews:

Squirrel Review — Gathering requirements

squirrel with collection of nuts   

What you're reviewing is a Requirements Analysis.

  • This is an internal document (that is publicly visible), thus it does not need to have polished wording. Avoid un-important word-smithing.

Eagle Review — Bird's-eye view / 30,000-feet

eagle soaring high in sky   

What you're reviewing might be an early, incomplete concept draft or wireframe.

  • High-level review for overall content and general design.
  • Comment on organization, structure, flow, tone, approach, meeting audience needs, overall content, etc.
  • Do not bother with word-smithing or copy-editing or design nit-picks.

Dragonfly Review — Specific sections or questions

dragonfly on tip of flower buds
(focusing on just one little flower bud)

What you're reviewing is an in-progress draft.

  • Review the specific section(s) &/or
    answer specific question(s).
  • Usually we want to focus only on these specifics, and not review the rest of the draft.

Often we will have several of these reviews where EOWG focuses on different sections or issues.

Starfish Review — What's missing? What doesn't fit?

starfish missing an arm
(Most starfish can re-grow missing arms.)

What you're reviewing is a complete draft. It might not be fully polished.

  • Are all points covered - is anything missing?
  • Is there anything in there that should not be in there?
  • Try to catch all significant issues in this review. (if you bring up big issues later, they could be disruptive)
  • Sometimes it's ready for word-smithing and sometimes not. We'll let you know with the review notice.


Monkey Review — Thorough Review

monkey picking at another   
(Fine-toothed comb grooming)

What you're reviewing is everything in the final draft.

  • This is EOWG's pre-publication review, our internal "last call".
  • Review and comment on anything and everything, including copy-editing as needed.
  • Speak now or forever hold your peace.
    We hope there will not be any more new comments after this review.

(Any changes after this review will be documented so participants can review just those changes and don't have to re-review the whole resource.)

Butterfly Approval — Approval to publish

butterfly on window pane looking outside   

Fly, fly, fly out into the world, you lovely resource!
What you're doing is approving the few changes implemented from the previous review.

  • Usually there shouldn't be any more comments at this stage, it's just the formal sign-off.
  • We are usually eager to publish and announce it. Sometimes we are trying to meet a specific publication date.
  • Only very important issues should be raised as show-stoppers ("HIGH"). Optional comments ("editors' discretion") are OK.
  • All comments must be indicated as either:
    • [ED-low] for editors' discretion, or
    • [ED-med] for editors' discretion, or
    • [HIGH] important to be addressed before publication

action: get permission for starfish image http://www.messersmith.name/wordpress/wp-content/uploads/2010/04/starfish_IMG_2311.jpg

Process for Minor Changes

For any significant changes, we use a survey for EOWG to approve changes. They are usually open at least 12 days.

For minor copy edits, corrections, and non-substantive changes, we use a lighter process to get things completed more quickly. The chairs and staff contact will determine what can fall under this process for minor changes.

This process is also used for corrections that are important to publish right away.

Process:

  1. Document editors, EOWG chairs, and staff contact approve changes. Changes are published.
  2. EOWG is notified of changes and opportunity to review. Usually this will be listed in Work for the Week. (Optionally it can be via e-mail to the main EOWG list &/or in a weekly survey.)

Note that EOWG still reviews all changes to EOWG Resources. The only difference is whether the review is before or after the changes are posted.

Guidance for Editors

(most of the OLD Archived Info below still applies, we just haven't updated it yet)

Handling comments, suggestions

Ideally everyone agrees – with the content, design, etc. Sometimes after discussion, it ends up that someone(s) says, “It’s not my preference, yet I’m comfortable going with the decision of the Group”. Or even, "I don’t like it, yet 'I can live with it'”.

Usually editors do the initial comment processing, and bring to the Planning Team (Co-Chairs and W3C Team Contact) comments that we might want to bring to all of EOWG for more input.

  • Editors thoughtfully consider each comment. Think about the big picture, the goals for the resource, the audience and use cases, etc. (not about your personal preference)
  • If you agree:
    • Make the change.
    • Notify the commenter. e.g.:
      • GitHub issue — Comment “Done.” and close the issue.
      • Survey comment replies — Send e-mail to the EOWG list that all comments in a survey have been addressed.
  • If you do *not* agree, discuss it with the commenter &/or Planning Team &/or all of EOWG:
    • If it’s big issue and/or the commenter feels strongly and/or you think EOWG would like to know about the issue and provide input — bring it to the Planning Team to prepare for EOWG discussion.
    • If you think the commenter might be OK not doing it once they understand your rationale — Reply to the commenter (in GitHub issue or e-mail) about why you think the Working Group wouldn't want to make the change. Invite them to discuss it further with you &/or Planning Team &/or all of EOWG. Archive the exchange, e.g., in GitHub issue or CC: public-eo-archive@w3.org
    • If in doubt, bring it to the Planning Team to help decide the best course of action.

“Bring it to the Planning Team” means:

  • Provide a list of open issues(comments) with pointers (e.g., to GitHub issues or e-mail archive)
    – by Tuesday afternoon, either:
    • Add to the upcoming EO-Plan Agenda, under “Potential Agenda Topics for EOWG Meeting” or “For discussion”
    • E-mail to public-eo-plan@w3.org (or not publicly archived: group-eo-chairs@w3.org )
  • Join the EO-Plan meeting to discuss.

Note: Always have a “paper trail” of how comments were addressed, e.g., GitHub issues or public e-mail archives.





OLD Archived Info

[old version] Review Stages and Levels

Stages: Resources are typically reviewed by EOWG in the following stages of development:

  1. Rough concept draft (or rough wireframe for tool) — Review for overall content and general design. Do not bother with word-smithing or copy-editing or design nit-picks.
  2. In-progress drafts — Usually there will be specific review questions on certain sections or issues.
  3. Complete draft — Review for things like: Are all points covered - is anything missing? Is there anything in there that shouldn't be? Word-smithing suggestions usually welcome. Try to catch all significant issues at this stage. (if you bring up big issues later, it will be annoying :-)
  4. Thorough review! — Review everything at all levels, including copy-editing. This is the pre-publication review, our internal "last call".
    • Any changes after the Thorough Review will be documented so participants can review just those changes and don't have to re-review the whole resource.
  5. Approval to publish — Usually there shouldn't be any more comments at this stage, it's just the formal sign-off.

Sometimes Task Forces or small groups, rather than all of EOWG, do most of the in-progress draft reviews.

Levels:

  • High-level - Comment on organization, structure, flow, tone, approach, meeting audience needs, overall content, etc. Do not bother with word-smithing or copy-editing or design nit-picks.
  • Detailed - Hopefully no high-level comments are needed at this point. Now is the time for detailed comments on specific content, including wording.
  • Show-stoppers - The Editor thinks the resource is ready to publish, and/or we are trying to meet a specific publication date. Only important issues should be raised as show-stoppers. Optional comments are welcome, marked as "editor's discretion" or "future enhancement".

Editorial Teams

EOWG is trying an approach where a specific resource will be worked on first in smaller Editing Teams. We hope this will let individuals focus more attention on specific resources that they are particularly interested in, and help get more resources developed and revised more efficiently.

The expectation is that minor issues can be worked out in the Teams, allowing all of EOWG to focus on bigger issues. Resources brought to all of EOWG will already have been worked through by the Teams and will have clearly defined issues to address.

As a reminder, it is important that for formal EOWG deliverables we:

  • ensure that they reflect the perspectives and contributions of multiple different stakeholders in a wide range of environments (large industry, small consulting, developers, trainers, proj management, policy, geographic, disabilities, etc., etc., etc.)
  • develop consensus among WG participants particularly, and also commenters
  • maintain high quality

Notes:

  • If you want to change your resource team assignments, e-mail public-eo-plan@w3.org
  • Editorial Team participants - commit to reviewing carefully and commenting "in a timely manner".
  • Editorial Team [monitors] - would like to be included in review opportunities, yet don't commit to completing all reviews.

Teams Approach

The overarching approach is that the Teams will:

  • Try to represent a wide range of perspectives (not just their own), and actively solicit input outside of their areas, such as international perspectives.
  • Make initial decisions when there is clear consensus within the Editorial Teams. Communicate the issues where they had some questions or specifically want additional perspectives.
  • For issues where there is not clear agreement within the Teams, the Editors should present the issue for broader input from EOWG (and WAI IG and others as appropriate) — with a brief summary and pointer to background discussions (in GitHub, etc.).

Process for revising existing resources:

  1. Editors review resource and provide summary of significant suggested changes – can be quick bullets – and any questions or issues at this point, especially that impact overall approach.
  2. Discuss with EO Planning Team and see if need EOWG to review suggested changes and big issues.
    (Brent provided example of helpful initial feedback in 21 July teleconference)
  3. Editors draft changes.
    Editorial Team reviews draft.
    As needed, bring issues to EOWG (per next section)
    Iterate as needed — number of iterations needed usually depends on extent of revisions, sensitivity of topic, etc.
  4. When Editorial Teams thinks it's ready, Editors bring to EO Planning Team to schedule EOWG full review. Usually this will be a "Thorough Review" (aka last call). Editorial teams provide:
    • Explanation of any issues for input from EOWG
    • List of changes &/or diff version
Minimum for Relaunch, Log for Later

Important: We want to do minimal work to update and clean up resources for the redesigned website soon. We have planned time later to make revisions that take more time to develop, review, and get consensus on. Please do record ideas for later revision, e.g., in GitHub with Labels and Milestones — e.g, https://github.com/w3c/wai-policies-prototype/issues/223 has label "future enhancement" and milestone "Post-Launch Enhancement".

When and how to bring what to EOWG

We encourage Teams to bring questions, issues, and drafts to EO Planning Team and then to all of EOWG whenever it will be useful to get broad input.

  • Issues can be brought to EOWG (after coordination with EO Planning) individually, as a batch, or along with a draft for review.
  • If a Team needs EOWG input on an issue (such as overall requirements, structure, approach, content outline, etc.) before moving forward with the resource — or if EOWG input could substantially change the work, they should bring it to EOWG soon.
  • If several smaller issues are accumulating, it would probably be good to bring them to EOWG to avoid lots and lots for EOWG to process at once.
  • @@ complete draft for review @@

How to bring issues and drafts to EOWG: It is most efficient to have specific issues/questions for EOWG.

Communications

Optionally, you can have a separate mailing list for your Editorial Teams -- just ask Shawn to set it up.

If you don't have a separate list, CC e-mail communications among your Team participants to public-eo-archive@w3.org. That will:

  • Fulfill EOWG's mandate to conduct work in public space
  • Let us go back and look up or reference info if needed
  • Help Chairs and Staff keep on top of things and see if there are ways they can help

You do not need to replicate GitHub issues to any mailing list; GitHub is sufficient public archive.

Editors:

Editing Approach

For most documents:

  • Simplify & Tersify — Make content simple and brief. Cut words. Cut Sentences.
  • Bullets & Graphics — Break up passages into bullets when appropriate. Suggest graphics.
  • Front-loaded Action — Use active voice, and action statements.

For spelling, punctuation, editorial style tips, etc., see WAI Style Guide (which includes language tools and Edit Examples)

Comments and changes

  • Editors should track, manage, and respond to issues in GitHub and comments in surveys.
  • Generally, Editors can close issues, and should invite the commenter to re-open it if they are not satisfied with the resolution.
  • Editors should usually provide a list of substantial changes &/or issues. In later stages, it is usually helpful to provide a diff showing changes.

To provide a diff using rawgit:

  • @@
Retrieved from "https://www.w3.org/WAI/EO/wiki/index.php?title=EOWG_Participation_Info&oldid=39031"