Important note: This Wiki page is edited by participants of the EOWG. It does not necessarily represent consensus and it may have incorrect information or information that is not supported by other Working Group participants, WAI, or W3C. It may also have some very useful information.


EOWG Participation Info

From Education & Outreach
Jump to: navigation, search

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-curricula@w3.org (curricula archive) — for work on Curricula, including Task Force communications
  • 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

EOWG meets by teleconference:

  • Fridays 8:30am US Eastern Time for up to 2 hours

To find what time this is in your region, you can check the world clock meeting planner.

Upcoming Teleconference Schedule shows which days we are meeting.

The phone connection and IRC info is linked from the EOWG meetings wiki page.

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

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. Consider running your comments by the editor &/or Chairs before posting them publicly.

  • Read background material, such as the Requirements Analysis (that has goals, audience, etc.), before commenting.
  • Know which review stage and level the draft it at.
  • Provide specific, clear, succinct comments that are:
    • quickly understandable to all EOWG participants
    • easily action-able by the editors
  • Usually include proposed re-wording and rationale for it.
  • Ideally through GitHub fork, edit, pull requests:
    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 or Issues for each comment or suggestion. (Typos and other corrections can go in a single pull request.)
  • If in GitHub issue, survey, or e-mail, make sure to include the location of text you're commenting on, ideally with a link to it, and indicate the level. Comment format suggestion:
    • level: (low, med, high for draft reviews)
    • location: (such as: "page: Image Maps. under Introduction heading, third paragraph")
    • current wording:
    • suggested revision:
    • rationale:

Comment Levels

For draft reviews:

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

For butterfly approval to publish reviews:

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

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 — Fine-toothed comb grooming

monkey picking at another   
(fka "thorough review")

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.

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.

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

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:

  • @@