Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify criteria for adopting work into the WICG #94

Open
jyasskin opened this issue Mar 11, 2020 · 7 comments
Open

Clarify criteria for adopting work into the WICG #94

jyasskin opened this issue Mar 11, 2020 · 7 comments
Assignees
Labels
Incubation Process Incubation/Interoperability/Implementation

Comments

@jyasskin
Copy link
Member

I'm interpreting the step of creating a repository in the WICG org as "adopting work".
The charter doesn't really say anything about what work the WICG can adopt.
The clearest statement I can find is in https://github.com/WICG/admin/blob/gh-pages/README.md#contributing-new-proposals:~:text=Evaluation

As a community, we will use Discourse to evaluate interest and ask for potential editors for the proposal. As soon as sufficient interest is shown in the discourse (notably from potential implementers), the WICG chairs will enable a team of editors to manage the proposal (based on the discourse), and those team members can move ownership of the GitHub repo (if any) to WICG.

What's "sufficient interest"? I think in practice it's been people from two separate organizations, not necessarily browser vendors or engine implementers, saying the problem is worth solving, but I'd like to be able to point potential contributors to something more official than my memory.

@travisleithead
Copy link
Member

Yeah... I'm concerned if this starts to include any formal criteria around the participants' organization or especially the browser engines used by those organizations. I think the intent here was to have as low a bar as possible to start new work. So to me, "sufficient" is almost "minimum" interest. IIRC, I've seen as little as one expression of interest from a separate community member be a trigger to move the proposal forward--not sure that's the right criteria though.

@marcoscaceres
Copy link
Contributor

What's "sufficient interest"?

It's not really quantifiable, but a couple of "yeah, that could be something we are interested in exploring" is usually sufficient. The aim is to circulate the idea and make sure that it's not a single vendor just pushing for stuff - and that an idea has been well socialized. It's a "you know it when you see it" kinda situation.

If a single vendor is like "we want this", and everyone else is "...meh" and don't respond in the Discourse thread (or in a GitHub repo), then usually we don't want to spin something up.

I think in practice it's been people from two separate organizations, not necessarily browser vendors or engine implementers, saying the problem is worth solving, but I'd like to be able to point potential contributors to something more official than my memory.

We deliberately keep it somewhat ambiguous... but the expectation is that proposals are put forward in "good faith", and that if they don't get momentum outside a single organization, then those proposing it should accept that it probably shouldn't be incubated at this time... or that more work is needed to sell it to the community.

@travisleithead
Copy link
Member

I think it's also worth noting that "sufficient interest" isn't necessarily constrained to the WICG community only--if the proposing party can point to evidence of interest from outside communities, that's also acceptable.

@domenic
Copy link
Contributor

domenic commented Mar 12, 2020

If a single vendor is like "we want this", and everyone else is "...meh" and don't respond in the Discourse thread (or in a GitHub repo)

I don't think this is an accurate depiction of the landscape. The issue is that getting people to express "interest", or positive signals, is quite a strong lift:

  • Individual web developers working for themselves sometimes do it, but in the past I've had that taken as insufficient interest by WICG chairs.

  • Developers working at corporations often feel the need to run things up the hierarchy of their company before expressing positive signals. And there is no incentive for them to bother their management in this manner: it buys them nothing to have the repo move from a personal repo to WICG, and in fact it might cost them something as the IPR checker makes pull requests slightly harder.

  • Even if management is interested in using a feature, there are often corporate-strategy reasons to avoid speaking up with concrete "we are interested in using this" or "this would be good for our business" statements.

On the contrary, getting people to discuss the feature is easy. Everyone has opinions, and they are often happy to express them in pull requests and issues on some personal repo, or on Discourse threads, etc. This includes engineers at other browser engines, who are sometimes happy to give detailed technical feedback or help you with your design or spec, but are not able to speak up and say "Browser X is interested in this feature".

This leads to unfortunate scenarios where a feature can get quite a lot of design work and web developer/browser vendor feedback, but all of it happens in a personal repository. Maybe that's OK, but it seems unhelpful from at least an IPR perspective, if nothing else.

@marcoscaceres
Copy link
Contributor

@domenic, I concur that generally we (I?) only look at the Discourse thread, and are heavily biased towards multi-vendor interest (as it affects Mozilla directly any time we spin up a repo in various ways: from having to then get a Mozilla position, to detailed reviews that need to be justified to our own management, to having to possibly allocate resources for prototyping/implementing, etc.... and we are already super resource constrained, even more so now given the recent Mozilla layoffs).

I'm still not sure what the right answer is here, but it feels like there is a massive resource/ideas imbalance: Mozilla and Apple each have less than 7-8 people in the WICG, while Google has over 120. Even if we loved all the ideas, the volume of stuff coming through is unmanagable for Mozilla... or least, if we disregard having to give feedback in a timely manner, which could be 1-2 years. The only solution I can think of is that Google does its own incubations (something @cwilso is maybe considering, and something Apple and Microsoft are already doing), and then only bring forward a mature/manageable set of ideas that have wide industry and multi-vendor support.

For developer led proposals, I agree it's super hard to get implementer interest - something the WICG folks said would always be challenging. The WICG chairs still endeavor to support those ideas where they make sense - but again, they often get drown out by the volume of stuff already coming through the WICG.

@hober
Copy link
Contributor

hober commented Mar 13, 2020

@marcoscaceres wrote:

@domenic, I concur that generally we (I?) only look at the Discourse thread

FWIW, we (the WebKit team) generally don't pay any attention to discourse. It's not clear that it would be worth the time investment. We do try to keep an eye on new repos spun up under @WICG, though I'm sure we've missed lots of them.

@domenic wrote:

This leads to unfortunate scenarios where a feature can get quite a lot of design work and web developer/browser vendor feedback, but all of it happens in a personal repository.

@marcoscaceres replied:

The only solution I can think of is that Google does its own incubations (something @cwilso is maybe considering, and something Apple and Microsoft are already doing), and then only bring forward a mature/manageable set of ideas that have wide industry and multi-vendor support.

I think it would be great if, minimally, Google located all of its proposals in some central place — a "chrome/blink standards" GitHub organization, perhaps—so it would be easier to figure out when some explainer from some random GitHub user is actually something coming from the Chrome/Blink team. That would make my life easier in a couple of ways: with my WebKit hat on, it would help us figure out how to prioritize our review time, and with my TAG hat on, it would help us understand the provenance of design review requests we get.

@cwilso cwilso self-assigned this Sep 21, 2021
@cwilso cwilso added the Incubation Process Incubation/Interoperability/Implementation label Oct 5, 2022
@marcoscaceres
Copy link
Contributor

I has a discussion with ChatGPT about this, feeding it the various points on view (stop laughing! it's actually good 😊).

After making sure it got the context, and it stated what "success" means, I asked it:

how would you rewrite that to clarify the criteria for adopting work into the WICG?

This is what it proposed we change the above to:

"The Web Incubator Community Group (WICG) provides a space for the development and incubation of proposals that have the potential to become web standards. To be considered for adoption into the WICG, a proposal should meet the following criteria:

  • Demonstrated interest from potential implementers: There should be evidence of demand and need for the proposed technology, as indicated by feedback and engagement from potential implementers.
  • Technical feasibility: The proposal should be implementable and developed in a way that is compatible with existing web standards and infrastructure.
  • Community support and participation: The proposal should be developed in a transparent and collaborative way, with the support of key stakeholders and community members.
  • Clear and well-defined goals and specifications: The proposal should clearly define what problem it solves, how it works, and how it fits into the existing web platform.

As a community, we will use the proposals repository to evaluate interest and ask for potential editors for the proposal. As soon as the proposal meets these criteria and sufficient interest is shown in the proposals repository (notably from potential implementers), the WICG chairs will enable a team of editors to manage the proposal, and those team members can move ownership of the GitHub repo (if any) to WICG."

Not bad. I would change a few words here and there (e.g., drop "and specification" as it's not needed at the proposal stage), but something like the above could work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Incubation Process Incubation/Interoperability/Implementation
Projects
None yet
Development

No branches or pull requests

6 participants