[Webkit-unassigned] [Bug 222885] Formalize rules for what is an Experimental Feature

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=222885

--- Comment #25 from Maciej Stachowiak <mjs at apple.com> ---
(In reply to Ryosuke Niwa from comment #24)
> (In reply to Sam Sneddon [:gsnedders] from comment #23)
> > (In reply to Ryosuke Niwa from comment #22)
> > > (In reply to Maciej Stachowiak from comment #21)
> > 
> > > I think "prototype" or "exploratory" might be better instead of "unstable".
> > 
> > I think we convey anything we don't have the confidence to be running tests
> > against likely is risky to enable, so unstable seems suitable to me?
> 
> "unstable" to me conveys that it's simply crashy because "stability" often
> refers to how frequent a crash is encountered at least internally at Apple
> and elsewhere in the general software QA sense so I don't think we want to
> be using that specific term.

Features in this category could potentially be crashy, or have serious security for perf issues. Or they could have nothing but stubs. It's probably good to use a name that sounds a bit scary. I'm not sure "prototype" or "exploratory" sufficiently convey that here there be dragons. It's possible there's a better word than "unstable" though.

> 
> > > I also feel like the distinction between "experimental" vs "developer debug"
> > > might be a bit confusing for web developers.
> > > 
> > > Maybe we need to explicitly call it some of the flags are for feature
> > > enablement and others are for debugging purposes so something like:
> > > "Internal Debug Options"
> > > "Developer Debug Options"
> > > "Exploratory Features"
> > > "Test Enabled Features"
> > > "Experimentally Enabled Features"
> > > "Stably Enabled Features"
> > 
> > It's probably not worth getting too hung up on exactly what string we use in
> > the YAML file, and allow application embedding WebKit to choose how to
> > present this information to users. If an application segregates the
> > different categories (i.e., doesn't have the current Safari behaviour of
> > putting everything in a single menu), I think the distinction between
> > "experimental" and "developer debug" should be pretty clear?
> 
> I disagree. That's one thing that separates WebKit from the rest of browser
> engine open source projects. We're very much insistent on using
> terminologies that make sense for humans even in our code so that we don't
> have code -> human-readable documentation. It has served us well, and we
> should continue to make our code self documentary.

I like distinguishing "option" flags from "feature" flags, but maybe we could try for something easy to type/read in config files. Maybe we don't need the word Enabled in all places, and perhaps these phrases could be all lowercase.

> 
> > All this said, probably relevant to any documentation of policy here is also
> > the question of when we want a runtime flag versus a compile-time flag,
> > especially for features in the "unstable" category.
> 
> The current policy is that any feature that could be complied on all
> platforms should be a runtime enabled feature unless it poses a new
> security, privacy, or perf cost that could not be rectified easily.

We have a policy document that explains when to use a compile-time flag, which includes the above conditions plus some others: https://webkit.org/feature-policy/

Probably the info about when runtime flags are enabled or disabled at the above link should be replaced with documentation of the various feature flag states.

For feature flag states that are features, not options, I wonder if we could get the WebKit feature status page to reflect them. It would be a bit more granular info than what we have now, where "Under Development" could be a wide range of conditions.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20210324/8126b6f6/attachment.htm>