Re: Member submission guide (Re: Agenda: W3C Process CG Telecon 23 July 2025)

On 2025/07/23 12:33, Philippe Le Hégaret wrote:
> On 7/23/2025 11:30 AM, Florian Rivoal wrote:

>> I'll be adding suggestions to that effect in the Google Docs. They're 
>> not meant to be blocking, so if you want to land the text as is, 
>> that's fine by me. At the same time, if you think some of these 
>> suggestions are uncontroversial improvements, feel free to take them 
>> in right now. As for the rest, I'd expect to send them as a PR 
>> against the first version, once landed.
>> However, I think we should also do a second pass soon after, for a 
>> few reasons:
>>
>> * some of the language seems quite outdated to me, and it would be 
>> better to bring it up to speed with current practices
>
> Got an example of such outdated language? I stumbled on the mention of 
> the document license myself but chose not to look at it for now. After 
> all, the submitter can always re-license their work under different 
> terms anyway.

You've already accepted my suggested replacement on that one, but one 
example was:

> On the other hand, when W3C is in the early stages of developing a 
> charter, Members SHOULD use the Submission process to build consensus 
> around concrete proposals for new work.
The SHOULD is outdated, as there are other ways to do this now, like CGs.

As far as the Document License is concerned, I agree it's outdated, but 
that's actually still a requirement in the new Process. So when we want 
to fix this, that's where we need to do it. This is also a good example 
of the next point.

>> * I think it would be useful to distinguish which bits are remainders 
>> of the (new) Process, and which bits are additional requirements/ 
>> expectations (now) imposed by the Team on its own authority. That 
>> way, when someone wants to make this document evolve, it's easier to 
>> tell apart what can be changed as long as the Team agrees from what 
>> is anchored by the Process.
>
> Well, since we're moving away from the Process, I'm not sure if having 
> the distinction matters in the long run. We will always have the copy 
> of 2023 process available in any case. Similar to the charter 
> template, we'll need to be careful in how we evolve the document and 
> inform the AC about changes.

The new Process has much less to say about Member submissions, but not 
nothing. It makes sense to me to have /Guide either cite or link to 
those remaining requirements, and add some more things which are now 
based on the Team's authority (even if they originally come from the old 
Process). On the other hand, if /Guide contains text which makes no 
reference to the new Process, and just describe the entire thing from 
start to end, paraphrasing requirements still in the new Process (using 
text derived from the old Process), it may work right now because these 
two descriptions are actually compatible, but as the Team evolves its 
expectations and as /Guide gets edited, we're at risk of introducing 
changes which are actually not compatible with the Process.

So far the requirements, despite different phrasing, are compatible, so 
it's fine. But I think a reframing which links to and/or blockquotes the 
new process, and adds extra information or extra requirements as 
distinct text would be preferable. So again, for now, it's OK, but for 
v2, I think we should try and remold this a little more.

>> * Given that this is now Guide text, and not Process text, I think 
>> there are quite a few places where we'd be better off rephrasing away 
>> from RFC2119 language.
>
> agreed. I merged your proposals.

Thanks. I think there's more to do in this direction, but that already 
helped.

I think that's all the time I have for this today. As long as we're OK 
iterating after the initial inclusion into /Guide, I think I'm good.

—Florian