Thanks for starting this discussion. On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <fw...@igalia.com> wrote:
> > The idea of an "intent to" process has been raised several times in the > past (e.g. in our 2020 goals [1]) and some people already use it > informally, but it does not seem that we have any agreement right now. Such > a process would help to coordinate changes internally (between port > maintainers and contributors) and externally (with standard groups, users > and other implementers). For the former point, see [2][3][4] for examples > of how coordination is not smooth right now. The latter point will give a > better understanding of what's happening in WebKit and help web developer > advocacy. > Having some kind of a process to announce a new Web facing API or behavior change is a good idea. In fact, we technically still have such a process although nobody seems to be using these days: https://trac.webkit.org/wiki/AddingFeatures The Mozilla and Chromium projects have their own process [5] [6]. We can > probably start with minimal rules and refine them in the future. We can > even make it mandatory only for new web platform features developed under > a runtime preference for now (i.e. excluding small features for which > it's not worth introducing a flag, behavior changes or deprecation/removal). > Below is a proposal based on Mozilla's one. > WebKit tends to err on the side of simpler rules so let's stick with that. I don't think we need an email template for example (I hate templates; all those intent to X emails on other engines' mailing lists look so silly). 1. Email webkit-dev with an intent to prototype. > I really dislike the idea of putting features into different stages like prototyping, etc... I'd prefer a much simpler approach in which a new feature or any behavior chance being worked on is announced on webkit-dev. In fact, I don't think we should have any rule about how emails are titled, etc... Emails just need to contain a certain set of information we need to evaluate whether a given feature / behavior change is good or not. Rather, what we need a guidance on is at which point something becomes a feature or a behavior change significant enough that an announcement on webkit-dev is necessary. For example, one could argue that any bug fix in Web facing API will affect its behavior. However, I don't think we want to be tracking every one of those behavior changes in WebKit on webkit-dev. Similarly, adding a new API has multitude of scales. On one hand, there is ResizeObserver and there is adding pointerLockElement on ShadowRoot <https://trac.webkit.org/changeset/209648/webkit>. At which point, should we be making webkit-dev announcement. Again, I don't think we want to be tracking the addition of every new DOM property, JS API, etc... on webkit-dev. 2. Implement the feature normally behind a off-by-default preference. > This is not a preference, it's a WebKit policy: https://webkit.org/feature-policy/ 3. Email webkit-dev with an intent to ship. > I don't think this makes much sense in WebKit since there is no such a thing as shipping in WebKit. Each port maintainers decide which set of features will be enabled at when. Or do you mean that we enabling new feature / behavior by default? If so, then making such an announcement on webkit-dev requirement for Web facing feature / behavior change makes sense to me. But we should never use term such as "shipping". 4. If there's no negative feedback, ship (ports maintainer can still > disable the feature if they want to). > We should probably adopt the same 5 business day policy here. II/ Intent to prototype template > I don't think a template is necessary. We don't have a template for nominating reviewer, committer, etc... We should just have a list of topics / details / information each email should contain. We should probably have: - Summary of new feature / behavior change - Bug URL - Spec URL / PR / Issue - Status in other browsers I really don't think links to the related emails on webkit-dev, etc... is necessary because anyone interested in a given feature / behavior change will surely check the bug, etc... On the other hand, we should probably also create a way to track all these new features and behavior changes in some central place. For new Web facing features, we have: https://webkit.org/status/ We should probably create some other page / tracking tool where all behavior changes to existing Web APIs are tracked. And updating of https://webkit.org/status/ as well as this new tracking tool should probably a part of the requirement of adding a new feature / making a Web facing behavioral change. - R. Niwa
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev