W3C home > Mailing lists > Public > www-style@w3.org > June 2008

[CSSWG] Minutes and Resolutions 2008-06-25

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 25 Jun 2008 12:10:28 -0700
Message-ID: <48629824.1000103@inkedblade.net>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:07 GMT