[whatwg] [blink-dev] Intent to Ship: Scroll To Text Fragment

[Chris Wilson]

On Thu, Oct 24, 2019 at 6:35 PM Maciej Stachowiak <mjs at apple.com> wrote:

> So on the whole, I don’t think Chrome engineers do as good a job as they
> could of actively soliciting signals. Members of the WebKit team at Apple
> are usually happy to provide an opinion if asked, or at least point to
> someone who can give an informed opinion. We also make sure to sync
> internally on things like this, to be able to give relatively official
> opinions.
>

Seconding Yoav's question - what would be the best way for us to write into
the Blink process to do this?  I think "quote any member of the Webkit team
you can get to make a statement in public" has multiple failure modes, so I
want to make sure we're pointing to (as you put it) relatively official
opinions.


> It’s possible that this is a Blink process problem, and that maybe “no
> signals” should be accompanied by a record of the lack of signal and/or
> attempt to solicit one, to remind Blinkers to actively ask. Assuming that’s
> the intention of the signals section.
>

We just had a conversation on precisely this topic, and I expressed the
concern that embedding a record of our attempts to solicit opinions might
also be taken as shaming, which isn't our intent either.

I think I'm hearing:

   1. Blink needs to be more explicit about asking for signals.  It would
   be good to have those as repeatable channels at the various other platform
   implementation organizations.
   2. Blink needs to be more intentional about notifying when features are
   tracking to land, to put appropriate pressure on getting those signals
   (positive or negative).

It’s especially concerning that WICG does not require either multiple
> implementation experience (like W3C WGs do) or multiple implementor support
> (like WHATWG does). As a result, single-implementation specifications with
> no track to multi-engine implementation look exactly the same as incubation
> projects with multi-implementor support.


I have to disagree with your concern, at least as an entry point.  The
whole point of starting incubations is that they may not have multiple
implementers interested in prototyping -but an incubation is not the end
point.  Certainly, as specs graduate from WICG incubations into an
appropriate WG (or the WHATWG) - their exit point from incubation - I would
expect multiple implementers to support and to be working on
implementations.

"No track to multi-engine implementation" can be only a matter of time and
priority, also.  I'm not against declaring more directly/publicly what
implementers are "supporting" (in quotes because there's not a precise
definition here) any given incubation, if we can come up with a way to do
so; would that help?

sometimes we end up with specs using the WICG “Community Group Draft
> Report” logo while in an individual’s personal repo rather than in WICG.
>

As Yoav said, I think this is a bug - much like putting the W3C editor
draft logo on a spec in a personal repo.  Misleading, at best.


> I think these are process problems with WICG.


I am strongly against making a higher bar than "multiple independent
parties are interested" in order to start an incubation - because a bar
such as "must have multiple implementers supporting" would mean the vast
majority of incubations would be done effectively outside the community, in
personal or corporate repos, with no early contribution IP commitment or
outside engagement.

That said, I'm happy to talk about process improvements we can do in the
WICG - for example, I proposed above that we enable implementers to tag
their support in WICG repos.  Would that help?  Is there something else we
should change?

-Chris
(WICG co-chair, among other roles)