Welcome...

Hi folks,


there are so far a small handful of us in this group, but I thought I would 
send a welcome message. 

Some of you know the specification, some have participated in its 
development before. Everyone is welcome to the group.

Things are still a bit in setup phase, although there are a couple of 
technical issues filed that I hope we can resolve sooner rather than later.

I assigned myself as chair so we have someone to blame. Please let me know 
if you want to share that specific workload for all the fame and glory it 
entails...

We now have a baseline spec in Github, so we can start to maintain it.

I would prefer to keep all technical discussion public, in github (or on 
this mailing list if people want to write email).

Please note we do have an "internal" mailing list. There are tens of 
thousands of people with access to that list (participants in this group, 
plus anyone with W3C Member access), but it's not available to the general 
public. The only use I can think of is for planning the timing of meetings 
(and location, if they are face to face).

A key goal is to set up a workflow. I am going to make a proposal in 
Github, which will be roughly how I have worked on this spec in the past:

   People raise issues in Github, and can propose PRs to fix them.

   We have a periodic meeting, with an agenda published far enough in 
advance to give people a realistic ability to engage via Github instead of 
turning up to the meeting.
   Agenda items can be labeled as one of 

     - "Resolve without discussion" - meaning that it seems to be simple 
with a single proposal likely to have consensus.
       *Unless* there is an objection received at least an hour before the 
meeting, or made at the meeting, it will be resolved according to the 
proposal
       (usually meaning "merge the PR") even if the meeting is canceled or 
doesn't get quorum.
     - "Question" - meaning it *will not* be resolved at the meeting, but 
someone wants others to discuss.
       If a meeting thinks it has a clear answer, it can be proposed as 
"Resolve without discussion" for the next meeting.

     Anything that doesn't have one of those labels will be up for 
resolution, based on discussion, and will not be decided if the meeting 
doesn't happen. 
     For example, if there are a couple of competing proposals to resolve 
an issue, the meeting could choose one of them.
     In general, resolutions should aim not to surprise to people who have 
followed the discussion.

   At some point there will be a proposal to publish the next version as a 
release.

Some chores I will be focusing on over the next couple of weeks:

- find a meeting time / schedule that works (and work out who expects to 
attend meetings and who promises not to do so)
- propose a charter for the group. There is a template W3C provides, but 
I'll propose a few additions, and hope we adopt it through the normal group 
workflow

So, thank you for joining the group - welcome, please bear with us as we 
get set up, I hope that the above explanations sound OK. Note that 
everything is up for discussion, so if they don't, please say so.

cheers

Chaals

-- 
Charles "Chaals" Nevile
Using fastmail.fm because it's worth it

Received on Friday, 22 May 2026 12:29:04 UTC