Process update - Potential changes

Hi Everyone,

Thanks to those who reviewed the problem statements, it helped to distil the feedback in order start thinking through changes/solutions.

We've drawn out the suggestions from the feedback, and added some. The following list is *very* draft, for discussion. We have tried not to pre-judge anything, so there are more options than we can use. it's also a bit rough, but hopefully understandable.

The items below have also been added in to the survey as my responses as well, to have the problem statements and changes in the same place:
https://www.w3.org/2002/09/wbs/35422/process-results-pt1/results

But the formatting is better here, so these potential changes to the process, for discussion, in the same categories as before:
Consensus

  *   Document, with examples, how the group consensus process is intended to work, including:
     *   Knowing that CFC decisions are by the chairs & staff, it is not one person.
     *   Strength of argument is more important than numbers.
     *   Objections need a clear rationale.
     *   Clarify distinction between W3C voting procedures and WG consensus measurement procedures.
     *   Clear procedures to re-open discussion previously closed.
     *   More clearly document reasons CfCs are not included.
  *   Documenting why SC proposals do not get included.
  *   SC proposals do not go into the draft until approved by the group.
  *   Calls for Consensus:
     *   Clear CfCs about what the vote is (We need to define what this means - no multi-option CFC's? Or something else?)
     *   Set up separate email list for CfCs (public-ag-admin)
     *   Brief change descriptions in CfCs (I believe that we do this now, what is different?)
  *   Document reasons for things that never made it to CfC? (Not clear how this could work, and it could be a big burden on documenting a negative space. If we have a smaller set of stuff under active work, might be feasible.)
  *   Support review
     *   Find a new way to see diffs in readable and understandable way (this may not be possible within the group, the W3C needs to resolve this rather than the WG)
     *   If improved diffs is not workable, ability to review old and new (rendered) versions of doc.
     *   Ability to see history of an updated item (SC, understanding doc etc).
     *   Change logs, but what is the right level of detail?
     *   Issue templates to structure input.
  *   Clarify and expand SC acceptance requirements, can we identify the implicit requirements from before? There has been disagreement on whether an SC was testable, so what can be clarified there.
(Issue: Some requirements have to be traded against another, can we come up with principles for that?)

Timeline, scope and quality (the pick any two out of three choice):

  *   Survey group on relative importance of these three competing factors (noting other W3C priorities also impact that decision).
  *   If a WCAG 2.2 happens:
     *   Select a set number of possible SCs to work on for 2.2, and/or
     *   Require an understanding doc and a technique prior to considering it in the wider group (reduces throughput but increases quality), and/or
     *   Have pre-set "rounds", where up to 3(?) are considered for a set time, agree or not, and then the next set.
     *   Have tests for each SC prior to publication (not feasible yet?).
  *   Consider a PM type role for ensuring people do the work committed to. (Overlap with some ideas below)
  *   Increase central editorial management (issues: needs more resources, this "de-democratizes" the work)
     *   Editors do the work of migrating from wiki etc. to spec editors' draft.
     *   Editors also look after editorial quality review.
     *   Add a couple well-trained editors to the set.
  *   Efficient management
     *   Ruthless chairing of teleconferences: defer tangents to later, or at end of call summarize them and plan ways to get back to them.
     *   Clear task setting and management (though we did lots of that) - but this makes the chairing role much more project management rather than technical leadership
     *   Find someone to be designated as a project manager.
     *   Focus meetings on a limited set of issues.
     *   Clear schedule of when topics will come up for discussion (is it realistic to schedule longer-term than one week?).

Github:

  *   New tool, but there seems to be no perfect solution, we have a diverse group.
     *   Google docs pros: Easier to edit, Good wiki replacement.
     *   Google docs cons: harder to link up pieces (maybe), harder to keep style / structure, harder to view history, harder to publish to W3C (note experimental gdoc2respec<https://github.com/sandhawke/gdoc2respec>), potential accessibility issues for some.
  *   Approach Microsoft about the github interface accessibility. Especially for reading.
  *   Push W3C centrally to improve tooling options (Note: has been done, but slow and we may be on vanguard of issue discovery).
  *   Centralise editing, so a few editors become the bottleneck for changes.
  *   Training for github usage, although might need to include basic HTML.
  *   Centralize editorial role more so most WG participants only have to deal with the issues interface, not the editing interface.

Volume and locations of discussion:

  *   Monthly overview;
  *   (Try to) use only one tool for discussion. Obvious options are Github issues & email, if LV issues with Github can be resolved.
     *   Github issues could work for that if we can address some of the accessibility issues
     *   Might be a job to get people to focus there, not migrate to list or something
  *   Link meeting minutes to issue threads.
  *   Don't try to use issues/comments for document revision (for things like understanding docs)

  *   Attempt to consolidate discussion fora to reduce fragmentation of discussion
  *   Try to have one topic per issue, where feasible.

Participation

  *   Invite certain people to join TFs. (haven't we done this?)
  *   Use community group more (though brings challenges with intellectual property review and differing levels of participation)
  *   Identify ways to support / fund other participants. (not the WG's job, but we can request it from the W3C)
  *   Better wide review messaging - find where else it would be productive to send stuff.
  *   Actively recruit participants.

Behaviour and meetings

  *   Have some kind of 3rd party or escalation path to evaluate certain situations / output (already part of the overall W3C process with escalation);
  *   Emphasize good meeting behaviour (see page Janina sent<https://www.fastcompany.com/26726/seven-sins-deadly-meetings>)
  *   Document ways to get third-party input on potential bias, including W3C's structural escalation paths.
  *   Clarify that issues get dealt with in private, so are addressed even if that's not visible publicly.
  *   Intervene in discussions that are turning into flame wars.
  *   Document expectations and procedures even more clearly.

Misc

  *   Possible proposals to support more understandability of work:
     *   WG works in plain language, somebody charged with translating to spec language
     *   Work on spec language, but with more emphasis on understandability, with explicit WG review step for that (try to avoid recycling due to concerns of over-simplification) - this could be a complementary mode to above that we continually cycle between
     *   We develop spec language, but when it matures somebody makes a plain language version
     *   Develop spec in plain language - but may not be concrete enough
  *   Allow modification to previous versions
     *   Pro: Allows solving inherited problems, allows better integration of new stuff
     *   Con: Backwards compatibility promise important to many organizations, built into process and tools.
  *   Clarify W3C vote vs WG consensus procedures.
  *   Focusing 2.2 on COGA
     *   Pro: Fills in gaps, allow focus without distraction from other areas.
     *   Con: If winds up less testable, will hinder adoption; disagreement over relative priority of the needs.

Kind regards,

-Alastair

--

www.nomensa.com<http://www.nomensa.com/> / @alastc