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

[Yoav Weiss]

On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak  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@
 account)


> 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  wrote:
>
> Thanks for starting this discussion.
>
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang  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
> . 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.
>
>
>
>  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/
>
>
> I think he was using “preference” to mean “setting”, not to suggest that
> this is merely a preference and not required.
>
>
> 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
> 

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

[Maciej Stachowiak]

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  wrote:
> 
> Thanks for starting this discussion.
> 
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang  > 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 
> . 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.


> 
>  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/ 
I think he was using “preference” to mean “setting”, not to suggest that this 
is merely a preference and not required.

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

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

[Frédéric Wang]

Hi Ryosuke, 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.

-- 
Frédéric Wang

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

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

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

[Frédéric Wang]

Hi,

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] https://trac.webkit.org/wiki/WebKitGoalsfor2020
[2] Behavior change: https://bugs.webkit.org/show_bug.cgi?id=201641#c49
[3] Deprecation/Removal: https://bugs.webkit.org/show_bug.cgi?id=204125#c7
[4] New feature: https://bugs.webkit.org/show_bug.cgi?id=157743landed in
April 2019 and only enabled in
https://bugs.webkit.org/show_bug.cgi?id=203644
[5] https://wiki.mozilla.org/ExposureGuidelines
[6] https://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:  

Summary: Elevator pitch for the new functionality.
Bug: Link to https://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:  

As of  I intend to turn  on by default:
https://bugs.webkit.orgto turn the flag on>. This has
originally been proposed in 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.

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev