AB/Guide

Welcome to the AB Guide. This page is a work-in-progress that describes many aspects of working as a member of the AB.

Language of the Process Document

The Process document defines the Advisory Board, outlining its the overall responsibilities and participation rules.

It also defines the role of an AB participant as acting in a personal capacity, emphasizing that AB members

do not represent their companies: they use their best judgement of what is good for the Web and the W3C Membership as a whole.
are expected to participate fully.

Values and Behaviors

All W3C participants are expected to adhere to W3C's Code of Conduct. But AB Members, as leaders of the community, have a special responsibility to be role models for this code.

Time Commitment

The AB conducts 4 F2F meetings through the year. Each lasts for three days. Locations are rotated around the world. Unless there is a significant conflict, all AB Members are expected at all meetings. When a conflict arises, AB Members are expected to dial in as much as they can.
AB members are also expected to attend the two Advisory Committee Meetings every year. Aside from participating in the meetings, it is an opportunity to interact with the membership.
The AB conducts 2 one hour calls every month (first and third Thursday) at 14:00 UTC.
The AB deals with many issues raised by the team, the AB, and the membership. It also reviews key material from the team and revisions to W3C governing documents. It is expected that an AB Member can devote four hours per week reviewing these documents.
The AB is responsible for managing the evolution of key W3C Governing Documents such as the W3C Process Document. It is highly desirable that AB Members participate in the W3C Process Community Group (which meets for an hour every other week) and stay abreast of key issues.
- It is recognized that some AB Members might prioritize their AB time on other critical matters and not be among the most active on process evolution.

Speaking guidelines

There are speaking nuances that are important to respect for two reasons. First, AB Members while serving on the AB are supposed to represent what is good for the Web community and W3C Membership - not their particular organizations. Second, as senior members of the W3C community their opinions carry special weight when outside of AB meetings. Here are some guidelines.

During AB meetings
- The basic assumption is that any opinion expressed in such a meeting is the opinion of the AB Member as an individual.
- There may be times when an AB Member thinks it is relevant to express an organizational view. In that case, it should be explicit (either in words or from context) that the AB Member is speaking in a capacity different from their role as AB Member.
- If your view in some other capacity (e.g. as an AC rep) differs from your view as an AB member - and that is likely to come out (e.g. if the AB approves something that you will object to as an AC rep) - then it is courteous to inform your AB colleagues in advance.

When speaking outside of an AB context
- Don't use the phrase "on behalf of the AB" unless the AB has specifically asked you to send the message
- When representing the AB, be clear that you are representing the AB
- When not speaking for the AB you may judiciously, but carefully, make mention of your being on the AB. Here are some examples:
  - If you are making an observation which is far from the AB's business (e.g. a technical remark in a Working Group) there is no particular point in mentioning the AB affiliation.
  - If your point is influenced by being on the AB, you may mention that ("in my experience on the AB, I find that…")
  - There is no need to hide your AB affiliation
  - If you are discussing a point that may come up in an AB discussion (e.g. an item related to the scope of W3C) you must make clear that you are NOT speaking for the AB. Otherwise the point might be misunderstood as a widespread view within the AB.
  - You will be held to a higher standard, as a result of your elected status (e.g. the AB owns the process and shepherds the code of ethics and professional conduct, so one might presume careful adherence)

How to represent AB decisions

When formally representing an AB decision to others (e.g. email to AC-forum, presentation at AC meeting)
- Express clearly what was decided and what was not decided
- Make sure that all written material is shared with others on the AB and that there is time to comment
- If time pressure prevents adequate time to vet material; as a minimum there should be a 24 hour comment period plus review by the AB Chair
When discussing an AB decision
- Be respectful about the decision even if you did not support the AB consensus
- Be respectful of all points of views, including those that did not gain consensus
When discussing an AB activity which has not yet reached conclusion
- Emphasize that the work is an ongoing activity, not a conclusion
- Emphasize that the AB as a whole is always looking for input (and if relevant point to the AB member-only GH repository)
- It is expected that you share your material with the AB in advance
  - It is recognized that there could be extreme timing cases where sharing in advance is not possible.

Meetings, Calls and Agenda Management

The AB typically meets the first and third Thursday of every month. These meetings are not open to the AC or Membership in general, although brief summaries are shared immediately afterward, and minutes are shared within a week or two. The AB Chairs are responsibly for planning and setting the agendas of the meetings, which they post (https://www.w3.org/Member/wiki/AB/Agenda) and send out to the AB and the AC. AB members are asked to help guide priorities for these agendas by using the "Agenda+" and "Agenda+ next meeting" labels on Github issues. (Non-AB Members may also request for the AB to take up issues, as well.)

The AB has developed a deliberate culture in the management of its meetings, intending to maximize inclusion and respect in deliberations while still progressing discussions to conclusion. The AB typically has members in many different time zones, with different language and cultural backgrounds, and we want all voices to be heard equitably. To that end, it is important to understand that our discussions are not an open free-for-all dialog, but neither are our meetings run formally by Robert’s Rules of Order. Our goal is to have a respectful, inclusive discussion, with everyone getting a chance to participate.

Our meetings are hosted in Zoom, typically with automatic subtitles turned on. (This record is not retained, but assists participants in tracking the conversation.) We typically have a scribe taking minutes in our IRC channel, while the Chairs are simultaneously managing the speaking queue with Zakim in the same channel. We rely heavily on the Chairs to manage flow of discussion in the meetings, asking for the next participant to speak in turn. The Chairs are responsible for ensuring that all speakers have a fair opportunity to engage and express their views, while attempting to manage a logical flow of conversation. With that in mind, we have a few rules and suggestions we like to follow:

Chairs will usually use the timing tools in Zakim to limit speaking turns to two minutes. The intent is not to cut people off, but to encourage speakers to be concise. Presenters for a given topic are not limited to this two minute timer initially.
Chairs will explicitly manage the queue trying to keep a logical flow of conversation. When you want to speak, type “q+” in the IRC channel. It is also a good idea to add a brief note about WHAT you are going to say: for example, you can say something like "q+ to suggest an approach based on quantum mechanics" or “q+ to ask about a different topic”. The chairs (and other participants) can see this comment in the queue, and the chairs regularly use it to prioritize speakers. If you only say “q+”, the chairs don’t know what you’re going to say, and you may have to wait longer to get your turn.
If you have a direct, immediate response to something another participant is saying or asking, and your response is brief, you may simply enter “qq+”; this inserts you at the head of the queue to respond to the current speaker. Do not over-use this tool.
Chairs will also sometimes prioritize those who have spoken less frequently, and call on participants out of turn to encourage diversity of participants.
You can also remove yourself from the queue by using “q-”, or push yourself to the last place in the queue by saying “q- later”.
Because the minutes are generated from the IRC log, we DO NOT hold conversations in IRC that are not reflecting the live conversation. If you have something to say to the whole group, put yourself on the queue and say it aloud. (If you are unable or unwilling to speak aloud, channel your comment through one of the chairs.) It is common practice to add links or references to documents being discussed, or indicating agreement with what someone else is saying (for example, saying "+1 cwilso's point about focusing discussions"), but side conversations should not be held; nor should IRC be used as a way of "getting something on the record" without taking a speaking turn and making your statement to the entire group.
However, sometimes it IS useful to make comments that should not be reflected in the minutes - you can do this by typing "/me " first - for example, when we're in the middle of a conversation but you are getting hungry, you might type into IRC "/me thinks it's time we broke for lunch", and the group will see "<alias> thinks it's time we broke for lunch" as an out-of-band comment. This will be omitted entirely when generating the minutes.
Chairs may also pause at significant topic points to enable cognitive catch-up; for example, when a question is being asked, a poll or vote is being taken, or when a topic is changing. This is intentional.

Github and Issue management

We keep a lot of information on a the AB wiki, but we also have several GitHub repositories:

https://github.com/w3c/ab-memberonly - This is visible to W3C members, and we have historically done most of our work in this repo, and managed most of our discussion topics in the issues in this repo.
https://github.com/w3c/AB-public - This is public, accessible to anyone (not just W3C Members), and is currently primarily used for the Vision document.
https://github.com/w3c/AB-private - This is only visible to the AB and some members of the W3C Team. This is for sensitive issues, and we try to avoid needing to use it.

Decisions and Consensus

The Advisory Board attempts to operate by consensus, and the chairs follow a set of rules to guide determining consensus, and making decisions when consensus is impossible.

Chairs may take straw polls to assess consensus.
1. This should take the form of "POLL: [proposal/proposed wording]" and responses should be in the form of "+1/0/-1". (+1: in favor, 0: abstain or no opinion, -1: against). All polls should be open until everyone present has responded, or for at least one minute from the time it is posted in IRC to the closing of the poll by the chair
2. If there are no -1s, and at least a majority of the poll responses are +1 rather than 0, Chair may declare consensus with no further action.
3. If there are any -1s, or a substantial portion of 0s, Chair should request elaboration not in favor of the proposal, and further discussion ensues. If the proposal changes substantially during the discussion, a new poll should be called.
4. Once all opinions have had a chance to be voiced, the chair may ask if everyone is willing to accept the proposal (even if there is disagreement). If everyone is willing to accept, the chair may declare consensus on that proposal.
In extraordinary cases where consensus cannot be reached, and the Chair believes both that further discussion will not be productive and that a decision needs to be made, the Chair MAY call for a formal vote. In this case the group SHOULD have consensus that such a decision is necessary. For groups that may have more than one member from a given Member entity, only one vote should be counted for each Member entity. (This does not apply to the AB, and rarely to the TAG.)
1. Votes should take the form of "VOTE: [proposal/proposed wording]" and again, responses should be in the form of "+1/0/-1". All votes should be open until everyone present has responded, or for at least one minute from the time it is posted in IRC to the closing of the poll by the chair. If there are more +1s than -1s, the vote passes. This should be represented as a group decision, but not as group consensus.

Project Workmode

This section is proposed draft documentation of the AB's default workmode on AB/Priority Projects.

Written by Tantek Çelik, with some additional content contributed by User:Fantasai, this section is in the process of being discussed and does not yet have consensus of the AB.

The intention of this section is to document the existing default work-mode best practices on AB/Priority Projects and is not intended to create or propose any new work-modes, nor attempt to capture the complexity, specialization, and depth of the individual workmodes of ongoing and more mature Open AB Projects.

Much of this DRAFT is based on the workmode on the AB/Vision project before and during the AB/2022-f2f in Berlin which was used to process issues, propose resolutions & edits, reach consensus on many of them, and update the Vision document accordingly. Some experience from past AB Priority Projects (e.g. patent policy) has also been incorporated.

Additional suggestions based on experience of best-practices in any AB/Priority Projects are welcome and may be included, preferably with citations of which project, and during which time period of work.

Member-only feedback/discussion link: https://github.com/w3c/AB-memberonly/issues/162

DRAFT

Work mode best practices:

When one of the AB/Priority Projects ("the project") requires creating or iterating on a document, leads on the project should:

draft and edit the contents of that document as (or delegate to separate) editor(s) with good faith understanding of AB member expectations and input towards a goal of AB consensus
work on the document preferably in a public space like the AB’s Public GitHub repo, unless there is a specific reason to keep it Member-only and then use the AB’s Member-only GitHub repo and explicitly document why it is being developed there.
maintain accessible document(s). whether public or member-only, in a GitHub repo or wiki page, edit the document(s) in an accessible format and service (if any)
explicitly seek out participation from any existing CGs/IGs/WGs which are directly related to (e.g. have in their charter scope) the primary subject of the project
process issues & pull requests (PRs) filed on the document balancing the following considerations at editor's discretion:
- cluster similar issues/PRs, so that they can be discussed / considered together
- handle trivial / uncontroversial issues/PRs as they come up, so that they don't sit in a backlog unnecessarily
- regularly triage older issues and find some way to incrementally move them forward towards an eventual resolution
- prioritize succinct, well-written, narrowly-scoped issues/PRs to provide incentives for contributors to file & comment accordingly
- simplify long, vague, or position statement essay-style issues by extracting one or more (perhaps all discernible) new specific narrowly-scoped issues, process individually, then conclude by asking on the original essay-issue for any remaining concerns (see also variants below)
facilitate the conversation in issues/PRs, identifying common ground among participants to grow areas of consensus
propose resolutions in the issues/PRs themselves, and attempt to asynchronously reach consensus or at least absence of objections
propose issues/PRs with proposed resolutions to the AB for review/approval at an AB meeting
summarize and lead any requested discussion of proposed issue/PR resolutions at an AB meeting, requesting consensus without objection
perform the necessary edits and issue/PR closures/updates as a result of the discussions/resolutions at AB meetings
iterate to simplify the document further, to make it easier to read and understand, especially for folks whose native language isn't English.

Additional best practices to consider:

The following best practices have worked for some leads/editors, on some specific projects, but also have disagreement from other leads/editors. Consider them for your particular AB Priority Project if you like and report on your experiences doing so:

process issues & pull requests (PRs) filed on the document balancing the above-noted and the following considerations at editor's discretion:
- try to process and make incremental progress roughly in date filed order, for these reasons, while also considering subsequent points for efficiency
  - Reason: this is more respectful to & inclusive of lesser-known voices & participants, instead of preferring newer (possibly duplicate) issues/PRs by more "well-known" individuals
  - Reason: it helps avoid the "recency trap" (described in Practices to avoid below) which is a known trap that even experienced editors have been vulnerable to
- for long, vague, or position statement essay-style issues, there are two different specific approaches that different leads/editors have found productive as best practices:
  1. extract one (perhaps the first discernible) specific actual issue and redirect the remaining labor to the filer to instead file additional succinct, well-written, narrowly-scoped issues for their remaining concerns as a learning opportunity, and to hold a boundary against filers writing essays and assuming someone else will do that work for them
    OR
  2. extract all of the actual discernible specific issues from an essay-style issue, then ask the original issue filer to note any remaining concerns, rather than take on the labor of coaching the original issue filer into properly filing new specific issues
- beyond extracting one specific issue from long, vague, or position statement essay-style issues (as noted above), consider taking on the extra labor to extract and process into multiple specific actual issues contained therein (instead of asking the original filer to do that extraction), and then ask the original issue filer for additional specific issues for any remaining concerns

Practices to avoid: based on actual experience, the following practices have been found to be counter-productive to collaborative AB Priority Project work:

solo rewrite of an entire document (or entire sections thereof) without working with the existing authors / collaborators
default artificial-urgency recency trap of "must respond to the latest email/issue ASAP", this may take the form of:
- pursuing the latest shiny questions/ideas at the expense of dealing with long-term matters
strictly prioritizing and getting wedged on almost-insoluble long-term problems and not dealing with more soluble ones
...

END DRAFT