Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Agenda for Sep 1 meeting #127

Closed
foolip opened this issue Aug 31, 2022 · 1 comment
Closed

Agenda for Sep 1 meeting #127

foolip opened this issue Aug 31, 2022 · 1 comment
Labels
agenda Agenda item for the next meeting

Comments

@foolip
Copy link
Member

foolip commented Aug 31, 2022

Here's the agenda for our meeting tomorrow:


FYIs, not using meeting time:

Previous meeting: #118, plus extra APAC meeting in #126

@foolip foolip added the agenda Agenda item for the next meeting label Aug 31, 2022
@bkardell
Copy link
Contributor

bkardell commented Sep 1, 2022

Minutes

Topic: Charter issues

foolip: There was a meeting the day before yesterday where we talked to folks at apple about some of the issues. A summary is in the agenda. First: We decided we should keep joining/leaving more or less as is - we'll try to make an email address for that to allow private communication as gh isn't always ideal. We can remove by concensus, if for example an organization stops existing. Worst case we can choose a representative to act as something like this
james: Can you not privately do this on gh? what do we do for CoC, for eample
foolip: We named people you can reach out to privately, I'm not aware of a way to do that in gh

foolip: We discussed relationship with working groups - we agreed that this group itself should not be working on new specs and things in this group - if we wnat to do something here we should join the WG, inform them that we want to do that and do that there.

brian: I'm slightly confused, lots of people here do do spec work but they're jsut wearing a different hat at the time

james: I think mainly this deals with IPR concerns, there's no risk that this happens out of sight of the working group, etc. I think it makes sense. If there is already a place or mechanism, we should use that place. If there are interop issues but it is stalled in the WG, we have to take that and try to not circumvent the WG, but do the work there.

foolip: Next steps were that folks at apple were going to discuss internally whether this would work for them. We'll have to wait for that, just seeing if that works for everyone here.

foolip: Next is the question about which things are acceptable requirements for what we work on. James suggested I think that perhaps this doesnt belong in the charter itself.

james: My thinking was that the charter should define the overall scope of the effort - creating metrics and interoperability. It probably shouldn't discuss derived properties of those things - like these ones would be acceptable. The reason for that is that it is really an outcome of the decision making process and keeping them separate allows us to keep 'stuff that could change' apart from the goals. We could have said "we only accept w3c specs at this level of the process" - but the process could change, and then we have to change, and so on. Alternatively, we just have advice about our current thinking and update it - it's not formally part of a charter.

foolip: I like that separation, it doesnt change the discussion we'll have

brian: I agree - it's what I was saying last week. This is ultimately just advice about what to submit or not, but people will in the end submit whatever they submit, including just spam - and we will need to decide.... and if we're not careful we will prevent ourselves from considering very reasonable things without rechartering

foolip: So we have 3 options, basically, about what we say here. Do people feel strongly about this, and what we should do? I should probably note that we can say "we may make exceptions"

james: I think to the goal of documenting what is highly likely to be accepted or not - it makes sense to be clear. If something is in WICG, we probably would not take it up. I think being specific there makes sense. I think the list of things fantasai provided is a good list - there are open and practical questions. I think we have, for example, ecma/test-262. IETF probably doesn't have web platform tests. If you had web sockets, and someone wrote a bunch of tests, we would probably accept that - but the truth is we don't have the best infrastructure for those sorts of things - http/quick. Generally we cover w3c/whatwg - maybe we have a few things that cover a bit of kronos, but they have their own test suites. There's a whole class of things that 'if we had a way to take the tests in WPT or a way to maybe incorporate scores in a single place - it could work. Currently tho it isn't 'norm'.

foolip: Let's talk about ecma/262. I have spent a bit of time looking into this. work was done a few years ago by dpino at Igalia. I was trying to revive that, it seems... reasonable/feasible. I would probably do some things differently. I guess the question is do we want to do it, and can we commit to doing the work if we get proposals that are good enough.

james: I guess plan B would be if we get good proposals and we decide then that we can't get the work done, we do an investigate next year and make it possible for a year later. In principle, I like the idea of being able to run 262 in web platform. I've wanted that for around a decade.

brian: this was initially done a few years ago as a contract for mozilla.

chris h: is the thing we're trying to do here is report the 262 things in WPT? Is that what you wanted for a decade

james: Yes, basically. It is possible that we can find other pracitcal concerns like it takes too long to run the tests

foolip: Yeah, definitely - we would probably want to not run them by default unless they are super fast.

brian: In my experience, they are not... but it is a really big test suite and deep, including things about language support etc that takes a long time. It's possible we don't need all of it either.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
agenda Agenda item for the next meeting
Projects
None yet
Development

No branches or pull requests

2 participants