On Thu, Feb 27, 2020 at 6:24 PM Maciej Stachowiak <[email protected]> wrote:
> > 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. > FWIW, at blink-dev, we found a title pattern extremely helpful in enabling scripts pick up intents that need reviewing, as well as enable more visibility through twitter bots (e.g. the intenttoship@ <https://twitter.com/intenttoship> account) > 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 <[email protected]> wrote: > > Thanks for starting this discussion. > > On Wed, Feb 26, 2020 at 10:33 PM Frédéric Wang <[email protected]> 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 > > 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/ > > > 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/ > > 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/ 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 > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev > > > _______________________________________________ > webkit-dev mailing list > [email protected] > https://lists.webkit.org/mailman/listinfo/webkit-dev >
_______________________________________________ webkit-dev mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-dev
