[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 #15 from Sam Weinig <sam at webkit.org> ---
(In reply to Maciej Stachowiak from comment #14)
> (In reply to Sam Weinig from comment #7)
> > So, without the implementation aspects of the proposal, the latest proposal
> > is:
> > 
> > 
> > The Experimental Features set is:
> > 
> > - Features that have not shipped in an official release.
> > - Preferred to be off by default (this means that if the experiment is
> > disabling something, it should be phrased as a negative, e.g. Disable SQL
> > Databases), but a stable feature waiting for an upcoming release can stay in
> > the experimental features set on by default until has shipped.
> > - Stable enough that we would like people to try them out.
> > - A feature or bit of functionality we would like for developers to try out. 
> > 
> > Features that still have utility in being configurable after they ship
> > should move to the Internal Features set.
> 
> Seems like this would make it inconvenient for people to try turning such
> features off (at least in Apple ports), and would create a confusing
> disconnect for anyone testing on/off comparisons, where they now have to
> look in a different place.
> 
> I can see how it is conceptually wrong to call a shipping feature
> “experimental” but this aspect of the proposal seems to have serious
> downsides, unless we change the UI to make internal flags much more easily
> accessible, and put them closer to experimental flags.
> 
> By way of comparison, other browsers with feature flag UI do not move flags
> to a totally different and less easily accessible place when they become on
> by default. And I don’t think we should do so either.
> 
> Maybe this means we should drop the label “experimental” and just call them
> something neutral like “feature flags”.

This is getting a bit too into Safari's UI probably, but the Develop menu has other features in it that aren't "experimental" (see the "Disable Styles", "Disable JavaScript" section). There is nothing stopping Safari from adding these features where it is useful to disable them to other parts of the menu. I also think it would be a useful exercise to make a decisions when a feature has shipped if it really is useful to have a way to disable it, and thus it's manual inclusion in the Develop menu will require more thought. I am not convinced that most features need a way to be disabled after shipping, so this seems ok to me.


That said, if we want to make it "easy" to have a way to disable some features after shipping, we could make another group, "Toggle-able Features" say, that exists parallel to the "Experimental" and "Internal" Features groups. Then, Safari could decide how it wants to display these.


I am making this argument because I think it is valuable to have clear delineation of what we think is "experimental", as it makes a clear indication both to those working on WebKit and to web developers on the status of the feature. The more we conflate shipping and experimental status, the muddier and more confusing that becomes.

-- 
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/20210322/645637ab/attachment.htm>