[prev in list] [next in list] [prev in thread] [next in thread]
List: webkit-dev
Subject: Re: [webkit-dev] Proposal for an "intent to" process for web-exposed features
From: Ryosuke Niwa <rniwa () webkit ! org>
Date: 2020-02-27 7:08:33
Message-ID: CABNRm62dW95SeSGHgxKtMYmEgy+d+=S8JPHqcym7WCPdarL9mA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Thanks for starting this discussion.
On Wed, Feb 26, 2020 at 10:33 PM Fr=C3=A9d=C3=A9ric Wang <fwang@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. Su=
ch
> 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/remova=
l).
> 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
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
dir="ltr"><div>Thanks for starting this discussion.</div><div \
dir="ltr"><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On \
Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <<a \
href="mailto:fwang@igalia.com">fwang@igalia.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><div id="gmail-m_-3689131201992439938magicdomid5"><br>
</div>
<div id="gmail-m_-3689131201992439938magicdomid92"><span>The idea of
an "intent to" process has been raised several times in the \
past</span><span> (e.g. in our 2020 goals [1])</span><span> 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). </span><span>For the former
point, s</span><span>ee \
[</span><span>2</span><span>][</span><span>3</span><span>][</span><span>4</span><span>] \
for examples of how coordination is not smooth right now.</span><span> The latter
point will give a better understanding of what's happening in
WebKit and help web developer \
advocacy.</span></div></div></blockquote><div><br></div><div>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: <a href="https://trac.webkit.org/wiki/AddingFeatures">https://trac.webkit.org/wiki/AddingFeatures</a></div><div></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div id="gmail-m_-3689131201992439938magicdomid94"><span>The \
Mozilla
and Chromium projects have their own process [</span><span>5</span><span>] \
[</span><span>6</span><span>]. 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 \
</span><span>developed under
a runtime preference </span><span>for now (i.e. </span><span>excluding small
features for which it's not worth introducing a flag, behavior
changes or deprecation/removal</span><span>). Below is
a proposal based on Mozilla's \
one.</span></div></div></blockquote><div><br></div><div>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).</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div id="gmail-m_-3689131201992439938magicdomid25"><span>1. Email \
webkit-dev with an intent to \
prototype.</span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Similarly, adding a new API has multitude of \
scales. On one hand, there is ResizeObserver and there is <a \
href="https://trac.webkit.org/changeset/209648/webkit">adding pointerLockElement on \
ShadowRoot</a>. 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.</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"><div id="gmail-m_-3689131201992439938magicdomid25"> 2. Implement \
the feature normally behind a off-by-default \
preference.</div></div></blockquote><div><br></div><div>This is not a preference, \
it's a WebKit policy: <a \
href="https://webkit.org/feature-policy/">https://webkit.org/feature-policy/</a></div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div id="gmail-m_-3689131201992439938magicdomid27"><span>3. Email \
webkit-dev with an intent to \
ship.</span></div></div></blockquote><div><br></div><div>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.</div><div><br></div><div>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".</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div id="gmail-m_-3689131201992439938magicdomid28"><span>4. If \
there's no negative feedback, ship (ports maintainer can still disable the
feature if they want \
to).</span></div></div></blockquote><div><br></div><div>We should probably adopt the \
same 5 business day policy here.</div><div><br></div><blockquote class="gmail_quote" \
style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div id="gmail-m_-3689131201992439938magicdomid30"><span>II/ \
Intent to prototype template</span></div></div></blockquote><div><br></div><div>I \
don't think a template is necessary. We don't have a template for nominating \
reviewer, committer, etc... </div><div><br></div><div>We should just have a list of \
topics / details / information each email should contain. We should probably \
have:</div><div><ul><li>Summary of new feature / behavior change</li><li>Bug \
URL</li><li>Spec URL / PR / Issue</li><li>Status in other \
browsers</li></ul></div><div>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...</div><div><br></div><div>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: <a \
href="https://webkit.org/status/">https://webkit.org/status/</a></div><div><br></div><div>We \
should probably create some other page / tracking tool where all behavior changes to \
existing Web APIs are tracked. And updating of <a \
href="https://webkit.org/status/">https://webkit.org/status/</a> 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.</div><div><br></div><div>- R. \
Niwa</div><div><br></div></div></div></div></div></div></div>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic