See also: IRC log
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
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
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
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.
Steve: The Patent Policy (PP) is not the problem.
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:[End of scribe.perl diagnostic output]