[webkit-dev] Proposal for an "intent to" process for web-exposed features

[Ryosuke Niwa]

Thanks for starting this discussion.

On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <fwang at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200226/880e5bba/attachment.htm>