[ig/security] revert coord with AB to Process CG for process changes

[tantek]

suggest reverting to prior proposed SING charter specifically on the matter of coordinating with the Process CG instead of the AB. Process CG is where any proposed W3C Process changes should go first. The AB largely oversees the work of the Process CG, rather than separately receiving input on the Process.

cc: @chrisn @msporny @jyasskin

[simoneonofri]

@tantek thank you for the revert, it was on my to-do list.

I was also thinking about removing references to CG/AB and simply saying that you could suggest changes to the Process.

[msporny]

Yes, agree with @tantek, the Process CG is the proper place to provide input on process changes.

[msporny]

I was also thinking about removing references to CG/AB and simply saying that you could suggest changes to the Process.

IMHO, explicitly calling out where process change requests will go is better than leaving it vague... anyone can improve process changes at any time. It's worth calling out that SING plays a particularly elevated role here when it comes to process changes wrt. desired security outcomes.

[jyasskin]

We need to also find consensus on this with @frivoal since he asked for the change that's being reverted. I'm happy either way.

[simoneonofri]

@jyasskin is a very good point, as I was writing to @tantek, given that:

1. For the charter, it's functional to consider that the group could propose improvements to the Process for the security aspects.
2. For my mental order, it seemed sensible to also include who to refer to, but for the Chater, it's not essential, since as needed the information can be derived just in time.
3. Since it's an important issue anyway, surely it's worth discussing, but it deserves a separate discussion.

Given this, I would simply leave the note that improvements can be recommended, without specifying to whom, as suggested by @msporny.

[simoneonofri]

as per #613 (comment)

[tantek]

Given this, I would simply leave the note that improvements can be recommended, without specifying to whom, as suggested by @msporny.

@simoneonofri that's the opposite of what @msporny suggested:

IMHO, explicitly calling out where process change requests will go is better than leaving it vague

Emphasis added.

[msporny]

@simoneonofri that's the opposite of what @msporny suggested

Yes, thanks for pointing that out @tantek. While that's true, I don't feel so strongly about mentioning to which group the request should be targeted. I do think it's better to state it explicitly (i.e., which group should be liaised with?), but don't feel that not stating it is going to lead to anything bad happening (more flexible). I feel like I'm wading into a discussion that's been happening for a bit, don't want to be disruptive, and am probably missing some detail?

I do think it's important that SING have, as one of its primary tasks that's written down, improving the process around security reviews at W3C... and stating that explicitly is a good thing, which @simoneonofri's suggested changes do. Not mentioning any specific group might also address @tantek and @frivoal's concerns (don't mistakenly list the wrong group, or one that might change over time) and make the charter more resilient to changes wrt. where W3C Process are discussed and made?

All that said, just take my input as non-blocking commentary. I defer to those more steeped in what the most accurate charter language here should be.

[frivoal]

I can go either way, but as I proposed in the original change, I think the AB is better to list here. The Process is largely delegated to the Process CG by the AB, so on a day to day basis, talking to the Process CG might be more logical. However:

• This delegation is revocable. I don't anticipate that the AB will start doing Process work on its own any time soon, but it could, and maybe more importantly, there's occasionally been talk about converting the Process CG to a Process IG, or an AB Task Force with open participation. This quite possibly may not come to pass, but the AB is a more stable contact point that the Process CG.
• The Process CG is not autonomous in its delegation. For tweaks, clarifications, bug fixes, efficiency adjustments and the like, it generally acts independently (thought the whole work is eventually vetted by the AB before being sent to the AC). But when the Process CG hits a bigger question, it frequently refers back to the AB, asking the AB to determine the policy we should follow, and only then figuring out how to implement it. I suspect that changing the criteria by which we go to REC is something the Process CG would refer to the AB for, and in that case, starting with the AB may be just as well.

Or maybe we should just list both?

In any case, whatever the choice, I'm not blocking.

[chrisn]

I would have preferred to see coordination with Process CG mentioned, but am happy with not mentioning any specific group.

[simoneonofri]

@frivoal

Or maybe we should just list both?

In any case, whatever the choice, I'm not blocking.

Thank you. Yes, I understand your point, so I made the initial change.

However, I was further reasoned by the various comments that came in, which, in the form of other details, were rather discussed in the review.

Reflecting on charter resilience to change, I'm more inclined to make the task generic.

@chrisn

I would have preferred to see coordination with Process CG mentioned, but am happy with not mentioning any specific group.

Thank you

[simoneonofri]

as we received also the approval by @frivoal, i am inclined to merge. @jyasskin have you any comments/review?

thank you!

[jyasskin]

As I said in #613 (comment), I don't have strong opinions on this point.