w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.52k stars 672 forks source link

CSS2 maintenance proposal #2553

Open gsnedders opened 6 years ago

gsnedders commented 6 years ago

CSS2 maintenance proposal

Some background:

Generally, mine and @tantek's proposal is:

I suggest:

We need to:

Open questions:

  1. Should we add scientific notation to CSS 2.1? (#2542)

  2. Syntax section readded despite WG resolution (#2224)

  3. Naming of revision of CSS 2.1 (#2008)

  4. Anchors changed in CSS 2 in-place edit in 2016 (#2551)

  5. Use only [css2] and label:css2 on GitHub? (mv label:css22 -> label:css2, [css22] -> [css2], [css21] -> [css2])

Sketch of the flow described above:

tantek commented 6 years ago

@gsnedders @fantasai and I worked on this effort to restart CSS2.x editing & publishing with a formal but efficient workflow during the current (Berlin) CSSWG meeting and we’re pretty sure we can make this work (@gsnedders helping with the restart, build system, and testing, and initially @fantasai and myself as editors), and it's the most efficient we can do this given goals and current W3C process / patent policy constraints.

This is intended to supersede all decisions/resolutions at the past Seattle f2f where the WG last discussed CSS2.x workflow.

Please take a look at the gist and thumbs-up, or add questions / comments / suggested improvements accordingly. Assuming the WG approves this proposed workflow I’d like to document it in a README in the css2 directory https://github.com/w3c/csswg-drafts/tree/master/css2 so its easily discoverable and we can tweak/iterate as needed while actively using it.

Thanks!

Tantek

cc: @astearns @atanassov

(Originally published at: http://tantek.com/2018/102/t2/)

css-meeting-bot commented 6 years ago

The Working Group just discussed Proposed CSS 2.x editing & publishing workflow, and agreed to the following resolutions:

The full IRC log of that discussion <dael_> Topic: Proposed CSS 2.x editing & publishing workflow
<dael_> github: https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce
<dael_> github: https://github.com/w3c/csswg-drafts/issues/2553
<dael_> tantek: I made a diagram based on discussion with gsnedders at dinner.
<dael_> tantek: Proposal: https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce
<dael_> tantek: We want to swtich to 1 copy of css2. We want to make 2 kinds of changes, one is editorial and the substantive we want them to be informative delta notes.
<dael_> gsnedders: And we can publish them without impl.
<dael_> tantek: And putting notes where people find them. When we go to CR those delta notes we ID as normative at risk unless they're interop and then we merge them in. CR to PR we look at the at-risk delta paragraphs. If they're impl we merge and if they're not merge to notes.
<dael_> tantek: Given that we think we can publish semi-regularly. Perhaps at F2F.
<dael_> tantek: [shows diagram on description]
<gsnedders> https://gist.github.com/gsnedders/e0aab5ca6a8c06cee3bae4afcfd664ce#file-flow-png
<dael_> tantek: Any substantive changes where there's interop and if we don't have it there's not interop we'll go to CR. Once CR period is done we issue the PR. We ID at-risk and they're merged in or they become notes again. When PR closes we do ED.
<dael_> gsnedders: If there's no substantive changes we go straight to ED>
<dael_> florian: So if no change since last time to impl we can cycle ED?
<dael_> tantek: Yes. Only if there are type 1 changes do we seasonally do an ER. If there are type 2 we do a CR.
<dael_> fantasai: I think that's a lot of extra work for no benefit. Our goal is minimize process. If we don't have impl of anything yet and everything is we're hoping for impl there's no reason for CR>
<dael_> tantek: Type 2 edits are agreement from impl to implement.
<dael_> fantasai: But if there's no...if none of the edits can fold into main line text there's no reason to go to CR with at risk notes. They may as well stay as notes.
<dael_> florian: I think that tweak reduces process churn and increases time spec is in ED.
<dael_> tantek: Okay with that. gsnedders ?
<dael_> fantasai: This whole churn is a lot of work for Chris to set up.
<gsnedders> [gsnedders' shrugs]
<dael_> tantek: Reduce # of transition requests makes sense.
<dael_> astearns: So only got to CR once there is at least 1 interop type 2 change.
<dael_> tantek: Reasonable.
<dael_> tantek: So there's a number of steps to start, which gsnedders has started.
<dael_> tantek: gsnedders committed us down to one version. It reflects the 2011 REC. It's a pull request right now.
<dael_> tantek: [reviews the need to do list]
<dael_> tantek: Assuming WG accepts this we'll drop this and build instructions into the read me.
<dael_> florian: The CSS2.1 PR is in the 2011 state?
<dael_> gsnedders: 2016 state. The 2011REC edited in place 2016 state.
<dael_> florian: Are edits between 2011 and 2016 correct?
<dael_> gsnedders: There's a diff. Except the anchors changing it's fine. There's some changes for pub rules and adding warning boxes.
<dael_> florian: Do you want to merge this and then work through things resolved?
<dael_> gsnedders: Yes.
<dael_> florian: SO a temporary set back to the most up to date ER?
<dael_> ChrisL: It's a stablization phase.
<dael_> florian: Current draft contains mix of correct and mix of not correct.
<dael_> gsnedders: We merge now and work our wait through.
<dael_> tantek: And going forward all changes will be PR that require at least two positive reviews so there's a trail.
<dael_> ChrisL: Inc tests for each change?
<dael_> tantek: Test requirement is when want to change delta notes to normative notes.
<dael_> ChrisL: But collecting tests is useful.
<dael_> tantek: Don't need to block on it.
<dael_> ChrisL: No, not block but collect them.
<dael_> tantek: When implentors impl the tests will be there.
<dael_> ChrisL: I suggest you use wpt tests needed tag
<dael_> fantasai: Andinformative notes contain links to test.
<dael_> florian: Are you going from 2016 to corrected 2018 state quickly? If it will take a long time I want to wonder...I don't want to lose good edits for too long.
<dael_> ChrisL: Good edits should be in errata.
<dael_> tantek: We'll continue to like to errata doc, but the goal is to deprecate it.
<dael_> florian: I'm not an editor for CSS2.anything and I made a PR to merge in line-height. That's not in errata. I'm okay with that being pulled back but not if it's 5 years.
<dael_> gsnedders: I have a list of things that weren't made. Things that went through PR should be relatively easy to land if they've been reviewed.
<dael_> tantek: We've IDed open questions that are a minimum to do another CR. Those are listed on the agenda, but it can be done on telecon on github.
<dael_> florian: Yes, think it's fine. If it takes longer then expected that wouldn't be great, but hopefully it won't happen.
<dael_> astearns: Other comments on this process?
<dael_> fantasai: I think it's great.
<dael_> tantek: Which is good because you're starting as a co-editor.
<dael_> fantasai: I could be a former editor. That would be an accurate representation.
<dael_> tantek: Need a second editor. gsnedders isn't paid for it so he's mostly doing tests and build system.
<dael_> fantasai: I'd propose to have it be gsnedders and have me as a former and say a former editor can review changes at same level.
<dael_> astearns: WE've had resolution on different process, we need a resolution to say we're adopting.
<dael_> ChrisL: Can gsnedders document be added to the read me to our own repo?
<dael_> astearns: That is part of the plan.
<dael_> RESOLVED: Accept this new editing process
<dael_> astearns: I can decree this. I decree fantasai as a former editor.
gsnedders commented 6 years ago

We should add something based on the above gist as a README.md in css2/.