W3C

- DRAFT -

SV_MEETING_TITLE

25 Jun 2008

See also: IRC log

Attendees

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
Regrets
Chair
SV_MEETING_CHAIR
Scribe
fantasai

Contents


 

 

<scribe> ScribeNick: fantasai

Peter: Any more topics to add to agenda?

<silence>

Charter

Peter: Daniel had a conversation with Chris via email

Daniel: We sent proposed charter 10 days ago

http://lists.w3.org/Archives/Member/w3c-css-wg/2008AprJun/0307.html

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.

<dsinger> :-)

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 do.
... 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 of deliverables.
... 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 on
... 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 work.
... 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 didn't
... 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.

Daniel: No
... We can move some items (e.g. Transformations, for which we expect 2 implementations in 6 months) to the first group

<Bert> http://www.w3.org/Style/Group/2008/draft-charter2.html

<plinss> http://www.w3.org/Style/Group/2008/proposed-charter.html

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

<dsinger> agree

Peter: This is a large effort, it will take many man-years. This is a small effort it will take a few months.

<glazou> agreed

<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:

brief description

status of the document

(including anticipated next state of document)

status of implementations

status of test suite

(status includes expectations)

issues/blocking items

reasons why we want this, why it's important

link to the spec

http://www.w3.org/Style/CSS/current-work

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

RESOLUTION: Make 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

Summary of Action Items

[NEW] ACTION: fantasai make table template [recorded in http://www.w3.org/2008/06/25-css-minutes.html#action01]
 
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/06/25 18:00:14 $

Scribe.perl diagnostic output

[Delete this section before finalizing the 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]