- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Wed, 25 Jun 2008 12:10:28 -0700
- To: www-style@w3.org
Attendees:
Bert Bos
Giorgi Chavchanidze
Arron Eicholz
Elika Etemad (scribe)
Ming Gao
Daniel Glazman (chair)
Melinda Grant
Dave Hyatt
Håkon Wium Lie
Peter Linss
Saloni Mira Rai
Alex Mogilevsky
David Singer
Jason Cranford Teague
Steve Zilles
Summary:
RESOLUTION: Use the wiki to compile table with information about specs:
- brief description
- status of the document (including anticipated next state)
- status of implementations (including expected implementations)
- status of test suite (including expectations)
- issues/blocking items
- reasons why we want this, why it's important
- link to the spec
The table will be here:
<http://csswg.inkedblade.net/planning/charter-2008>
RESOLUTION: Create short list of deliverables for charter, put other items in
a normative scope section. Items in scope section can be worked
on, but not advanced through REC track unless the charter is
amended to list them as a deliverable.
Full minutes below.
===============================================================================
Peter: Any more topics to add to agenda?
<silence>
Charter
-------
Peter: Daniel had a conversation with Chris via email
http://lists.w3.org/Archives/Member/w3c-css-wg/2008AprJun/0307.html
Daniel: We sent proposed charter 10 days ago
Daniel: Main concern about charter is too-long list of deliverables.
Daniel: He's afraid W3C management will choke on this
Daniel: The new Domain Leader thinks the list is too long for the time
frame. Chris agrees.
Daniel: I said that the list was already a difficult compromise
Daniel: And that the WG wants to preserve the ability to work on these items
Daniel: But he doesn't think w3cm will find it acceptable.
<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?
<dsinger> :-)
Daniel: He thinks the first set looks like it can be done
Daniel: He said we should work on an item in the second set only if it can
replace a completed item on the first set
Daniel: And that the last set is unrealistic.
Daniel: 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.
Daniel: Furthermore there are IPR issues.
Daniel: A Member joining the WG accepts patent policies wrt list of
deliverables.
Daniel: That was SteveZ's concern awhile ago
Daniel: A too-long list of deliverables is not encouraging for new members
Daniel: The second big comment about the charter itself is the lack of
explanations for each and every module in the list of deliverables.
Daniel: That list is very meaningful for people who know CSS and are
involved in the CSSWG.
Daniel: But it is not meaningful for w3cm and AC reps who are not involved
in CSS.
Daniel: He proposed adding for each deliverable a brief description, its
current status, status of implementations, status of test suite
Daniel: He insisted a lot on the test suite
Daniel: We should show more and better what is our coverage of tests for a
given spec
Daniel: Finally, what are the positive things and blockers for the spec
Daniel: What are the arguments we could give to w3cm to make them accept
such a deliverable?
Daniel: As I said wrt test suites..
Daniel: The CSS2.1 test suite says it is incomplete and contains a lot of
errors. This is something we have to fix.
Daniel: We have to make all the test suites move forward.
Daniel: I told him that writing complete tests is a huge work, and he
agreed with that.
Daniel: 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
Daniel: I objected that individuals in such a group have no legal
responsibility if they lie or don't do correct tests.
Daniel: He said no, there's a commitment when you join an interest group
and an implementation report written by someone outside the browser
vendor is as valid as one written by the browser vendor
Daniel: Chris would like to see a new section in the new charter that
analyzes the results of the previous charter.
Daniel: What were the successes, what were the failures, what do we need,
what did we lack.
Daniel: 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
* alexmog thinks cutting the list would just be denial. there *is* a lot
of work to be done
Ming: As Elika was saying, a lot of things Chris was suggesting to do,
Elika is planning to do.
Ming: 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
Elika: It doesn't make sense to write tests when the drafts is still in
the brainstorming phase
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.
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.
Daniel: I perfectly understand the rationale of a long list.
Daniel: 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.
howcome: but I don't think it will make us not work on other items
howcome: it will only block us from working on some things
howcome: 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.
Jason: We should work on the high priority items. We shouldn't have to
revise the charter to go back and work on something
Daniel: The charter is supposed to be deliverables, not a list if items we
want to work on
Daniel: 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.
howcome: 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.
howcome: We have different areas of interest.
Daniel: CSSWG is the only WG that is not willing to extend the charter
and work like this
Daniel: 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
Steve: Most other WGs have got RECs already
howcome: Most of which have failed
Peter: What is sounds like Chris is asking for is take everything out of
the deliverables except the first group
Peter: Move everything else to a separate section that says these are in
scope, but not deliverables.
Daniel: No
Daniel: We can move some items (e.g. Transformations, for which we expect
2 implementations in 6 months) to the first group
<plinss> http://www.w3.org/Style/Group/2008/proposed-charter.html
dsinger: Chris asked for a table of information about the specs.
dsinger: That would help: some of these specs are very small
dsinger: If W3cm thinks they are all big specs, then of course they would
be very concerned.
dsinger: I think building that table is critical.
dsinger: We could e.g. merge animations, transforms, and ? into one line
dsinger: it would look like less work
dsinger: although it's the same
dsinger: 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
<fantasai> our wiki is 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?
Melinda: number of pages? number of properties?
Melinda: 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.
Jason: 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...
Peter: who's going to set up the template wiki page?
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
(statuses includes expectations)
issues/blocking items
reasons why we want this, why it's important
link to the spec
<fantasai> 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
Daniel: 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
Peter: leaving it in the scope section, that allows us to do work on them,
but not move them along the REC track
Peter: 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.
ACTION: fantasai make table template
Peter: All advocates need to fill out their module's info
RESOLUTION: Make table with information about specs
RESOLUTION: 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
<RRSAgent> I have made the request to generate http://www.w3.org/2008/06/25-css-minutes.html
<RRSAgent> See http://www.w3.org/2008/06/25-css-irc
Meeting closed.
<fantasai> http://csswg.inkedblade.net/planning/charter-2008
Received on Wednesday, 25 June 2008 19:11:08 UTC