w3c/wg-effectiveness

Name: wg-effectiveness

Owner: World Wide Web Consortium

Description: Working Group effectiveness Task Force

Created: 2017-08-04 19:52:47.0

Updated: 2017-12-16 22:11:57.0

Pushed: 2018-01-11 16:03:39.0

Homepage:

Size: 139

Language: null

GitHub Committers

User	Most Recent Commit	# Commits

Other Committers

User	Email	Most Recent Commit	# Commits

README

New to this repo? Feel free to comment on and add issues.

Working Group Effectiveness Task Force

Weekly call time 1pm UTC on Thursdays. Natasha Rooney chairs.

The Working Group Effectiveness Task Force is a W3C AB organised task force which aims to assess and work on solutions to improve working group effectiveness in W3C working groups.

The Task Force was setup after the assessment of some working groups which, although producing well used technologies, were not able to complete their chartered specifications on time. In response, the Common Standards Issues document was created, which aimed to help working groups identify issues affecting their progress, and help them solve these. The creation of the Common Standards Issues document lead to the creation of this Task Force.

The Task Force is currently identifying what makes a working group affective and attendee roles within a working group. Identifying these will allow the Task Force to give advice and create solutions which allow all working group attendees to contribute to successful working groups.

For other goals of the task force, see the below “Expectations” seciton.

Task Force Members

dontcallmedom, torgo, astearns, plehegar (team contact), nrooney (chair), jeffjaffe, marcoscaceres, Paul Cotton

Outcomes

The group has agreed to work on the current outcomes. We have a number of outcomes, so a Phase 1 and a Phase 2 has been agreed.

Phase 1

[Guide & GitHub] Updated /guide (Easy to Read and Access Information for New and Existing Attendees)

Updated guidance and information in an easy to find and access location for chairs, participants and implementers in how to work effectively in working groups. This information also needs regular assessing and updating as necessary. Currenly much of this information can be found in The Art of Consensus: A Guidebook for W3C Group Chairs and Participants, this needs to be re-organised, redeisgned and must include:

• information on how to effectively use tools
• including the effective use of GitHub
• information for chairs, participants, implementers
• information on testing
• information for new chairs and new attendees on how to get started within W3C (perhaps including welcome emails and welcome pack)
• Updated look and feel - ask team who work on W3C spec design

GitHub

The use of GitHub will be of large importance within this deliverable. The groups utilising GitHub properly have generally been working very effectively. Therefore, which should take great care in greating documentation on guidelines for using GitHub.

• Github guidelines mentione in: #21

Owners: (suggested)

• Information Architecture:
• Effective Use of Github Info: DKA
• Information for Chairs: Alan
• Information for Participants: Natasha

[Testing] Testing

Something to enable groups to work on better testing (currently not defined).

• Tests should be required in the process (see [process_changes])
• A testing section should be built into specs, showing testing has completed (see [process_changes])
• Detail types of tests that are required (e.g. interoperability, stress tests, security tests, etc - sad that this is evidence I know so little about tests)
• this should all go into /guide/
• No Tests No Merge should become a GitHub rule for our tools / github related outputs
• Possible ombudsman for testing.

Testing is referenced in issues: #21

Owner:

[Chair Train] Chair Guidance and Sessions

Chair sessions including dedicated breakout sessions at TPAC which can be both information giving and sharing sessions. Task Force members can inform chairs as to the new available tools and information. Chairs can share information on what has and has not worked for them in their respective groups. TPAC usuaully has a chairs breakfast presentation, in which the Task Force can present its findings.

Task Force members should also have some one-to-one discussions with chairs to get some more insight into issues working groups have experiences and how they have dealt with these.

Owner:

Phase 2

[Process] Process Changes

Some discussion within this task force has suggested process changes. These decisions cannot be made by the group, but the group can work towards promoting these and aiding the wide discussion. These possible changes are:

• Ensuring the process adheres to the “Shipping as a Feature” model (see #12)
• Tests should be required in the process
• A testing section should be built into specs, showing testing has completed (also a process change)

[CSI] Common Standards Issues Document and Triage Process

• Continued development of the Common Standards Issues document.
• Introduction of a Triage Process for when things do go wrong.

Owner: Natasha

[Ombudsman] Ombudsman for Working Group Effectiveness with Guidelines for Escalation

W3C currently has team contacts who can be approached with issues related to working group effectivness. This team should be reviewed (possibly adding some non team contacts) and promoted within the W3C. The team should have guidelines on what happens when issues need to be escalated. The task force will need to work on a flow.

Owner: plh (suggested)

Expectations

Timeline is to wrap up this Task Force at the end of November.

Links to current chair/team resources:

Now here.

Questions to ask chairs and key group members

@@TODO