[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: Yoav Weiss <yoav () yoav ! ws>
Date: 2020-03-01 22:02:38
Message-ID: CACj=BEifBFy=deM77+2i=G=WUa5VHu9_aS6CO6cN94TmojV7aA () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak <mjs@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@
<https://twitter.com/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 <rniwa@webkit.org> wrote:
>
> Thanks for starting this discussion.
>
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric 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. 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.
>
>
> 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).
>>
>
> 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 mailing list
> webkit-dev@lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev
>
[Attachment #5 (text/html)]
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak <<a \
href="mailto:mjs@apple.com">mjs@apple.com</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"><div style="overflow-wrap: \
break-word;"><div><br></div>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<div><br></div><div>I also like having a title \
pattern, because that makes it easier to search email to find all things that fit the \
category.</div></div></blockquote><div><br></div><div>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 <a \
href="https://twitter.com/intenttoship">intenttoship@</a> account) \
</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
style="overflow-wrap: break-word;"><div><br></div><div>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 </div><div><br></div><div>I had \
some sample templates (much simpler than the ones used by Chrome) which I will dig \
out and send here.<br><div><br><blockquote type="cite"><div>On Feb 26, 2020, at 11:08 \
PM, Ryosuke Niwa <<a href="mailto:rniwa@webkit.org" \
target="_blank">rniwa@webkit.org</a>> wrote:</div><br><div><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" target="_blank">fwang@igalia.com</a>> \
wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF"><div \
id="gmail-m_8061948861555929901gmail-m_-3689131201992439938magicdomid5"><br> </div>
<div id="gmail-m_8061948861555929901gmail-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" \
target="_blank">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:1px solid \
rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"> <div \
id="gmail-m_8061948861555929901gmail-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:1px solid \
rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"> <div \
id="gmail-m_8061948861555929901gmail-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" target="_blank">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></div></div></div></div></div></div></blockquote><div><br></div>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.</div><div><br></div><div><br><blockquote type="cite"><div><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"><div \
id="gmail-m_8061948861555929901gmail-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/" \
target="_blank">https://webkit.org/feature-policy/</a></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I \
think he was using "preference" to mean "setting", not to suggest that this is merely \
a preference and not required.</div><br><blockquote type="cite"><div><div \
dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div \
class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px \
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div \
bgcolor="#FFFFFF"> <div \
id="gmail-m_8061948861555929901gmail-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:1px solid \
rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"> <div \
id="gmail-m_8061948861555929901gmail-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:1px solid \
rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"> <div \
id="gmail-m_8061948861555929901gmail-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/" \
target="_blank">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/" \
target="_blank">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> \
_______________________________________________<br>webkit-dev mailing list<br><a \
href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br><a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br></div></bl \
ockquote></div><br></div></div>_______________________________________________<br> \
webkit-dev mailing list<br> <a href="mailto:webkit-dev@lists.webkit.org" \
target="_blank">webkit-dev@lists.webkit.org</a><br> <a \
href="https://lists.webkit.org/mailman/listinfo/webkit-dev" rel="noreferrer" \
target="_blank">https://lists.webkit.org/mailman/listinfo/webkit-dev</a><br> \
</blockquote></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