W3C home > Mailing lists > Public > www-style@w3.org > October 2014

[CSSWG] Minutes Sophia-Antipolis F2F 2014-09-10 Part II: New W3C Process

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 15 Oct 2014 14:48:43 -0400
Message-ID: <CADhPm3sJB=EoowQdKoKk0MD4yYL-Z19eGd9CukXa7+o+s6PkHQ@mail.gmail.com>
To: www-style@w3.org
New W3C Process
---------------

  - RESOLVED: Convert all specs to the new W3C Process at the next
      publication at which such a conversion is allowed.

  - plh presented new tooling for publishing WDs. W3C plans to allow
      up to one snapshot per day, and editors will be able to
      publish without W3C staff intervention. There was some
      discussion of how much oversight the CSSWG should have on
      publishing, whether editorial or substantive changes could go
      directly to /TR, etc.

===== FULL MINUTES BELOW ======

New REC-track Process
---------------------

  <plh> https://www.w3.org/wiki/ProcessTransition2014#Impact_on_Working_Groups
  <plh> https://www.w3.org/wiki/ProcessTransition2014#What_is_the_transition_procedure_for_groups.3F

  plh: I am new to this new process.
  plh: We need to get rid of some of the pains between LC and CR.
  plh: The new process does- it gets rid of LC.
  plh: You still have to do review, but in the state of WD - but
       when you're ready you move to LC and subsequently CR.
  plh: You're supposed to get a review of it, and then issue the
       change.
  plh: The expectation is if you want to republish a CR you need to
       get approval and it should occur quickly.
  plh: We did this recently for two of the CSS documents, there are
       some areas that we can streamline but that is the major
       change.
  plh: And it streamlines the dance that you're doing between the LC
       and CR with the directors.

  SteveZ: If you do a change in CR it does trigger the patent
          policy, and only on the delta?

  plh: When should we switch to the new process, it is really up to
       the group?
  plh: Also any documents in CR, you can move to the new process.
  plh: Documents in LC you can not move to the new process.
  fantasai: Do we need to republish to go into the new process?
  plh: That is a good point, you don't want to trigger the patent
       policy review between LC to CR.

  dbaron: We should move all of our documents to the new process as
          soon as possible.
  dbaron: I presume we can resolve right now to do this on all specs.
  chrisl: I propose we do that,
  florian: Will we need to republish for them to be on the new
           process?
  fantasai: We'll need to update the boilerplate.
  TabAtkins: Sure, it's a boilerplate I'll update it

  <dbaron> Proposed resolution: We should convert all specs to the
           new process at the next publication at which such a
           conversion is allowed.
  <chrisl> Even documents in WD have to say in SOTD whether its
           oldstyle or newstyle.

  <glazou> All in favor but two "abstains": yamamoto + Bert
  <glazou> No objections.

  RESOLVED: We should convert all specs to the new process at the
            next publication at which such a conversion is allowed.

  plh: It's not effecting you. It shouldn't be an issue. It is just
       based on a delta.

  glazou: Anything else on the new process?
  plh: We are trying to determine what is "wide review" and we want
       to define that.

New Publishing Process
----------------------

  plh: We can talk about the publishing pipeline that we've been
       working on.
  plh: We're trying to resolve the pain of publishing
  plh: It's a high cost on WD and the W3C directors.
  plh: You can update it as often as you want, and we want to be
       able to do that.
  plh: If publication rules are okay then we'll let it go through
       based on the link sent in by the editor.
  plh: If you try to publish more than one version on the same day,
       then we'll grab the latest one.
  plh: It should be automatic.

  glazou: Are you getting consensus from the WGs?
  plh: We didn't think it was necessary.
  plh: We want to leave this to the groups.
  glazou: If there is a form, do not make it mandatory but also make
          it so that we can have a URL for consensus.
  plh: Also, there will be a way to do an undo.
  plh: It will notify the chairs that a publication occurred.

  plh: With all that, do you want to have a link?
  fantasai: It could just be a general comment box for us to look up
            later.

  glazou: Is it possible for the form to know each Working Group's
          public mailing list?
  TabAtkins: The whole point is to push working drafts constantly.
  TabAtkins: I don't want the public list spammed for every new
             working draft.
  TabAtkins: I don't want the setup to post to the public mailing
             list to be used as an argument to preclude us from
             doing constant publication.

  glazou: I disagree that you should push directly to the WD without
          consensus.
  fantasai: I think we do want to publish faster and allow editors
            to make quicker changes without consensus.
            Shouldn't have to go to telecon to make editorial changes
  glazou: The point of the consensus is that it allows you to review
          complicated information.

  SteveZ: The TR page currently points to the WD and ED.
  plinss: The whole point of this is to get TR up to date so that
          everyone is using the TR pages.
  TabAtkins: I agree with plinss so I only brought this up that we
             shouldn't need this going to the mailing list.
  hober: I agree that editorial changes should be published easily,
         but there have been examples that are controversial.
  hober: We should treat our editors as adults, we have the Undo
         button.

  glazou: Who can push the undo button?
  plh: The chairs and team contacts can press the undo button.

  SteveZ: There are two audiences for these documents. Implementors
          and Authors.

  plh: Some groups will be updating the WD more frequently.
  fantasai: My ideal mode of operating is that there is a
            history chain of changes.
  fantasai: Those snapshots are chained to discussions from the WG.
  fantasai: The TR page is the thing that EVERYONE uses to look at.
  fantasai: I'd like it so that every change that's not in the
            process of being edited gets to the TR page as soon as
            possible.
  fantasai: Any edits to keep that up to date, that level of up to
            date-ness will be possible with the new process.
  fantasai: The only things that are not going to TR are the things
            that we are working out technical details on the mailing
            list.

  glazou: I still want consensus on publications of substantiative
          changes to publish a WD (non-editorial stuff).
  <glazou> I don't want to see WD updated every day
  plinss: I think this will need to be done on a spec by spec basis;
          based on the maturity of specs.
  TabAtkins: My issue is that editors push all the time to EDs that
             implementors and authors looking at.
  plinss: I agree with most of what you say.
  plinss: If you can publish under TR more quickly you can use the
          ED as a scratchpad and the TR can be the one people look
          at.
  plinss: I think for your issue with remembering to send emails to
          publish we should offer tooling.
  TabAtkins: I will send about 12 emails per day then.
  plinss: We just need to have it noted, it can be on a twitter
          account or email list, it doesn't have to be on www-style.

  fantasai: It's creating the ability to create a little bit of a
            break here as I leave things partially done in the ED
  fantasai: I don't filter on EDs.
  plinss: That sounds fine, have the back and forth on the ED and
          then publish to WD.

  SteveZ: You've now added the work to all of us.
  TabAtkins: No I have not. You can still just review once a year.
  SteveZ: The people that have dependencies aren't looking at the ED.
  fantasai: That's not true.
  fantasai: If it's the thing you should look at, it should be the
            thing that the W3C says you should look at.

  dbaron: What is the end conclusion we're looking for here?
  dbaron: Were there some changes to what PLH stated?
  TabAtkins: No, we're ironing out some of the details on that now
             based on the auto-publish feature.
  plh: There will be a checkbox for checking whether a draft has
       large changes.
  plh: The system was designed to trust individuals, and I don't
       want it to decide what the WG's should do.
  plh: It is designed to allow groups to publish daily.

  astearns: I have a strong desire to trust the editors will publish
            WD appropriately and not add WG process until we
            actually have an issue.
  plh: If there are issues down the road there are steps that we can
       take, but we don't want to solve a problem that hasn't
       occurred yet.
  glazou: Section 7.3.2 of new process says "a Working Group must
          record the group's decision to request publication".
  glenn: This is a change, this making a WD without consensus.
  TabAtkins: If you think this is a change you're not following
             along today, we have everyone looking at the ED.
  fantasai: I think it is very important that people that go to the
            WD and it be the latest.
  fantasai: I want all consensus and approval done through the same
            system.

  SteveZ: The status section should be updated in all WD.
  florian: Are you suggesting having WDs and having a WD that states
           it has consensus?
  fantasai: Yes, we can even have the color change, etc
  plinss: We can even have links (Latest Working Draft, Latest
          Consensus Draft)

  plh: Two points I'd like to make:
  plh: It does not make the decision for the group.
  plh: We still have a nightly draft link, but we are not going to
       copy the editors draft into the TR space.
  plinss: We should still retain the editors draft.
  plh: It will not go away.
  plinss: That then makes the ED become a scratch space.
  fantasai: I've had implementors reference my editors drafts when
            I'm trying to figure something out. It's a problem.

  glenn: My issue is that you're trying to re-label this as a
         Working Draft but it is an editors draft. It should be a
         group process output.
  glenn: I have a real problem with that. If you call it a
         Non-Consensus Working Draft then I'm fine with it.
  SteveZ: There is a presumption of working draft.
  TabAtkins: You're arguing the definition of working draft.
  SteveZ: Come up with the name that means Editor's Working Draft.
  zcorpan: We are actually arguing about the URL more than the name
           since TabAtkins doesn't care.
  zcorpan: So why don't we leave the names as-is and just fix the
           URL so the editor's draft is on TR?
  plinss: We have our own tooling with bikeshed, we can make an ED
          published and then with consensus this can be updated. We
          can add additional tooling to make this easy and make the
          output result very clear to what we're doing.
  fantasai: Part of the update, was to allow the groups to practice
            and experiment with their own process.

  plinss: When will this tooling be available?
  plh: Between TPAC and 2015.
  plh: We will be testing between TPAC and 2015.
Received on Wednesday, 15 October 2014 18:49:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:25 UTC