clarify deliverables of the group

[npdoty]

This paragraph describes the "primary artifacts" of the group:

The primary artifacts of the Community Group will be technical specifications of capabilities that support advertising while implementing the browser's responsibility to act in the interests of users, including preserving privacy. These technical specifications will be developed in preparation for standardization in other groups.

But this leaves out the two known, planned deliverables: a proposed WG charter and a community group report on principles.

This also includes another novel description of the scope of the group, to implement the browser's responsibility. That doesn't match the scope of proposals which may extend beyond just browser features. And many may see privacy as the responsibility (and in some places, a legal requirement) for other parties, not just the browser.

Documents for new features will be accompanied by test cases.

I'm not sure test cases are necessary when this incubation work isn't being standardized yet. Test cases might encourage potential implementers to think that APIs and designs are already settled, which is typically something that would happen during standardization.

[seanturner]

On the first point (and I am nit picking here), I hope the primary artifacts are not the two planned deliverables :) I am hoping we can address the two other noted deliverables in a new 2nd paragraph that says something about also bootstapping an associated WG by creating its charter and specifying some principles. Now that there's this other document Robin referenced maybe we can add some words around that too.

[AramZS]

@npdoty Addressing the test case situation in particular: I think it is pretty standard process, as I understand it, in the w3c that proposals will often come in having already undergone some level of testing and including at least one test case. My concern here is that we do not want to see proposals that might not have been fully thought out as implementable and be handling a huge number of proposals that there is not even enough of an interest to see a test done around them. I'm open to amending this language in some way, but I have sort of the opposite worry, not that people will think a proposal having a test case is standardized, but that we will end up seeing proposals that are impossible to standardize.

I think the danger of some misconception that a proposal is standardized when that's not our intent should be, in part, resolved by the fact that we are a CG and not a WG. Additionally, the folks who don't understand the process well enough to understand how a tested proposal isn't a standard are--I think--equally likely to misconstrue any activity we take on a proposal as some sort of standardization step even when we are just examining or drafting a report on it. So I'm not sure that it not needing tests would be a good defense against that problem.

Do you think there might be another way to handle your concern outside of lowering this particular requirement bar?

[npdoty]

My impression is that WGs are sometimes slowed down by needing to catch up with writing automated tests and so I thought it wasn't necessary at the CG stage. I don't feel strongly that it would be misleading (I agree, anyone could be misled, and testing isn't likely the main signifier), just that writing tests can take time and effort, which might make us resistant to further changes.

I didn't read "accompanied by test cases" as meaning someone tried it out, like a Chrome origin trial or a demo, but as a suite of WPT tests. Which was intended?