- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Feb 2024 23:00:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `republishing Grid and Flex`, and agreed to the following: * `RESOLVED: Change CRD requirement for tests from MUST to SHOULD` * `RESOLVED: Republish CRD of grid/flex after fantasai's audit` * `ACTION: emilio to file an issue about improving automation to comment on the issues` <details><summary>The full IRC log of that discussion</summary> <astearns> topic: republishing Grid and Flex<br> <emilio> github: https://github.com/w3c/csswg-drafts/issues/6900<br> <emilio> fantasai: grid specs have not been published in 4y, flexbox even more (2018)<br> <emilio> ... from a process perspective this is pretty bad<br> <emilio> ... means that our official spec is massively out of date<br> <emilio> ... it'd be great to get to a point where the folks looking at drafts is us while we discuss recent changes and get them published<br> <emilio> ... we need to review the changes and tests, and write the tests necessary to make sure that every change has a test<br> <fantasai> s/drafts/editors drafts/<br> <fantasai> s/the folks/the only folks/<br> <emilio> ... we can wait for me and tab to do that which will probably take a while<br> <emilio> ... we can assign someone else which was supposed to happen but didn't<br> <emilio> ... or we can re-publish without the test-case requirement<br> <florian> q+<br> <emilio> ... we can block the CR on having tests, but at least TR will be up-to-date<br> <astearns> ack florian<br> <fantasai> s/CR/CRS/<br> <emilio> florian: I think we should republish at this. This is a lot of work for specs that I edit, and I do it for very simple specs<br> <fantasai> s/very/comparatively/<br> <emilio> ... for these it's a lot of work<br> <emilio> ... the test requirement is not a process requirement, it's a working-group requirement<br> <florian> q+<br> <astearns> ack florian<br> <emilio> astearns: I'm willing to make an exception for this publication, but I think I still like the idea of requiring tests for post-CR changes<br> <emilio> TabAtkins: evidence suggests the rule is not being followed<br> <emilio> florian: we _might_ have tests, part of the issue is that we don't have a way to map the tests to the section of the spec they test<br> <emilio> iank_: there's a link to the spec<br> <emilio> florian: it takes me more time to figure out what the test is testing that everything else<br> <emilio> rachelandrew: I agree, it's a hell of a job, takes a lot of time to go through them, very grateful for people that put notes on what the test is testing<br> <emilio> q+<br> <iank_> q+<br> <emilio> florian: whether of not we change the culture of testing or requiring more documentation<br> <fantasai> ^rachelandrew: can take 30-45 minutes per test to even figure out what it's testing<br> <emilio> ... as it is right now, finding what tests are testing is a lot of work<br> <astearns> ack emilio<br> <emilio> ... for comparatively small specs it's manageable, for big complex specs is not<br> <fantasai> emilio: We have a lint that guarantees every test in CSS directory has a link to the spec<br> <fantasai> emilio: but you can drop a link to the spec, and not to the relevant section<br> <fantasai> emilio: we could be more strict about what acceptable links are<br> <astearns> q+<br> <fantasai> emilio: or maybe require an assert metatag or title tag to explain what it's doing<br> <fantasai> emilio: not to object to this publication, we should not have 6-year-old specs on /TR<br> <fantasai> emilio: but if it saves editors time, it is true when I write tests, the only thing I want is to get the test to work wrt the patch i am writing<br> <fantasai> emilio: I land the tests to move on<br> <fantasai> emilio: but more than happy to add spec link, can also write more words to help the editors figure out what the test is testing<br> <fantasai> emilio: generally I try to both spec and bug link when I write tests, so it can be easy to follow the link<br> <fantasai> emilio: but maybe we should require a little bit of description<br> <astearns> ack iank_<br> <emilio> iank_: one thing I want to point out is that it's likely that implementors don't really care there's duplicate tests<br> <emilio> ... adding a test is less effort than finding an existing test<br> <astearns> ack fantasai<br> <emilio> astearns: proposal: for specs in CR+ to not /merge/ a change without a test<br> <florian> q+<br> <emilio> TabAtkins: no way, that'd slowdown working on CR specs a lot<br> <astearns> ack astearns<br> <emilio> astearns: maybe the slowdown is less at the time you're making the change than finding all of WPT afterwards<br> <emilio> dbaron: let me take one step back<br> <emilio> ... one of the motivations is that there should be a moderately high bar to change specs that are in CR<br> <emilio> ... because they're implemented etc<br> <emilio> ... a lot of the discussion has gone around finding through tests<br> <emilio> ... the alternative workflow is, when we have a post CR check, we make sure that we have links from the PR to the browser bugs<br> <emilio> ... and those bugs should end up having tests<br> <emilio> ... there's a different case which is changing a CR to reflect implementations<br> <emilio> ... a potential way forward would be to split CR changes in two:<br> <emilio> ... * changes that reflect what is already implemented: try to get the test checked in when the change is<br> <emilio> ... * changes that require implementation changes: Make sure that implementation bugs are linked from the issue, then finding the tests is trivial by looking at impl bugs<br> <emilio> q+<br> <emilio> ... I think that makes the problem a bit simpler<br> <emilio> ack dbaron<br> <astearns> ack florian<br> <emilio> florian: one thing that bothers me (searching tests / writing tests / linking) is always work for the same people<br> <emilio> ... the idea that other people would do that doesn't happen in practice<br> <astearns> ack emilio<br> <emilio> ... if it's more work they have to do then that's great if they have infinite time but they do not<br> <emilio> ... so maybe the rest of the WG has to step up and maintain more specs<br> <astearns> +1 to more editors to spread out the work<br> <emilio> ... or we require the editors to do that and recognize that they would edit fewer things<br> <castastrophe> q+<br> <fantasai> [the fork above was, if there's a total amount of work that's more, dumping them on overworked people doens't work, so either the rest of the WG needs to help with the testing stuff or needs to take on more editing stuff or more stuff gets dropped on the floor]<br> <fantasai> emilio: at least Chromium and Gecko have automation to track WG resolutions that link back to the original issue<br> <fantasai> emilio: that helps make sure that the resolutions get linked to browser bugs<br> <fantasai> emilio: we do the work of triaging and opening bugs as needed already<br> <fantasai> emilio: maybe could use that as a way to figure out the lins<br> <fantasai> emilio: I don't think filing browser bugs in every issue tracker should be responsibility of Elika and Tab<br> <fantasai> emilio: we already have a bot to track the resolutions<br> <florian> s/to step up and maintain more specs/to step up and help with the extra steps we require<br> <fantasai> emilio: we could make more explicit where the browser bugs are, or maybe our bot could comment directly in the issue or something<br> <fantasai> emilio: WHATWG/HTML require when you open a PR to have implementation bugs and link from the description<br> <florian> s/and recognize that they would edit fewer things/and recognize that they would edit fewer things and then the WG needs to step up and edit more things<br> <fantasai> emilio: I think that's reasonable compromise, especially if Elika and Tab don't have to do it<br> <fantasai> emilio: I agree with dbaron that finding tests would be easier if we go through implementation bug reports<br> <fantasai> emilio: let's discuss what we can do to help editors<br> <fantasai> emilio: obviously more editors, but, besides that<br> <astearns> ack dbaron<br> <florian> q+<br> <fantasai> dbaron: basically just that, we should revise the bots that we use so that they comment back on CSSWG issue to point to the relevant browser issues<br> <fantasai> astearns: people could remove the Needs Testcase tags once there's tests checkd in<br> <florian> fantasai: we have "needs test case" as well as "tested" labels<br> <fantasai> castastrophe: I wonder if we have a backlog, if we can breakdown what the backlog is and request funding for temporary contractors?<br> <fantasai> florian: I've done it on some specs as a contractor, but not those specs<br> <emilio> fantasai: proposal is to drop the tests for CRD, but keep it for CRS<br> <emilio> emilio: CRD?<br> <emilio> fantasai: CR Draft doesn't have the checks for the patent policy etc... lots of stuff is checked for CRS<br> <emilio> ... we could fork that and at least that way<br> <emilio> ... not great that we haven't published a snapshot in 6 years but better than not publishing a draft in 6 years<br> <fantasai> s/patent policy etc/wide review, addressing FOs, etc, and also has full patent protection/<br> <emilio> astearns: so proposal is changing the requirement for CRD to _should_ have tests<br> <emilio> astearns: objection?<br> <emilio> dbaron: as long as it's clear that CRS keep that requirement<br> <dbaron> dbaron: relative to the previous CR or CRS<br> <emilio> RESOLVED: Change CRD requirement for tests from MUST to SHOULD<br> <emilio> fantasai: have to do some cross-checking that they're all in sync and prepare grid/flex for publication<br> <emilio> ... not ready today but can audit and bring back to the wg<br> <emilio> RESOLVED: Republish CRD of grid/flex after fantasai's audit<br> <florian> q+<br> <astearns> ack castastrophe<br> <oriol> q+<br> <emilio> ACTION: emilio to file an issue about improving automation to comment on the issues<br> <astearns> ack florian<br> <emilio> florian: q about automation<br> <emilio> ... we'd generate a link from GH to browser bugs<br> <fantasai> ... could we also add the has tests label if the browser bug closes?<br> <fantasai> emilio: could maybe do<br> <fantasai> dbaron: [suggests some automatic stufff]<br> <matthieud> q+<br> <astearns> ack oriol<br> <dbaron> Step 1 is making sure browser bugs are linked from the CSSWG issue. Step 2 is linking that to the automation that ties those browser bugs to WPT PRs -- probably commenting on CSSWG issue when WPT PRs are created and maybe changing labels when they're merged.<br> <emilio> oriol: I wanted to comment on automation, sometimes I did create it, pointed out to the spec, and nobody implemented it in the issue but was fixed somewhere else<br> <emilio> ... like a year later somebody comes around but that link is lost<br> <astearns> ack matthieud<br> <emilio> ... we should make sure that the issues created by these bots are not closed blindly but have the right references to what fixed it<br> <emilio> matthieud: can't the test be written when the change is made?<br> <emilio> florian: Ideally yes but can be a lot of work for the editor<br> <fantasai> emilio: everyone agrees that having tests ready with the spec change, and even fixing existing tests, would be great<br> <fantasai> emilio: but that's a lot of work for the editors<br> <fantasai> emilio: as an implementer, when you fix the behavior, it's easy to see which tests need to be fixed<br> <fantasai> emilio: or if tests need to be added<br> <fantasai> emilio: so in practice -- and especially since Tab and Elika do 50% of spec editing -- it's not practical for the editors to do all the testing work for the spec changes<br> <fantasai> emilio: we want to reduce the workload for publishing<br> <castastrophe> a half-joking suggestion that we train an ML model to write and review tests :wink:<br> <fantasai> emilio: the linking work here will help implementers, too<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6900#issuecomment-1939750687 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 12 February 2024 23:00:41 UTC