Steve: W3C Process Agility
... specification development sometimes took a long time. Was the Process a problem?
... we got in the order of 27 proposals, filtered down to 12 discussed in May
... I'm here to report on the actions the AB thought appropriate
... We found the Process was not most of the problem
... methods could be implemented within the Process to make things more workable

Proposed Process Changes

Steve: Consider testing early in the process would be appropriate.
... The Process is mostly for new people. To let them know what to think about what it takes to get to REC
... tests are not the only way to show things are interoperable. Showing a feature is implemented in multiple implementations and the bug log on those features is reasonable is another way of demonstrating.
... the HTML WG might use that
... There were a couple of things that seemed to be artificial restrictions that made things more complicated than necessary
... The PR step caused delay and caused confusion with respect to referencing.
... The idea is to clarify that a CR is pretty damn close to REC
... CR is not perfect, but the final tune up to REC is painful and should be less
... painful
... Questions?
... and feedback? Is this adequate?

dbaron: The CSS WG has the tendency bounce in and out of CR a lot
... it seems inconvenient to have the AC vote multiple times at CR

Steve: The proposal is the AC would vote once
... with allowance for a requested vote on re-entry if felt necessary

David Filip: The testing recommendation is vague. I wonder if it should be normatively required?

Steve: what is required is at LC that the WG documents their approach.
... and at CR they establish a plan
... they are at those points not required to have tests
... we want to encourage testing early, but we do not want to require it

Practices for Agility

Steve: A barrier to getting to LC is resolving dependencies with other WGs
... the idea is to identify those during chartering
... FPWDs are perhaps better developed in CGs
... The W3C has four important events: FPWD (initial patent commitment), LC (more patents), CR (is done), REC (actually done)
... We want to focus on those points as they seem to be gating things
... We are working on making Editor Drafts (EDs) more discoverable

David Filip: if someone recharters between LC and something else?

Steve: should not matter
... patents are attached to documents, not the charter

Mike Champion: About making chartering more agile. Using a CG to produce a draft or starting with a SUBMISSION is better. Open ended discussion is painful.

Steve: yes, that would avoid laywering and allow for technical discussion
... documents have multiple audiences
... implementors want latest; reviewers might want latest
... TR/ only gives snapshots; make the EDs more accessible
... by linking them from TR/

Mike Champion: does it matter where they are published?

Steve: The Google/Bing result is terrible for non-TR/ links

dbaron: New engineers at browsers have implemented old versions of a spec

Steve: if you do testing early, you get specifications adopted faster
... specification editors seem to appreciate this more as well as tests help them guide their writing and understanding

<dbaron> Steve shows http://test.csswg.org/annotations/css21/

Steve: The CSS WG has an annotated version of CSS 2.1 that identifies the tests for it
... and allows running to run tests for the browser used
... it has section-by-section information as well
... this is an example of integrating testing
... as well as tests, integrating issues would be good too
... both WebApps and CSS develop small specifications
... modularizing also creates problems
... such as making sure it's coherent

Are Supergroups the Solution or the Problem[?]

Steve: HTML, CSS, and WebApps are supergroups
... patent commitment is made to the WG
... protection is for all IPR of the WG

dbaron: I think the common case is that a Member refuses to grant IPR for a small work item

Steve: A perception is that these groups add work faster than they output it

[The scribe missed something above and therefore what dbaron said does not quite make sense in the context of the minutes. Apologies.]

<dbaron> What Steve said before was talk about small group spinoffs, and mention a motivation being that somebody whose input was important refused to join the supergroup for IPR reasons

Steve: Large groups create problems for AC review and there's a question about whether or not process is being made.

The Impact of the Paten[t] Policy

Steve: The Patent Policy (PP) is not the problem.

What is the AB Missing?

Michael Cooper: I see the case for modularization, but it can be difficult to manage. The PFWG has a large problem with reviewing the incoming work.

Michael Cooper: The PFWG gets blown away by the snowball

Michael Cooper: The more you modularize the more you make it difficult to separate out IPR concerns. The opposite is group spawning, but then you miss having everyone in the same room for closely related specifications.

scribe: The charter has little wiggle room
... The charter is too formal as it's likely to change in response to concerns

Mike Champion: The PP drives these suboptimal things

scribe: making it applicable to a specification rather than WG might make things more tangible

Steve: Maybe supergroups should give some kinds of heads up? [Did I get that right?]

Michael Cooper: We'd need to not miss those LCs then

Steve: I'm trying to see if there's a mechanism that works for both sides. I think it's important for WGs to have interaction with other WGs; either scheduled or unscheduled

Daniel Glazman: The HyperText Coordination Group is mostly useless. It's difficult to find the reasons why, but it does not work well.

Daniel Glazman: Make status reports and participation mandatory

[The scribe thinks that forcing people to do boring things is not going to work.]

Steve: We've been thinking about a notion of dashboards, to coordinate these kind of things

Daniel Glazman: They're not intrusive enough

Daniel Glazman: Email you're almost forced to read

[Scribe actively filters his email...]

Michael Cooper: The audience of who needs reviews needs to be public; important to get public engagement

David Baron: I took something different from what Daniel was saying than what he meant.

David Baron: The HyperText Coordination Groups (HGCs) does not work well because you pass information via liaison and that does not work well

Steve: An advantage of the HCG is that it is tracked

Henri Sivonen: I think one of the bugs with the HCG is that it's Member-confidential

David Baron: I think it's public now

[Multiple people confirm it's public.]

[Secret stuff is being said. I guess you had to be here.]

Steve: The secret stuff is a problem of the past.
... I'd like to thank you all for your time

Michael Cooper: What is going to happen with the output here?

Steve: The AB is represented by three people here and the AC will look at this as well
... it will not on the floor

This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Mike:/Mike Champion:/
Succeeded: s/Coopier/Cooper/
Succeeded: s/liason/liaison/
No ScribeNick specified.  Guessing ScribeNick: annevk
Inferring Scribes: annevk

WARNING: No "Present: ... " found!
Possibly Present: MichaelC_ Steve agile cygri dbaron hsivonen jalvinen jcverdie jeff joined koalie plinss tpacbot
You can indicate people for the Present list like this:
        <dbooth> Present: dbooth jonathan mary
        <dbooth> Present+ amy


WARNING: No meeting title found!
You should specify the meeting title like this:
<dbooth> Meeting: Weekly Baking Club Meeting


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Got date from IRC log name: 31 Oct 2012
Guessing minutes URL: http://www.w3.org/2012/10/31-agile-minutes.html
People with action items: