Proposal for an "intent to" process for web-exposed features

# Frédéric Wang (5 days ago)

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.

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.

WDYT?

Frédéric, on behalf of Igalia's web platform team

[1] trac.webkit.org/wiki/WebKitGoalsfor2020 [2] Behavior change: bugs.webkit.org/show_bug.cgi?id=201641#c49 [3] Deprecation/Removal: bugs.webkit.org/show_bug.cgi?id=204125#c7 [4] New feature: bugs.webkit.org/show_bug.cgi?id=157743landed in April 2019 and only enabled in bugs.webkit.org/show_bug.cgi?id=203644 [5] wiki.mozilla.org/ExposureGuidelines [6] www.chromium.org/blink/launching-features


I/ General process

  1. Email webkit-dev with an intent to prototype.
  2. Implement the feature normally behind a off-by-default preference.
  3. Email webkit-dev with an intent to ship.
  4. If there's no negative feedback, ship (ports maintainer can still disable the feature if they want to).

II/ Intent to prototype template

Subject: Intent to prototype: <your feature goes here>

Summary: Elevator pitch for the new functionality. Bug: Link to bugs.webkit.org Standard: Link to standard or public discussions with other browser vendors. Preference: name of flag. Status in other browsers: "shipped", "intent emailed" or "considering". web-platform-tests: Test suite for this feature.

III/ Intent to ship template

Subject: Intent to ship: <your feature goes here>

As of <today + 1 week> I intend to turn <name of feature> on by default:

<link to https://bugs.webkit.orgto turn the flag on>. This has

originally been proposed in <link to https://lists.webkit.org/pipermail/webkit-devintent to prototype>.*If

anything changed since that thread please include that information in this email*.

It's acceptable to merge the "intent to prototype" into the "intent to ship" email as long as all the relevant requirements are met.

Contact us to advertise here
# Ryosuke Niwa (5 days ago)

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: 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 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.

  1. Implement the feature normally behind a off-by-default preference. >

This is not a preference, it's a WebKit policy: webkit.org/feature-policy

  1. 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".

  1. 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: 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 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
# Frédéric Wang (5 days ago)

just replying quickly to two points:

On 27/02/2020 08:08, Ryosuke Niwa wrote: >

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".

Yes, it's about enabling the feature by default, as I said it's up to the port maintainer to later decide whether they want to disable it. The term "shipping" was copied from Mozilla's template but we can use something else if that's misleading.

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.

Right, the proposal says + 1 week, but that's just an example.

# Maciej Stachowiak (5 days ago)

I think we should have some structure, not just freeform emails. We can start with a simple template, but there’s some info that folks almost always want, so it’s easier if it’s included in the first place, rather than needing predictable follow-up questions

I also like having a title pattern, because that makes it easier to search email to find all things that fit the category.

Basically, since for any given feature email, there’s many potential readers and only one sender, so it seems reasonable to ask the sender to do a little extra

I had some sample templates (much simpler than the ones used by Chrome) which I will dig out and send here.

On Feb 26, 2020, at 11:08 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

Thanks for starting this discussion.

On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <fwang at igalia.com <mailto: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: trac.webkit.org/wiki/AddingFeatures, 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 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.

I personally think every web platform facing change should be announced, but it’s ok if some broader feature announcements cover every property and attribute in the spec at the time, even if they don’t land all at once. On the other hand, in specs like HTML or DOM, many individual new markup attributes or DOM properties are a feature in themselves.

  1. Implement the feature normally behind a off-by-default preference.

This is not a preference, it's a WebKit policy: webkit.org/feature-policy, webkit.org/feature-policy

I think he was using “preference” to mean “setting”, not to suggest that this is merely a preference and not required.

# Yoav Weiss (a day ago)

On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak <mjs at apple.com> wrote:

I think we should have some structure, not just freeform emails. We can start with a simple template, but there’s some info that folks almost always want, so it’s easier if it’s included in the first place, rather than needing predictable follow-up questions

I also like having a title pattern, because that makes it easier to search email to find all things that fit the category.

FWIW, at blink-dev, we found a title pattern extremely helpful in enabling scripts pick up intents that need reviewing, as well as enable more visibility through twitter bots (e.g. the intenttoship@ twitter.com/intenttoship account)

Want more features?

Request early access to our private beta of readable email premium.