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

Thu Feb 27 09:22:09 PST 2020

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: 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 at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20200227/2e1dca3f/attachment.htm>