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 

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 <rn...@webkit.org> wrote:
> Thanks for starting this discussion.
> On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <fw...@igalia.com 
> <mailto:fw...@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

webkit-dev mailing list

Reply via email to