W3C Chair training Focus & Poductivity 2014102

© 2014 IBM Corporation

W3C Chair Training – Focus and ProductivityArnaud J Le HorsSenior Technical Staff Member, Open Web Standards, [email protected]

23 October 2014

© 2014 IBM Corporation2

Chair Training – Focus and Productivity

Presenter Overview

■ Senior Technical Staff Member, Open Web Standards, IBM Software Group

■ Standards Professional

■ Former W3C Team Member

■ Worked on many standards: HTML, DOM, XML as well as open source: Apache Xerces

■ Linked Data Platform WG Chair

■ Social Web WG Co-Chair

■ RDF Data Shapes WG Chair

■ IBM AC Rep.



Challenges

■ Rigorous W3C Process (especially at Last Call/Candidate Recommendation)– Dealing with public comments can be very time consuming– Fairly simple changes can lead to weeks of delays

■ W3C culture– Timeline set by the charter is typically not taken seriously; we need to change this.– “Perfection” is often favored over on-time delivery – fueled by fear of being stuck with the

wrong solution or no solution for years to come, which creates a vicious cycle

Very diverse community– W3C seeks to be very inclusive but the bigger the group the harder it is to get agreement– Participants often have very different backgrounds, use different terminology, and care

about different use cases– Not everyone knows how to collaborate effectively

■ Reaching consensus is harder than deciding by majority vote

■ Chairs must foster a productive environment without sticks nor carrots.

■ Co-chairing requires good communication among the chairs and agreed upon ways of working

■ Level of support from the Team can vary.



Process

■ Know the W3C Process:– Different types of deliverables: Rec Track and Non-Rec Track documents– Different states: FPWD, Last Call/Candidate Recommendation, PR, REC– Transition requests– Minimums for review periods, for implementations, etc.

■ Educate WG members so they understand what needs to be done.

■ Ask your Team contact for help when you're not sure.



Tools

■ Know the W3C tools that are available:– Trackbot, Zakim, RRSAgent– Tracker– Wiki– Mercurial

■ Educate WG members so they can help.

■ Ask your Team contact for help when you're not sure.



Keeping WG in Scope

From the Role of the Group Chair http://www.w3.org/Guide/chair-roles :

“The ability to keep the Working Group "in Charter", both for technical and IPR issues”

■ Use charter as your primary tool for scope and deliverables

■ Agree on a set of governing Use cases & Requirements to further define the problem to be addressed.

– It is very hard to solve a problem that is poorly defined.– This can also help establish a common terminology.

Develop a wish list to capture possible future work items – this provides a relief valve.



Keeping WG on Time

■ Keep track of your WG's timetable:1. Start from the charter2. Further refine it, determining intermediary milestones and deadlines that need to be met

to deliver on time:Editing, WG review, decision to publish, publication, comment period, etc.

3. Update your timetable as things progress

■ Keep the WG informed about it – force them to face the reality, do not let them think it's ok to blow the WG's deadlines

■ Propose cuts to the spec or deliverables when deadlines become impossible to meet– Non-Rec track deliverables are low hanging fruits – Primers are nice to have but not

required for success– Postpone by moving things to wishlist rather than dropping them – It is much easier for

people to accept.

Be drastic about this, consider the current WG's expiration date as final.



Conducting productive meetings

■ Send a detailed agenda beforehand– Highlight important proposals in your announcement– Keep track of time and move topics off line when running out of time

■ Drive the discussion– Manage the queue– Refocus the discussion when needed– Cut in when needed – you're the chair, you have the right to interrupt, use it– In case of tension prompt the quieter participants for their opinion

■ Restate as clearly as possible what the different positions and options are

■ Avoid open ended questions, drive discussions around specific proposals and issues.– Once a draft is available focus discussions on specific aspects of the spec, specific

sections or paragraphs if possible– Request proposed changes

Don't let the most vocal participants overcast where the WG stands– Have frequent strawpolls to check where the WG actually stands.

Make proposals



Consensus

■ Decisions are to be made by “Consensus”

■ Formal proposals should be clearly spelled out (by chair or scribe on IRC) a la:PROPOSED: Close Issue-32 by changing the type of X in section 3.2 from int to float

■ Make sure people understand the voting process and the meaning of -1!!• +1 means “Yes”• 0 means “Abstain”• -1 means “No”, as in “I object/veto.”• Variations a la “-0.5” or “+.8” are often used to express degrees of opinion, only “-1”

is blocking.

■ When someone objects to a proposal:– Ask for an explanation– Investigate possible ways to address the objection– Ask for a counter proposal

In case of deadlock:– Try to come up with a proposal that might address everyone's needs– Consider talking to the various parties off line to better understand their position



Consensus vs Majority vote

■ Consensus is Not a majority vote

■ Example:– Proposal A has a bunch of +1s and one -1– Proposal B gets a bunch of 0s, maybe a few -0.5s, and a +1 (typically from the person

who voted -1 on A!)

– Consensus is B even though the majority prefers A!!

■ Key question to ask is: “Can you live with it?”



Formal objections

■ Objective of reaching consensus must not lead to a WG being held hostage

■ Don't be afraid of Formal Objections:1. Document efforts made to accommodate objection2. Notify objector of the possibility of filing a formal objection3. And Move on!

■ In practice very few people file formal objections.

■ Formal objections are not a showstopper if you can demonstrate that reasonable attempts have been made to accommodate.



Chair's neutrality

From the Role of the Group Chair http://www.w3.org/Guide/chair-roles :

“The ability (both actual and perceived by the Working Group -- including potential competitors) to forge consensus fairly and without bias from your affiliation/employer and, sometimes, even your own technical positions;”

■ Chairs should abstain from casting votes – have someone else from your organization representing your organization if necessary.

■ It may be reasonable for Chairs to take position in case of a tie.



Issues and Resolutions

■ Use Tracker to record issues and keep track of them

■ Anyone can “Raise” an issue but a WG decision is needed to “Open” an issue– Ensure the issue is new and in scope– Encourage people to propose a solution when they raise an issue

■ When a proposal has been made the issue may be marked as “Pending Review”.

■ Review the list of open issues regularly (e.g., on weekly calls)

■ Make sure all resolutions are clearly recorded (use “Resolved: xxx” in IRC)

■ When closing an issue add a link to the resolution from Tracker to the minutes

■ Do NOT reopen unless new information is being brought in.

■ Some WGs prefer using Github which has its advantages but the process should be similar.– Consider using Github issues for minor/editorial issues and Tracker for issues that are to

be resolved by WG.



Enabling remote and asynchronous participation

■ Asynchronous participation and asynchronous decision making takes more time.

■ Most practical way seems to be:1. Make decisions during meeting/call2. Publish minutes highlighting resolutions3. Approve minutes on the next call – effectively confirming the resolutions

■ This allows those who couldn't attend the meeting to object before resolutions are confirmed.



Action Items

■ Use Tracker to record Action items and keep track of them

■ Make sure the person accepts the action item– It is inappropriate and counterproductive to give actions to people without their consent

■ On completion, action owners can mark their actions as “Pending Review”

■ Review action items regularly (e.g., on weekly calls)– Close completed actions– Identify and address possible blocking issues



Developing documents

■ Identify a couple of editors (2 seems optimal)– Ensure they are committed and have the time this requires

■ Ensure WG members are paying attention– For milestones (e.g., FPWD) identify a couple of people who take action items to review

■ When applicable, think about developing a test suite early on– Issue resolutions are great opportunities to add tests– Failing to develop the test suite will lead to delayed CR

Be pro-active, inquires who's going to implement what– If something seems to be lacking support mark it as “At RISK”



Publishing documents

■ Know the W3C publication process and schedule– Documents must be PubRules compliant – don't forget the link checker– Publications only occur on Tuesdays and Thursdays– Beware of blackout periods (e.g., TPAC)– Transition requests can take time, especially when call with W3M is necessary

■ Help new editors with the publication process – failure to fully understand the rules and process invariably leads to delay in publication.

■ Secure participation from your Team contact– They have to participate in the publication process (copy doc to TR space)– They can help smooth things out and avoid unnecessarily delays.



Dealing with comments

Probe the public often– The earlier you deal with feedback the better off you are.– If you know of any stakeholders (groups or individuals) prompt them directly.

Keep track of Last Call “Disposition of comments” using Last Call Tracker or some other tool– Ensure someone (e.g., the editors) is committed to:

1. Sorting out comments,2. Bringing to the WG what needs to be discussed,3. Responding to the public and chase commenters for their acknowledgement,4. Documenting all of the above!

– When answering comments request response by a specific date.– Documented due diligence is key to successful transition requests.



Parting thoughts

There are many things you do not control that can lead to delays:– Fluctuating levels of participation or attention, late issues, public comments, etc.

You can mitigate some of these by being proactive:– Watch out for warnings: people no longer showing up on calls, not responding, etc.– When needed reach out to people directly and seek help from your Team contact.

At the same time there are many things you do have control over:– Keeping the WG focused, running meetings effectively, avoiding repeats, setting

deadlines, etc.

And these can have a big impact so, don't miss out on those!



Reading material

Joseph Reagle's Thoughts from the P3P Harmonization WGhttp://www.w3.org/Guide/reagles-experiences.html

Predicting milestoneshttp://www.w3.org/Guide/predicting-milestones.html

Good Practice for Managing Reviews and Review Commentshttp://www.w3.org/2006/07/comments.html

W3C Chair training Focus & Poductivity 2014102

Education

Transcript of W3C Chair training Focus & Poductivity 2014102