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
Welcome to the W3C Web Accessibility Initiative (WAI) Education and Outreach Working Group (EOWG)!
- 1 The Basics
- 2 Tips
- 3 Comments
- 4 Review Stages and Levels
- 5 Process for Minor Changes
- 6 Archived Info
The EOWG home page is: http://www.w3.org/WAI/EO/
The main wiki page is: https://www.w3.org/WAI/EO/wiki/Main_Page
Work and agendas
- "Work for this week" and teleconference agendas are listed in the wiki at: https://www.w3.org/WAI/EO/wiki/EOWG_Meetings
- Current and upcoming projects are in the wiki at: https://www.w3.org/WAI/EO/wiki/EOWG_Current_Projects
The following e-mails lists are currently used by EOWG. All are publicly archived.
- email@example.com — main EOWG list - goes to all participants (and about 100 lurkers)
- firstname.lastname@example.org — for planning work in EOWG. goes to Co-Chairs and Staff (and anyone else crazy enough to subscribe). EOWG participants use this list when you want to bring work to the EO planning team and to all of EOWG.
- email@example.com — place to archive stuff without cluttering other lists. 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 :-).
- firstname.lastname@example.org — purpose: for public and others to get messages to the WG on things that need edits -- for those who won't want to do it through GitHub. goes to chairs and staff (and anyone else crazy enough to subscribe)
- email@example.com — for work on Roles and Responsibilities
- firstname.lastname@example.org — for work on Developing Web Accessibility Presentations and Training
Note: You can choose to have a separate list for a project — just ask Shawn.
EOWG meets by teleconference alternating:
- Fridays 8:30am US Eastern Time for up to 2 hours
- Thursday 6:00pm 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 Thursday and Friday 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:
You can change your answers at any time. The link to this form is on the EOWG home page near the top under "EOWG questionnaires (WBS):" and also on the EOWG Meetings wiki page under "Work for this week", Every week.
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 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
- 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 "" next to headings if your're logged in)
- Figure out which heading you want your new page to be under, and click "" after it
- Type the new page title in double brackets, e.g.:
[[XYZ Resource Revision 2018]]
- Save page.
- Your new page link will appear with (create new page), e.g.:
- Click it, edit it, save it, done!
- screen readers
- A guide to Participating in w3c calls with a screen reader
- Mastering GitHub with a screen reader, part 1
- #screenreaders IRC channel - for screen reader users to ask questions about scribing, participating in calls and meetings, using tools like GitHub, etc.
- 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:
- Fork and make the suggested change
- In the comment area,
- Put a short description of the location &/or change (e.g., "introduction copyedits") in the box replacing "Update index.html.erb.md". Preface it with the *priority* [ED] or [!!]
- Put the *rationale* in the box replacing "Add an optional extended description..."
- Submit pull request
- Comment level:
- [ED] = Editors' Discretion
- [!!] = Important to address
Review Stages and Levels
Stages: Resources are typically reviewed by EOWG in the following stages of development:
- 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.
- In-progress drafts — Usually there will be specific review questions on certain sections or issues.
- 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 :-)
- 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.
- 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 Editor and Review Teams, rather than all of EOWG, do the middle stages.
- 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".
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.
- Document editors, EOWG chairs, and staff contact approve changes. Changes are published.
- EOWG is notified of changes and opportunity to review. Usually this will be via e-mail to the main EOWG list. Sometimes it might be 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.
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
- If you want to change your resource team assignments, e-mail email@example.com
- 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.
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:
- 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.
- 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)
- 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.
- 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.
- Send e-mail to firstname.lastname@example.org (*or* add to the EO-Plan wiki page) with your proposed:
- Plan to join the EO-Plan teleconference on Wednesday to discuss, or arrange alternate meeting time
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 email@example.com. 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.
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.
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: