See also: IRC log
<scribe> ScribeNick: fantasai
Peter: Any more topics to add to agenda?
Peter: Daniel had a conversation with Chris via email
Daniel: We sent proposed charter 10 days ago
Daniel: Main concern about
charter is too-long list of deliverables.
... He's afraid W3C management will choke on this
... The new Domain Leader thinks the list is too long for the time frame. Chris agrees.
... I said that the list was already a difficult compromise
... And that the WG wants to preserve the ability to work on these items
<dsinger> would it look better if we split into N working groups, each with a reasonable length list, and we all joined all the groups?
Daniel: But he doesn't think w3cm will find it acceptable.
Daniel: It looks like the first
set looks like it can be done
... He said we should work on an item in the second set only if it can replace a completed item on the first set
... And that the last set is unrealistic.
... Chris said that it is a lot of work for the documents, first. And there is a lot of work to do on the test suites as well.
... Furthermore there are IPR issues.
... A Member joining the WG accepts patent policies wrt list of deliverables.
... That was SteveZ's concern awhile ago
... A too-long list of deliverables is not encouraging for new members
... The second big comment about the charter itself is the lack of explanations for each and every module in the list of deliverables.
... That list is very meaningful for people who know CSS and are involved in the CSSWG.
... But it is not meaningful for w3cm and AC reps who are not involved in CSS.
... He proposed adding for each deliverable a brief description, its current status, status of implementations, status of test suite
... He insisted a lot on the test suite
... We should show more and better what is our coverage of tests for a given spec
... Finally, what are the positive things and blockers for the spec
... What are the arguments we could give to w3cm to make them accept such a deliverable?
... As I said wrt test suites..
... The CSS2.1 test suite says it is incomplete and contains a lot of errors. This is something we have to fix.
... We have to make all the test suites move forward.
... I told him that writing complete tests is a huge work, and he agreed with that.
... Since we don't have a lot of resources in the WG, Chris suggested creating an Interest Group who could help with reviewing of tests and running the implementation against the test to produce implementation reports
... I objected that individuals in such a group have no legal responsibility if they lie or don't do correct tests.
... He said no, there's a commitment when you join an interest group and an implementation report written by someone outside the browse vendor is as valid as one written by the browser vendor
... Chris would like to see a new section in the new charter that analyzes the results of the previous charter.
... What were the successes, what were the failures, what do we need, what did we lack.
... Last point is minor, we probably need liaison with WebAPI or whatever it's called now because of Selectors API
fantasai: We're sort of doing the Interest Group thing already, informally, on public-css-testsuite
Daniel: an Interest Group is more formal legally, and asks for more commitment
Ming: As Elika was saying, a lot
of things Chris was suggesting to do, Elika is planning to
... We should look at what we're doing, e.g. wrt the review process, and if that is not adequate we can create a group
Daniel: We should start writing test suites when we start writing the spec
Melinda: It makes more sense to start writing tests around when implementations are starting to happen
Daniel: I can see a lot of cases when a browser vendor won't say when they're starting to work on an implementation for competitive reasons
Melinda: We might not always be able to identify that point in time, but I think that's the point we're looking for.
Daniel: We should start writing tests when we feel the spec is starting to stabilize.
Elika: (earlier on) It doesn't make sense to write tests when the drafts is still in the brainstorming phase
Melinda: I don't think this group has a realistic plan for the CSS2.1 test suite
Daniel: So the charter needs more
work. We need to spend more time discussing the proposed list
... I perfectly understand the rationale of a long list.
... But if the result is a rejection by w3cm, then that won't work.
<dsinger> but we can't control what people actually spend their time on
Peter: My concern is what do you define as popping off the stack? Getting to REC? Or not having much to do on it for a few months?
Daniel: Probably the latter. The w3cm's concern is resources.
Peter: I thought that was already our intent.
howcome: I can see the rationale
for wanting to cut back because we want to finish.
... but I don't think it will make us not work on other items
... it will only block us from working on some things
... I don't think we're going to work any faster by cutting down the list.
Jason: I agree. I think it comes
back to prioritizing.
... We should work on the high priority items. We shouldn't have to revise the charter to go back and work on soemthing
Daniel: The charter is supposed
to be deliverables, not a list if items we want to work
... If an item is on a wait list, then that item's chance for success is already questionable.
howcome: We have different
opinions on what a charter is.
... I think a charter defines the scope of our work, and if it it has a list of deliverables too, fine.
Daniel: I'm not saying my POV, I'm speaking for management
Steve: The charter is two things, it's what's in scope and what you commit to get done.
howcome: I think the charter should say that we want to be able to work in all these areas
Daniel: Then we put the list in an informative section listing what we might work on, and say that the charter may be extended to include these later
howcome: I think that's too much overhead
Melinda: I don't think the list of things in scope and deliverables need to be one and the same
Steve: Reviewing a one line addition to the charter is pretty quick and straightforward
howcome: I don't think it's that
we have X amount of resources that we can point at the pool of
... We have different areas of interest.
Daniel: CSSWG is the only WG that
is not willing to extend the charter and work like this
... Other working groups accept to have a short list of deliverables and extend the charter to work on other things
howcome: We split our spec up. HTML5 is one item, but it's as big as all CSS3 modules put together
Steve: CSSWG has a bad reputation
for not being able to finish anything. I'm not saying it's
deserved, but you can see which specs got to REC and ours
... Most other WGs have got RECs already
howcome: Most of which have failed
Peter: What is sounds like Chris
is askin for is take everything out of the deliverables except
the first group
... Move everything else to a separate section that says these are in scope, but not deliverables.
... We can move some items (e.g. Transformations, for which we expect 2 implementations in 6 months) to the first group
dsinger: Chris asked for a table
of information about the specs.
... That would help: some of these specs are very small
... If W3cm thinks they are all big specs, then of course they would be very concerned.
... I think building that table is critical.
... We could e.g. merge animations, transforms, and ? into one line
... it would look like less work
... although it's the same
... the thing to consider is, how big is this spec, and how much work do we expect it to be?
Peter: Who's going to create this table?
dsinger: wiki the list and have everyone fill in the parts they care about
wiki at http://csswg.inkedblade.net/
Peter: That wiki is public
fantasai: the charter's going to be public
Melinda: What are the metrics
we're looking at for the specs?
... number of pages? number of properties?
... If we want to assess the amount of work, what do we look at?
Daniel: One thing w3cm wants is a measure of how big the test suite will be
Melinda: Many tests won't be at a point where we can count test assertions
Jason: When we do req docs, we
give a "level of effort" score.
... Would we want to give a scale?
<dsinger> yes, small/medium/large on the spec. and the test suite would seem to be enough
Peter: I think we should do it in prose
Peter: This is a large effort, it will take many man-years. This is a small effort it will take a few months.
<dsinger> the test suite is a few dozens of tests, the test suite is many hundred or thousands of tests...
fantasai: I can do that, I just need a clear idea as what blanks need to be there.
Items for each record:
status of the document
(including anticipated next state of document)
status of implementations
status of test suite
(status includes expectations)
reasons why we want this, why it's important
link to the spec
is a good starting point
<dsinger> is the spec. small/large, is the test suite small/large?
Daniel: This solves the problem
of information about the documents
... What do we do about the list of deliverables?
<dsinger> my bet is that this exercise will do some thinning...
Peter: Do we move the rest of the items to an informative section? Move it to the scope section?
Steve: Keep it normative, move it to scope section
Peter: We move things from scope
to charter as charter revisions when something needs to move
through REC track
... leaving it in the scope section, that allows us to do work on them, but not move them along the REC track
... We shouldn't have to update the charter to let someone work on an editor's draft
Daniel: I think working on an editor's draft is not a problem. FPWD is an issue
Peter: In order to the move something along the REC track, we'll send a note to the AC asking to shift the line from the Scope to the Deliverables section
Melinda and howcome have concerns about items getting stuck and not moving, esp Paged Media and Multicol
Peter: Those groups are not set in stone. Once we fill out the table, we can shift items around.
<scribe> ACTION: fantasai make table template [recorded in http://www.w3.org/2008/06/25-css-minutes.html#action01]
<trackbot> Created ACTION-70 - Make table template [on Elika Etemad - due 2008-07-02].
Peter: All advocates need to fill out their module's info
table with information about specs
... Create short list of deliverables, put other items in a normative scope section
Peter: I like the idea of an interest group for test suites, everyone give some thought to that
<dsinger> thanks, bye
<glazou> hyatt: sorry we did not have time for variables but the charter discussion was urgent
RRSAgent: make logs public
RRSAgent: make minutes
This is scribe.perl Revision: 1.133 of Date: 2008/01/18 18:48:51 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/He/It/ Succeeded: s/the previous charter/the results of the previous charter/ Succeeded: s/is very committed to/has a realistic plan for/ Found ScribeNick: fantasai Inferring Scribes: fantasai Default Present: +1.408.398.aaaa, +1.760.741.aacc, +1.281.419.aadd, plinss, Bert, hyatt, +1.858.655.aaee, Melinda_Grant, dsinger, George, +1.703.265.aaff, glazou, Ming, jason_cranfordtea, SteveZ, SaloniR, +1.510.981.aagg, fantasai Present: +1.408.398.aaaa +1.760.741.aacc +1.281.419.aadd plinss Bert hyatt +1.858.655.aaee Melinda_Grant dsinger George +1.703.265.aaff glazou Ming jason_cranfordtea SteveZ SaloniR +1.510.981.aagg fantasai 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: 25 Jun 2008 Guessing minutes URL: http://www.w3.org/2008/06/25-css-minutes.html People with action items: fantasai WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]