Add a features/draft/vendor/ directory an exempt it from CI #3726

foolip · 2026-01-27T13:51:26Z

No description provided.

jgraham · 2026-02-05T16:29:39Z

I don't really understand how this is going to work. If a vendor adds a draft feature here, how do they refer to the feature in e.g. an intent to prototype email or standards-position request? If the feature is updated "later" how is one supposed to handle references to the old name in immutable data (e.g. email)?

Basically I don't understand the concept of an "unpublished web feature". I think the use cases require there to be an agreed ID for early stage features, but which tools that don't care about early stage features can filter out.

If this proposal amounts to features getting an like vendor/foo which can be used as a real id and later renamed as normal (or marked as superseded by a different feature name), then that would make sense.

foolip · 2026-02-05T20:44:25Z

If this proposal amounts to features getting an like vendor/foo which can be used as a real id and later renamed as normal (or marked as superseded by a different feature name), then that would make sense.

That is effectively the proposal, yes. This PR doesn't say how to refer to these features externally, but vendor/foo SGTM.

jgraham · 2026-02-06T12:09:07Z

That is effectively the proposal, yes.

I think we should make that explicit, and ensure that we have group agreement on the proposal. Having a feature lifecycle that makes sense across a range of usecases feels like the important part; exactly how we represent that in the repo feels like implementation details.

ddbeck

I'll start with my assumptions. I'm expecting a loop like this:

Vendor creates a draft .yml file for vendor-originating feature X.
web-features mints a real feature Y.
web-features deletes draft X and records somewhere that draft X became real feature Y.
Vendor checks that record and replaces their feature X identifier with real feature identifier Y (or however they want to handle that mapping on their end).

I'm also assuming that we do not expect vendors to do any reconciliation with each other (we'll do that when we mint a feature). For example, two standards positions requests on the same day could trigger the creation of two vendor drafts referring to the same feature and we don't care, as long as everyone's generating unique vendor draft IDs.

If that's right, then I think this is a good place to start. I've left some comments on some specifics.

features/draft/vendor/README.md

ddbeck · 2026-02-06T12:23:19Z

features/draft/vendor/README.md

+- A web-features maintainer creates a real feature entry and replaces the draft
+  feature with a pointer to that feature.


It would be nice to have a stub/example file showing a mapping from a completed draft to a real feature ID.

Or we could have a JSON file showing former vendor draft paths (this would be nicer for us, to have the folder contain only un-minted features, but would require vendors to do a little more than not overwrite an existing file).

This has been resolved below. After the live review session with Philip, I was brought around to the idea that the resolution of a draft can and should happen in-place, rather than deleting or moving the files. While this is less convenient for me personally as a maintainer, it's less complex for the bots that are going to commit this stuff (e.g., the process for creating a draft file is, more or less, "don't clobber an existing file").

ddbeck · 2026-02-06T12:31:51Z

Also, FWIW, I have been reading "vendor" in the sense of "vendorization" and not that these things would be the sole domain of browser vendors. If, for instance, WPT or State of… surveys wanted to get in on this process, then that could happen here just as well.

foolip · 2026-02-09T14:26:09Z

@ddbeck and I live reviewed this just now. I've updated the README to say that vendor/a-feature is how you can refer to these entries, and wrote an example for how I expect this to be used.

Note that I don't think we need to publish these anywhere to start out.

ddbeck

I'm much happier with the examples here. I think this is enough for us to go on to start experimenting with this.

ddbeck · 2026-02-09T16:28:27Z

features/draft/vendor/README.md

+- A web-features maintainer creates a real feature entry and replaces the draft
+  feature with a pointer to that feature.


This has been resolved below. After the live review session with Philip, I was brought around to the idea that the resolution of a draft can and should happen in-place, rather than deleting or moving the files. While this is less convenient for me personally as a maintainer, it's less complex for the bots that are going to commit this stuff (e.g., the process for creating a draft file is, more or less, "don't clobber an existing file").

ddbeck · 2026-02-09T16:29:17Z

features/draft/vendor/README.md

+## Example
+
+The [processing instructions in HTML](https://chromestatus.com/feature/6534495085920256)
+feature is created as `vendor/html-pis.yml` file with this contents:
+
+```yml
+# features/draft/vendor/html-pis.yml
+explainer: https://github.com/WICG/declarative-partial-updates/blob/main/patching-explainer.md
+chrometatus: https://chromestatus.com/feature/6534495085920256
+```
+
+When the real web-features entry is created, it is decided to consider this part
+of `<template for>`, so the draft vendor feature is updated like this:
+
+```yml
+# features/draft/vendor/html-pis.yml
+kind: moved
+redirect_target: template-for
+```
+
+Any references to `vendor/html-pis` can be updated to refer to `template-for`.


It's my expectation that we'll revise this to use a fully-realized example, once we've been through it once or twice.

ddbeck

I'm much happier with the examples here. I think this is enough for us to go on to start experimenting with this.

jgraham

I think this needs to consider the workflow for consumption, rather than just the publishing workflow. If these feature names are going to appear anywhere in public (explainers, s-p requests, status counters, intent emails), it needs to be possible for people to reference them just like other feature ids.

jgraham · 2026-02-09T17:21:41Z

features/draft/vendor/README.md

@@ -0,0 +1,44 @@
+# Draft vendor features
+
+This directory is for features proposed by a browser vendor, to support the


Why only browser vendors?

It doesn't have to be, we can change this to allow anyone in principle. Possibly there could be a bot that looks for a specific format in WPT's WEB_FEATURES.yml files, for example.

jgraham · 2026-02-09T17:22:54Z

features/draft/vendor/README.md

+# Draft vendor features
+
+This directory is for features proposed by a browser vendor, to support the
+early use of web-features before there is a published web-features ID, and a


If we don't publish these anywhere we still can't reference them from e.g. standards positions without recreating all the build infrastructure to know what are valid definitions.

If you expect to reference these in standards positions, we can publish somewhere. How about a JSON file on GitHub pages that's updated for every commit to this repo?

Well, I expect you to reference them in standards positions (requests) :p

But yes, publishing them separately to the main ids would be fine for me.

jgraham · 2026-02-09T17:24:54Z

features/draft/vendor/README.md

+feature is created as `vendor/html-pis.yml` file with this contents:
+
+```yml
+# features/draft/vendor/html-pis.yml


I think if the subdirectory is vendor then there should be a vendor name for each proposal e.g. vendor/google/html-pis.

If it's just about the naming, could we call it tentative or proposed instead and not have any further nesting?

I quite like proposed.

Add a features/draft/vendor/ directory an exempt it from CI

acf420f

github-actions bot added documentation Improvements or additions to documentation tools and infrastructure Project internal tooling, such as linters, GitHub Actions, or repo settings labels Jan 27, 2026

foolip requested a review from ddbeck January 27, 2026 13:53

rdvnnl approved these changes Feb 5, 2026

View reviewed changes

ddbeck reviewed Feb 6, 2026

View reviewed changes

Reserve vendor/ prefix and give worked example

92d6c2a

foolip closed this Feb 9, 2026

foolip reopened this Feb 9, 2026

ddbeck approved these changes Feb 9, 2026

View reviewed changes

jgraham requested changes Feb 9, 2026

View reviewed changes

		- A web-features maintainer creates a real feature entry and replaces the draft
		feature with a pointer to that feature.

		@@ -0,0 +1,44 @@
		# Draft vendor features

		This directory is for features proposed by a browser vendor, to support the

Add a features/draft/vendor/ directory an exempt it from CI #3726

Are you sure you want to change the base?

Add a features/draft/vendor/ directory an exempt it from CI #3726

Conversation

foolip commented Jan 27, 2026

Uh oh!

jgraham commented Feb 5, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

foolip commented Feb 5, 2026

Uh oh!

jgraham commented Feb 6, 2026

Uh oh!

ddbeck left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddbeck commented Feb 6, 2026

Uh oh!

foolip commented Feb 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ddbeck left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ddbeck left a comment

Choose a reason for hiding this comment

Uh oh!

jgraham left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

jgraham commented Feb 5, 2026 •

edited

Loading

ddbeck left a comment •

edited

Loading

foolip commented Feb 9, 2026 •

edited

Loading