Re: WG draft charter

The W3C has a process <https://www.w3.org/2019/Process-20190301/#Reports>
for moving from Working Draft to Recommendation. It has changed over the
years and is not the same process as was in place when MathML first became
a recommendation. In the end, the committee puts forth a Candidate
Recommendation (CR) if the director approves, gets feedback on that, and
again if the director approves it based on technical issues,
implementor feedback, and community feedback, it moves on to Proposed
Recommendation (PR). No changes can be made to the CR except for removing
"at risk" items. Once it becomes a PR, the  Advisory Committee must approve
it. This is mostly a consensus vote, so a single dissent can sink the
recommendation.

Because of this process, it would be self-destructive to include
controversial items in a recommendation without labelling them "at risk"
and ultimately removing them if they remain controversial. I think that is
the ultimate safeguard to what you are concerned about. Nothing about this
process prevents adding language to the charter emphasizing the issues you
are concerned about though.

    Neil


On Mon, Aug 3, 2020 at 4:03 AM Frédéric Wang <fwang@igalia.com> wrote:

> Maybe I haven't read in details but I don't think these address my
> concern. At least MathML3 also had similar W3C's "two interoperable
> implementations" and "test suite" rules, and that unfortunately didn't
> prevent it from becoming what it is. I'd prefer to follow a stricter model
> like WHATWG and the browser community do, where you need support and test
> coverage for each change.
>
> What you quoted is "deliverables" and "success criteria" which just sounds
> goals not decision policy, so I don't see how it prevents us from putting
> something in core that has no implementor's interest or is controversial in
> the browser community or no test plan. Actually, one could say this is
> worse, since that means we can actually put a complex/controversial
> feature, wait for the PR application, finally try to convince browser, get
> pushback and then give it up with the idea. Moreover, browser vendors
> really only use working drafts as a reference these days, so I don't think
> MathML Core drafts should even contain controversial things.
>
> Note that my remark is only for MathML Core, I don't care if people put
> things in MathML full that have no browser implementor interest if this is
> just to present something for discussion or to experiment with polyfills.
> What I don't want is the way of thinking "put something in core without
> following the modern approach of the browser community, with the hope that
> it will get natively implemented in browsers".
>
> On 03/08/2020 01:52, Neil Soiffer wrote:
>
> I think what you want is at least partially addressed by what is written
> in "deliverables" for MathML Core Level 1:
>
>> This specification provides an initial integration to the platform with
>> increased implementation details, focused on a subset of MathML 3 which had
>> wide implementation and could be 'fit' into the platform. It greatly
>> details and relies on automated web platform tests aiming to greatly
>> improve MathML interoperability.
>
>
> It is supported by the listing of a Test Suite and Implementation report
> in the non-normative documents. This is backed up by the success criteria:
>
>> There are multiple, independent, interoperable native implementations of
>> MathML Core Level 1 that are widely used
>
>
> Furthermore, we can't proceed to Proposed Recommendation (PR) without two
> interoperable implementations as per W3C policies. So no matter how
> important I think linebreaking support may be and how good I might be at
> convincing others that it is essential for Core, without the
> implementations, Core will never make it to PR without it being implemented.
>
> Based on other group's "Decision Policy" sections, that section should
> concern itself with voting policies (consensus, voting time periods, ...),
> not criteria on which way a vote should go.
>
> We need to improve the intro language, the scope language, and language
> about what the group produces. I think changes there will be able to
> address your concerns. I hope you and others will suggest wording
> changes/improvements to those sections as we move forward with the charter
> development.
>
>    Neil
>
>
>
> On Fri, Jul 31, 2020 at 3:15 PM Frédéric Wang <fwang@igalia.com> wrote:
>
>> Thanks Brian for working on the draft,
>>
>> I just skimmed through it, I think it looks good overall. My main
>> concern is about the policy regarding what will go into MathML Core
>> specifications (or any other one that is intended to be implemented
>> natively in browsers).
>>
>> I believe the charter should really contain strong rules that aligns
>> with the policy of other web platform standards (maybe in "Decision
>> policy"?), so we are sure that we don't end up adding/keeping something
>> in the spec that, for example, lacks rigorous implementation details,
>> does not have web platform tests, is controversial among the browser
>> community or for which nobody is committing to implement it.
>>
>> We have tried our best to adhere to these principles and that was
>> instrumental in order to convince the browser community that our CG is
>> credible and address criticisms of the MathML3 specification. However,
>> this is a topic that has been raised again and again in Core meetings.
>> So I think we should make sure that this is clearly stated in the charter.
>>
>> --
>> Frédéric Wang
>>
>>
>>
> --
> Frédéric Wang
>
>