Version 2 (modified by 4 years ago) ( diff ) | ,
---|
Standards Position Discussion
by Tess O'Connor (@hober), Apple Slide Deck
Let’s figure out how the WebKit community can come to consensus on web standards and communicate that consensus to the world & our colleagues from the other engines.
hober: Coming to consensus and communicating that consensus externally
hober: Right now, folks ask the community for positions on webkit-dev because there is no other place to ask
hober: We should publish our positions on webkit.org
hober: jond has a prototype, similar to Mozilla's standard's positions
hober: Difference is that Mozilla is a single organization, but WebKit is multiple organizations, how do we come to consensus, and what happens if we cannot come to consensus?
hober: Let's keep the process as light-weight as possible
hober: We should create a new GitHub repository under WebKit, folks can request a position by filing an issue
hober: Community can come to a consensus and make comments on the issue
Questions & Comments
noam: Can we have this a year ago?
sam: Paragraph lines in the json is a problem with Mozilla, would probably be a problem for us too
hober: There is pressure to keep it short, maybe we should use a different backing store
smfr: Maybe link back to the GitHub issue?
Eric Carlson: You skipped over what happens if we can't come to a consensus
hober: We want to introduce as little process, not trying to describe a solution to that beforehand.
rniwa: I think we've come to consensus about most of those requests, but how do we know that? How do we know enough time has passed for folks to comment?
hober: We need to wait long enough, can also re-open issues if they're closed pre-maturely. People need to show up to have a conversation, none of this is set in stone
hober: These wouldn't be unchangeable positions, ones that are issued can be revised
rniwa: Email to say "we have reached a consensus, please comment within the next 5 business days to object"
hober: Would make a lot of sense to do something like that
John Wilander: Differentiating between standard and doing something
hober: Differentiating between published standards, things being worked on by one individual or one organization
rniwa: How do we handle when a standard substantially changes and our position changes
hober: Communicating is easy, noticing might be hard. Answering that question probably requires vigilance
rniwa: Maybe specify a date when the review happened
noam: Will this be connected to MDN/can I use?
hober: Existing feature status page is a source of information, but I don't think it makes sense sense to link to MDN
Jen Simmons: Seems like developers won't really use standards positions or find them relevant
noam: it has "under consideration" which has link to somewhere where it is considered
hober: We do have under consideration on our status page
rniwa: Concerned about unhelpful noise from developers
hober: Inclined not to worry about this at the beginning
smfr: Is it a non-goal to prepare for the scenario where different ports have different opinions?
hober: Let's worry about that when we get to it
hober: Maybe should reflect a per-port stance on the feature page?