Where do we start for a draft?

[xeenon]

We need to discuss where we should start documenting a spec draft.

• Should we start at the manifest.json format or other another area of the common core of APIs?
• Do we inherit anything from the old CG (issue What to do with the older CG?  #1)?
• Should we contribute WebIDL files for the APIs?

[therealglazou]

Maybe we first need to discuss how and where we discuss? We have four possible chat sources:

1. GH issues
2. matrix
3. CG mailing-lists
4. regular confcalls ?

[dotproto]

@therealglazou, there's a bit of context lost in the transition from our pre-announce efforts to the public group. The primary channels we're currently planning to use are GitHub issues, regular conference calls, and Matrix. We just published a blog post that outlines the meeting schedule.

• Issues for specific topic and long-running conversations.
• Conference calls to discuss topics that require higher bandwidth conversations than issues typically allow
• Matrix for general chat, quick questions, pings, etc. We may ask participants to open issues here for tracking purposes.

We allude to this in the contributing guide, but we can probably make that clearer.

[dotproto]

Should we start at the manifest.json format or other another area of the common core of APIs?

I don't have strong opinions on where to start. As the entry point for extensions, manifest.json feels like a natural starting point. Alternatively, we could go breadth first and start collecting the topics that we want to pursue in more detail. This could potentially allow us to parallelize work and identify areas where we need further discussion.

I'd love to hear @zombie and @mukul-p's thoughts here.

Do we inherit anything from the old CG (issue #1)?

In a comment on that issue I suggested one way that we might handle the previous group's assets.

I don't think we should start from the Browser Extensions draft spec as I want to be judicious about the initial common core we pursue. That said, I do think it makes sense to borrow targeted pieces of document where appropriate to accelerate our efforts.

With respect to our drafting efforts, we could do something like the "breadth first" approach I suggested above by extracting the heading structure from the Browser Extensions draft spec and using that outline to help guide our conversations.

Should we contribute WebIDL files for the APIs?

My gut feeling is yes, but I'm not sure how high of a priority this should be. Eventually having WebIDL makes a lot of sense as it gives us a common language to describe an API surface and browser vendors are already familiar with it. That said, I can't help but wonder if we may need to make some material progress on identifying and specifying the common core before we start pursuing IDL for it.

---

Finally, there's also the more meta topic of what stack do we use to produce a spec? The two tools I'm aware of in this space are ReSpec and Bikeshed. @zombie and @mukul-p, do you have any thoughts?

[Jack-Works]

Maybe we should start with the high-level abstraction, explain and define content scripts, user scripts, background page, etc...

[Techdojo]

Maybe we should start with the high-level abstraction, explain and define content scripts, user scripts, background page, etc...

Defining a common language and set of concepts would be a great place to start.

[dotproto]

I believe that in the 2021-06-24 meeting we reached a loose consensus to start the specification work by focusing on manifest.json.

We did not discuss spec tooling in the meeting and there has been minimal discussion here and in Matrix. In the interest of making forward progress, I think we should start with Bikeshed and get a basic build pipeline set up. Once we have that we can start drafting spec content and discussing details.