[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: Maciej Stachowiak <mjs () apple ! com>
Date: 2020-02-27 17:22:09
Message-ID: E7D73DE7-F504-4B4F-A093-E6B2C9E11E53 () apple ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@webkit.org> wrote:
>
> Thanks for starting this discussion.
>
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <fwang@igalia.com \
> <mailto: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 \
> <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/ <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/ \
> <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/ <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
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; \
-webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div \
class=""><br class=""></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 class=""><br \
class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I had some \
sample templates (much simpler than the ones used by Chrome) which I will \
dig out and send here.<br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On Feb 26, 2020, at 11:08 PM, Ryosuke \
Niwa <<a href="mailto:rniwa@webkit.org" \
class="">rniwa@webkit.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><div dir="ltr" \
class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" \
class=""><div dir="ltr" class=""><div class="">Thanks for starting this \
discussion.</div><div dir="ltr" class=""><br class=""></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" \
class="">fwang@igalia.com</a>> wrote:<br class=""></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" class=""><div \
id="gmail-m_-3689131201992439938magicdomid5" class=""><br class=""> </div>
<div id="gmail-m_-3689131201992439938magicdomid92" class=""><span \
class="">The idea of
an "intent to" process has been raised several times in the \
past</span><span class=""> (e.g. in our 2020 goals [1])</span><span \
class=""> 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 class="">For the former
point, s</span><span class="">ee [</span><span \
class="">2</span><span class="">][</span><span class="">3</span><span \
class="">][</span><span class="">4</span><span class="">] for examples of \
how coordination is not smooth right now.</span><span class=""> The latter
point will give a better understanding of what's happening in
WebKit and help web developer \
advocacy.</span></div></div></blockquote><div class=""><br \
class=""></div><div class="">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" \
class="">https://trac.webkit.org/wiki/AddingFeatures</a></div><div \
class=""></div><div class=""><br class=""></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" class=""> <div \
id="gmail-m_-3689131201992439938magicdomid94" class=""><span class="">The \
Mozilla and Chromium projects have their own process [</span><span \
class="">5</span><span class="">] [</span><span class="">6</span><span \
class="">]. 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 class="">developed under
a runtime preference </span><span class="">for now (i.e. \
</span><span class="">excluding small features for which it's not worth \
introducing a flag, behavior changes or deprecation/removal</span><span \
class="">). Below is a proposal based on Mozilla's \
one.</span></div></div></blockquote><div class=""><br class=""></div><div \
class="">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 class=""><br class=""></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" class=""> <div \
id="gmail-m_-3689131201992439938magicdomid25" class=""><span class="">1. \
Email webkit-dev with an intent to \
prototype.</span></div></div></blockquote><div class=""><br \
class=""></div><div class="">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 class=""><br class=""></div><div \
class="">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 class=""><br class=""></div><div class="">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 \
class=""><br class=""></div><div class="">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" class="">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 \
class=""></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 class=""></div><div><br class=""><blockquote \
type="cite" class=""><div class=""><div dir="ltr" class=""><div dir="ltr" \
class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" \
class=""><div class="gmail_quote"><div class=""><br \
class=""></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" class=""><div \
id="gmail-m_-3689131201992439938magicdomid25" class=""> 2. Implement \
the feature normally behind a off-by-default \
preference.</div></div></blockquote><div class=""><br class=""></div><div \
class="">This is not a preference, it's a WebKit policy: <a \
href="https://webkit.org/feature-policy/" \
class="">https://webkit.org/feature-policy/</a></div></div></div></div></div></div></div></div></blockquote><div><br \
class=""></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 \
class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" \
class=""><div dir="ltr" class=""><div dir="ltr" class=""><div dir="ltr" \
class=""><div dir="ltr" class=""><div class="gmail_quote"><div class=""><br \
class=""></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" class=""> <div \
id="gmail-m_-3689131201992439938magicdomid27" class=""><span class="">3. \
Email webkit-dev with an intent to \
ship.</span></div></div></blockquote><div class=""><br class=""></div><div \
class="">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 class=""><br \
class=""></div><div class="">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 class=""><br \
class=""></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" class=""> <div \
id="gmail-m_-3689131201992439938magicdomid28" class=""><span class="">4. If \
there's no negative feedback, ship (ports maintainer can still disable the
feature if they want to).</span></div></div></blockquote><div \
class=""><br class=""></div><div class="">We should probably adopt the same \
5 business day policy here.</div><div class=""><br \
class=""></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" class=""> <div \
id="gmail-m_-3689131201992439938magicdomid30" class=""><span class="">II/ \
Intent to prototype template</span></div></div></blockquote><div \
class=""><br class=""></div><div class="">I don't think a template is \
necessary. We don't have a template for nominating reviewer, committer, \
etc... </div><div class=""><br class=""></div><div class="">We should \
just have a list of topics / details / information each email should \
contain. We should probably have:</div><div class=""><ul class=""><li \
class="">Summary of new feature / behavior change</li><li class="">Bug \
URL</li><li class="">Spec URL / PR / Issue</li><li class="">Status in other \
browsers</li></ul></div><div class="">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 class=""><br class=""></div><div class="">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/" \
class="">https://webkit.org/status/</a></div><div class=""><br \
class=""></div><div class="">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/" \
class="">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 class=""><br class=""></div><div \
class="">- R. Niwa</div><div class=""><br \
class=""></div></div></div></div></div></div></div> \
_______________________________________________<br class="">webkit-dev \
mailing list<br class=""><a href="mailto:webkit-dev@lists.webkit.org" \
class="">webkit-dev@lists.webkit.org</a><br \
class="">https://lists.webkit.org/mailman/listinfo/webkit-dev<br \
class=""></div></blockquote></div><br class=""></div></body></html>
_______________________________________________
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