Agility

From W3C Wiki

Raison d'être

This task force is intended to:

  • Improve agility unrelated to W3C Process. In many cases, WGs seem to overly burden themselves with requirements, slowing down work in ways that the process does not require. This could be, for example, by bureaucratically running the WG process - asking for greater consensus at intermediate stages than the process requires. How can we improve agility without changing the process? How do we manage the necessary bureaucracy to the rare defined places where it is needed? How do we train Chairs on this?
  • Define best practices for work modes to enhance agility. For example, publish best practices around Meetings and Workshops work mode using 1) web tools (e.g. WebEx, Moderator, Etherpad) and 2) the Process and a culture for following it - e.g. providing adequate notice for people to attend events. This continues and expands the dialog we started last year. It relates to project 2, but is more narrowly focused.

The graveyard of /TR. It is very challenging, as a user, to understand the current status of specifications - particularly, if a given TR has been superceded, or is in the process of being superceded by current works-in-progress, or if it is a dead end. Something along the lines of the warning on http://tabatkins.github.io/specs/respimg/ would be good; a more dynamically-updatable "status" section for recommendations would be another idea. Based on the findings, the AB will work with the Team to advise on which current efforts are 1) on the road to failure, or 2) on the road to failure unless the team takes action.

The challenge of course is to given that "prediction is very difficult, especially about the future". This task force is charged with gathering information and building consensus on how to do a better job than we have been doing at making such predictions and prescriptions.

Basics of how the project will work

The project will mostly work in public. The AB does reserve the right to have confidential discussions with people who do not want to be identified or quoted in public to make sure we get solid data on controversial topics. The project will involve any volunteer (AB, AC, any W3C participant or invited expert willing to help) The project will suggest any recommendations for best practices before or during AC meeting in May 2015.

Methodology : historical research into poor work mode

Why have some efforts worked around the W3C, and why? How could they have been done within the constraints of the W3C, and how would that have been better or worse?

Initial list of failures to learn from
Strawman Proposals

Milestones

  • Nov 2014 : setup wiki and mailing list, call for participation
  • January 2015/February : identifying hypotheses about what factors lead to good work mode
  • March/April 2015 : summarizing what we learned and presenting a proposal for better work modes
  • May 2015 : Recommendations and action plan

Team members

  • Chris
  • Virginie
  • Chaals
  • Jeff
  • Mike
  • Daniel
  • David
  • Robin
  • Glazou
  • [please add your name here]

Open Issues (for discussion)

  • Should we create a CG to do this?
    • AB: no, reuse public-w3process using a [agility] Subject: prefix
    • CW: preference to NOT reuse process CG, as that group covers a lot of other issues. Requirement to be public, however.
  • Workmode: email? IRC?
    • AB: e-mail is number one preference and very strong preference to just reuse the public-w3process list