Noticed today during strat discussions:

The guide states

This page is Public

which is good, and useful, and should to the extent possible be true.

The first non-navigation section then states

Note: The information in this section is W3C Member-only.

which is sad, confusing, and off-putting. Also partly untrue. The information, the titles, are clearly public. What is not public are the links, which go to the Member-only chairs mailing list archive.

I am concerned that readers may not go on to the following sections in the guide, after such an unwelcoming and confusing message.

There are several things that might fix this.

Firstly, the list of newsworthy links, which does have value, could be moved to another page to clearly separate out the Member-only from the Public information.

Secondly, is the information really Member-only? For example

2020 Process Document and Patent Policy operational

That isn't Member only. Both documents, W3C Process Document & W3C Patent Policy are public. The only Member part is that the announcement was made to a Member-only list.

Changes to I18N HR requests

Again, public. The GitHub repo for I18N HR requests is public. The only Member part is that the announcement was made to a Member-only list.

Automatic publications - Chairs can now create tokens

That one, token creation, is indeed restricted to Chairs only.

Feedback on Horizontal Review

That is a request for feedback, including from document editors. Unfortunately, any document editor who doesn't have Member access won't have seen that request; the announcement was made to a Member-only list.

So there is a pattern of creating news items from selected, archived postings to a Member-only list. This could be made more welcoming by also posting the public ones to some public list and linking to that archive, to make the news items.

Thirdly, re-examine whether the Chairs list needs to be public or whether a new, Public, Chairs list could be used for most postings?

"Meeting duration should be limited to 4 hours per day; consider two 90-minute segments with an hour break between them. That break can be used by the participants for "hallway" conversations, arranged on separate conference channels."

Is this proposed as a W3C rule, or as a recommended best practice? Is it due to concerns about duration of hours that people are on videoconferences overall, or concerns on a per-group basis? Or because it's assumed that every meeting will bridge most time-zones? Many will, but probably not all.

In the case where a meeting is mixed-mode (some participants face-to-face, and some remote) capping a meeting to four hours could create odd results, for instance disadvantaging people who have gathered, or disadvantaging people who must be remote but are actually in the same time zone and available for longer.

Please consider raising the issue of meeting duration to people's awareness, and recommending a four-hour cap as a best practice, but also adding a preamble to the document recommending that these best practices should be read and discussed as needed, but that negotiated exceptions are acceptable if the group consenses those exceptions.

Generally, some of the document has a tone of "considerations to take into account;" other parts "recommended practices"; and yet others as "you must to do this." +1 to "please consider" and -1 to "must" unless the requirement is well-backed up by information or experience.

Team has updated practices for getting re-review of changes proposed during charter review. Add more detail to the guide. PR #31

General comment on this section: Most people will be skimming this, and it's hard to follow. I suggest adding a topic word or two at the beginning of each paragraph to clarify the organization of this section and make it easier to find relevant information. Given current content, you could consider: "Use of video conferencing services" "Scheduling" "Materials" etc.

Additionally, add a topical paragraph, either with the sub-head "Web For All" or specifically "Accessibility." I am guessing that there are I18N, privacy, and security considerations that people could be briefly reminded of here, which would favor a "Web for All" topic word. Definitely there are accessibility considerations. We will be developing this further, but for now, please use: "Accessibility: Please ensure that virtual presence meetings are accessible for participants. Check needs in advance with participants. Use WAI resources and/or contact W3C staff for questions as needed."

Suggested in the Working Group Effectiveness Task Force to add guidelines for creating explainer documents (w3c/wg-effectiveness#66)

People need to search /guide. How will this work?

With several workshops in the pipe (one cancelled already), how do we plan for workshops during travel resctriction times?
(via @wseltzer)

There need to be lines with appropriate links for a11y, security, and privacy (anything else?)

@RachelComerford made a great comment as to how to manage issues more effectively (w3c/wg-effectiveness#50). Suggest these are added to /guide:

One the major struggles that we face in the groups I participate in is in getting productive responses to issues. Too often I see thinly disguised sarcasm, personal complaints that are unrelated to finding a solution, or a long list of reasons why something won't work without any proposed solutions. In problem solving, I try to ask participants to answer the following questions:

What problem are you trying to solve?
What solution are you proposing?
Why do you believe this is the ideal solution?
What alternatives did you consider
What is your back up plan?
Consistency in enforcing these structured responses is difficult (and I admit to struggling with it) but without this, I see newer members to groups and in particular newer members to the W3C/W3C processes alienated by lack of explanation of methods, uninterpretable proposals, and (in my opinion the worst offense) the attitude that can sometimes accompany experience.

While it will be difficult to convince some member to abide by guidelines like this, I think it would be a beneficial structure (or something like it would be) to recommend in order to help keep github conversations civil and effective.

The Working Group Effectiveness Task Force discussed the following in (w3c/wg-effectiveness#73). Suggestion is to provide guidelines for this in the new /guide.

This issue continues the discussion from w3c/process#505 . That issue has been resolved in the Process CG to add provision for an Alternate AC Rep to Process 2021.

I've added draft Guide text in https://github.com/w3c/Guide/blob/main/process/alternate-ac.md

mentioned continuously in the working group effectiveness task force. Below is a comment from @astearns

I strongly believe that whatever improvements we want to make (videos or other introductory material, rearranging docs, etc.) should happen in the WPT documentation repo directly
https://web-platform-tests.org/
It's known that the docs there could stand improvement, and I believe the WPT folks would welcome the help.
We've had problems before with multiple, separate attempts at testing infrastructure (contradictory, each somewhat out-of-date, too difficult for a single project to integrate them all). We should be leveraging the momentum that WPT has as a single source of web engine testing.

• manu training session, video

• ivan herman piece on how to use github

suggested in w3c/wg-effectiveness#62

The file is where it's supposed to be, but a redirection is hiding it behind a 404 coming from GitHub.

@iherman says that “newer charters rely on this CSS[…], so they do not display correctly :-(”.

Note that this might be happening to a few other files under the same directory, too.

Apart from the separate reminder about accessibility at the end of the "Arrangements" section, people also need a reminder that materials presented in remote meetings must be accessible. On a videoconference platform, there are mutliple ways to do this.
So where it currently says:
"Materials Presenters are even more strongly encouraged to distribute (post to the Web) presentation materials in advance of the meeting to allow participants to avoid using extra download bandwidth during the meeting" add "Presentation materials must be available in accessible formats that meet WCAG 2.1 AA. If it is not possible to provide a structured document within a videoconference presentation window, provide access to an accessible source file."

"Video cameras are strongly encouraged; this improves the sense of being together. Groups may prefer to use teleconferencing services that allow each participant to choose not to receive video streams if their network becomes saturated."

Please add a cautionary note: Please note that not all participants may be able to see each other on a videoconference. This may be because of visual capabilities of devices, or capabilities of participants.

Please be sure to at least provide informal real-time descriptions of video action, to keep people informed if they are not able to directly view their presention,

We may want to update Dealing with timezones with consideration for consecutive meeting days.

In the context of our recent virtual meeting we received the following feedback:

I'd suggest future meetings avoid consecutive days with meetings at the extreme end of the day. In practice this would slow down the overall meeting speed, e.g. taking two weeks instead of one.

@scheib @reillyeon @xfq

@nrooney and/or anyone from the WGE TF can say more, but there's a request to revamp /Guide and make it really useable (sic).

The W3C internal webdesign task force may be able to help.

Chairs must make equal time to hear both sides of an argument and work with participants to encourage consensus via such a route.

Given the lack of representation of smaller organizations that can afford the time to participate in the wide range of W3C groups and other trade organizations, it is incumbent upon the W3C to ensure that lack of counter arguments is a testament to widespread consensus, rather than an indication of wider participation.

This is important to further ensure that the W3C is not used as a channel for anticompetitive conduct or collusion.

I need to add this to the new /guide content. Can someone link me to it?

Or as section?

• AC Reps

• Link to process doc

In Continuity of Operations, under "Different Meetings" you note that TPAC 2020 is, as of 13 March 2020, happening as planned, on 26-30 October 2020, in Vancouver BC, Canada.

Good place to demonstrate that we have already announced that we are virtualizing the AC Meeting originally planned for Seoul in May.

Have group specific pages section which explains tools specific for those group. CSS group is a good example.

Continuity of Operations under Travel Restrictions
https://w3c.github.io/Guide/meetings/continuity.html

Currently states: "Groups should plan to make extensive use of video conferencing services for those unable to travel. If a substantial number of participants are unable to travel the group is encouraged to conduct the meeting entirely by video conference, avoiding even local "hubs". The goal is to put all the meeting participants on equal terms."

It may be more useful to encourage meeting organizers to note that there are many different modes of telepresence and/or remote gatherings. In the case of travel restrictions for some but not all participants, those without travel restrictions might want to gather in a hub, and it is unclear that the benefit for those individuals would somehow adversely affect the experience of those who couldn't gather in hubs. Equitable participation could be assured by following good communication and meeting participation practices, rather than by depriving those who can gather of the opportunity to do so.

Instead of imposing constraints on options for gathering, W3C could commit to accommodate mixed-mode meetings, including high quality remote participation options for one, some, most, or all the participants in a gathering.

Hi! We’re working on improving the content on /guide by bringing it up to date and adding some new items to reflect how W3C and spec development works today. We’ve created an information architecture and are sourcing content from the community.

Would you mind taking a look at the below section and adding some content to it? All it would require is adding content to the link below (in md format) underneath the headings. You can also add new headings if you feel like they’re appropriate. Upload images to the `/mock/images/‘ folder and include them using relative urls.

https://github.com/w3c/Guide/blob/mock_guide/mock/code_of_conduct.md

If you feel like you’re not the right person let @nrooney know and we can assign the task to someone else; if you happen to have a name of another W3C participant who would be keen to help out please again let @nrooney know - we appreciate the help!

https://www.w3.org/Guide/standards-track/predicting-milestones.html is a 404 but https://w3c.github.io/Guide/standards-track/predicting-milestones.html isn't. I can't fix, because of all the .htaccess I don't understand.

@plehegar , you asked me to file an issue on the Web for All factors in Continuity of Ops.

I originally included this issue in #68 Arrangements; #68 (comment) , specifically: "Additionally, add a topical paragraph, either with the sub-head "Web For All" [...] I am guessing that there are I18N, privacy, and security considerations that people could be briefly reminded of here, which would favor a "Web for All" topic word."
Credit to @nitedog for the observation.

@svgeesus comment on privacy issues to be aware of on some platforms is one example of potentially relevant privacy considerations to mention, as it has been on the Chairs' list.

@swickr this overlaps a previous issue that is now closed, but opens a clearer issue so as not to miss this item.

We're about to formally discontinue w3c/ghapi.
Before we do so, I'm tracking possible usage of that tool.

I found references to it on
/participant/group_specific_data/README.md
, and that seems related to
https://w3c.github.io/Guide/participant/group.html
and to
https://w3c.github.io/Guide/participant/group_specific_data/group.html
.

What are those documents? Are they still useful?

You may have to rewrite those soon, to stop using ghapi, and rely on querying the GH API directly instead (or take up ownership and maintenance of ghapi yourselves).

/cc @ashimura.

The Working Group Effectiveness Task Force discussed the following in (w3c/wg-effectiveness#70). Suggestion is to provide guidelines for this in the new /guide.

These guidelines can state things such as working with timezones, using presentations, speaking tips and other items documented and presented by Judy Zhu at AB 2014 (this might be the incorrect year - ask Natasha to check) and others.

I originally raised this on the Comm team mailing-list (team-only link), but here seems a good place for that discussion.

It seems common (and good!) practice these days to use a GitHub repository to prepare draft WG charters, either directly within the w3c/charter-drafts repo, or using a dedicated repository as done for the Second Screen WG Charter.

When doing so, the URL sent to the Advisory Committee for review typically looks like https://w3c.github.io/[foo].

When substantive changes are made to the proposed charter after AC review, section 5.3 of the How to create a WG or IG page in the Guide book requires the staff:

1. Mint a new URI for the version of the charter that includes the changes. In the "About" section of the charter, please link to the original (reviewed) charter.
2. Modify the original charter in place with the following status sentence at the top: "This charter has been superseded as a result of Advisory Committee Review; please see the [revised charter]".

While it's easy to track changes made to a proposed Charter on GitHub, there is no easy way to mint a new URI in that case: https://w3c.github.io/[foo] will always return the latest version. Unless we want to enforce stable snapshots there, I would suggest to extend the section with something along the lines of:

Alternatively, the original charter may be modified in place to link to the history of changes with the following status sentence at the top: "This charter may have been superseded as a result of Advisory Committee Review or other feedback, please check the [commit history] for details"

"Agenda items during virtual presence meetings could take several following forms. The list below proposes different methods of replacement in lieu of in-person meetings. "

Might be useful to indicate that these are suggestions, not prescriptions.

I am concerned about this scenario (which has played out several times for me)

1. As a group chair, I see a non-member harassing people in our repo.
2. I warn them to follow our CEPC
3. They continue and/or escalate their harassment
4. I act to ban them (asking a team contact or sysreq to help)

I think for this I am the accuser, and there’s a sentence that says I should recuse myself in that case. Is that the intent (that I should find someone else to do step 4, or wait until someone else complains before step 2)?

The Working Group Effectiveness Task Force discussed the following in (w3c/wg-effectiveness#71). Suggestion is to provide guidelines for this in the new /guide.

(e.g. those countries which cannot access github, or when companies block github access)

In the Chairs list @astearns started a discussion (member-only link) of the pros and cons of currently available teleconferencing tools.

The considerations include:

• scalability
• accessibility
• internationalization
• privacy
• reliability
• dial-in capabiilty
• screen sharing
• queue management
• network bandwidth
• ability for participant to turn off incoming video (see bandwidth)
• cost
• interoperable browser support

I think our guidelines for "W3C AC Meeting" ought to include a specific "Meeting duration" recommendation because assuming that we recommend that this particular meeting be fully remote (no hub --in either case, this could be clarified), I believe the meeting duration described under "Arrangements for Virtual Presence" is appropriate, provided that the AC Meeting spans more days than our habitual two.

(We typically have a 12-hour agenda spread over 2 days.)

In editing, making a charter, attending meetings, etc.

There is a link for "Moderating (Facilitating) Meetings" that goes to a wiki page titled "Moderating Meetings" whose first sentence says that it should be facilitating rather than moderating.

I think the wiki page should be titled "Facilitating Meetings" (and keep the sentence explaining why) and have the link in the guide be "Facilitating Meetings"

In the cover page, 'Quick start guide' in irc scribe section has a link to dev.w3.org as http://dev.w3.org/2002/scribe/scribedoc.htm#Quick_Start_Guide.
I suppose a page in scribe or scribe2 github.io should be a target of replace. (not sure on which at this point, although...)

(from immersive-web/administrivia#93)

Currently "accessible" points to the WAI homepage, two times. In the context, it would appear that Planning Audio and Video Media is a better link choice.

In continuity of operations document, purpose section, you mention:

"This document outlines contingency plans due to (international) travel restrictions"

Given where we are now on Covid-19, the qualifying parenthetical adjective "international" seems unnecessary at this point, as travel restrictions are now on multiple levels.

Simply removing the parenthetical would resolve the issue.

In "Arrangements for Virtual Presence"

Meeting duration should be limited to 4 hours per day; consider two 90-minute segments with an hour break between them.

It has been suggested that when there is a group who has chosen to gather in-person, especially if they have traveled to do so, they will want to be able to use more of their in-person time. Balancing this desire with the need to be inclusive of other distributed group participants is a challenge.

These are, in any case, guidelines ("should"); the group and meeting chairs might agree to alternative accomodations.

In order to build a culture of compliance no one should feel unable to speak out, or that in the event of speaking out that they will be ignored or that their concerns will not be recorded.

Transparency is core to the W3C mission. Accordingly, those supporting changes to existing process or standards put their organizational affiliation and name associated with their submissions.

The same is not true of voting to approve or reject a change. Given allegations of bullying cited in the US House Antitrust report, one method to enable people to more freely express their opinions would be to participate via secret ballot. This would ensure enhanced focus on the substance of the issue raised rather than the biases associated with the messenger or their employer. In my experience, multiple instances of bias have been expressed against entire industries that may act to stifle the very feedback W3C so values and undermines a culture of compliance.

This would also protect members accidentally engaging in collusion by being pressured to vote in accordance with the wishes of a different company, and those who would otherwise "go along with" the proposals for fear of making difficulties with businesses that are also important trading partners.

"Hand-raising will be supported exclusively via irc. Hand-raising features of the teleconference system should be disabled (preferable) or (less preferable) be bridged to irc."

Why?

I've been in multiple meetings where hand-raising within a teleconferencing or videoconferencing app was far more usable and accessible to members of a meeting. Until that improves, we have what we have, and chat within an app may need to be an option, depending on who's present.

https://www.w3.org/Guide/1998/08/TeleconferenceHowTo

switch this date to UTC to aid people not used to boston time (seems selfish I know, but I actually had this issue when I lived in Japan and needed to work out when meetings were by both knowing boston timezone and my own...)

"High quality real-time transcription of the meeting should be provided in more than one language."

This should be "high-quality real-time captioning."

Use of "transcription" here muddies the waters. [More info https://www.w3.org/WAI/media/av/]

In the Guidebook page on Zoom we suggest that the Zoom whiteboard can be enabled. A question has been raised as to whether the Zoom whiteboard is accessible.

Needs to be included in the new /guide. Find the correct place for it to live!

Includes IRC information. Maybe speak to Kaz and plh to see where these things go.

If we update a charter in place, we need to update the change log. If we need to create new dated links when we propose a charter to the AC AND when the Director approves a new charter.

See w3c/charter-drafts#272