[MPEG-OTSPEC] Consensus Protocol

[Dave Crossland]

Thanks Vlad! I think this is helpful, yet for me it adds more questions
than it answers :) In the same way this list is called "mpeg-otspec" not
"mpeg-offspec", the meaning of "consensus" as I've understood it is very
different to the defined meaning you provided, which seems limited to the
activities of the formal WG, and not the AHG.

Since the AHG can not conduct formal voting procedures, but can conduct
"straw polls", I'd like to suggest we use Github Issues and Reactions to
manage that straw polling.

It is disappointing to me that WG can decide things by a 2/3 majority vote,
yet (AFAICT) the voters are anonymous and apparently bound to keep
everything confidential. But, I guess as long as there are no objections at
the WG level, this is rather academic.

So, say that Peter Constable proposes to update the COLR and CPAL
table definitions, based on the work done in the Google Fonts github repo
and then the Microsoft OpenType website, so that a 'beta' OT 1.9.0 document
is available from microsoft.com/typography... What is the best way to get
those new table definitoins proposed - is a whole chapter "all at once"
best?


On Thu, Sep 10, 2020 at 9:57 PM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> Hello AHG,
>
>
>
> I am back from vacation to a huge backlog of emails. Vacations are great,
> coming back … not so much L
>
> (I am not looking for sympathy, just stating the obvious. Bear with me as
> I sift through the pile.)
>
>
>
> See below.
>
>
>
> On Wednesday, August 26, 2020 1:00 PM Dave Crossland wrote:
> On Wed, Aug 26, 2020 at 11:42 AM Levantovsky, Vladimir <
> Vladimir.Levantovsky at monotype.com> wrote:
>
> This AHG has always been striving to (and, so far, has been successful at)
> reaching consensus decisions, resolving objections with edits and proposed
> changes that we as a group can agree on. When consensus decision cannot be
> reached, the escalation path is simple – bring it to the attention of the
> WG.
>
>
>
> What are the examples/cases where that escalation path has been used in
> the past? Or is this something that only WG can know about?
>
>
>
> In this AHG, we never had a situation where consensus decisions had not
> been reached, so I can’t really offer a concrete example. But it is not
> unusual for the WG to consider alternative [sometimes, conflicting]
> proposals where one possible outcome could be adopting one proposal and
> rejecting the other(s). Usually this is done after due consideration is
> given, and the outcome is based on data and factual evidence. In MPEG. It
> is customary to setup a series of core experiments (where applicable) to
> determine which of the proposals satisfies stated requirements and to what
> degree.
>
>
>
> In the history of font work in MPEG, this happened only once, in the
> beginning of the font standard development, when two competing proposals
> were brought up for consideration – a font format based on OpenType vs.
> PFR. PFR failed to satisfy requirements related to language coverage and
> complex script support, and the decision was made to start a new work item
> developing a font format standard based on OpenType.
>
>
>
> It seems to me that resolving all objections and reaching consensus in the
> AHG can be flexible, as proposed above, and thus can for this group be far
> superior to the laborious and bureaucratic formal WG process.
>
>
>
> I agree wholeheartedly! I think what sets us apart is the proven ability
> to work towards the common goal where all the opinions are heard and where
> pragmatism and practical considerations trump ambitions and feelings.
>
>
>
> For the reasons described above, I suggest that the long-standing practice
> of placing a responsibility on each individual member to review the
> proposed changes / comments, and to act within the established and
> announced timelines should stand as is. Failure to act and to respond in
> time (a.k.a. silence) is treated as approval!
>
>
>
> I'm grateful for your thoughtful reply! :) But I am requesting a
> "protocol", so what I'm really asking for is a set of "if then else"
> statements and actual dates for periods of time - which can be augmented
> with software, like the github issue tracker and dashboard webpage I
> describe above.
>
>
>
> The "first principles" of the protocol are clear to me from your reply,
> but rather abstract. I'd like to get more concrete :)
>
> I think it would be a useful starting point [for the benefit of all
> members of the AHG] to review formal ISO definitions of consensus (from
> ISO/IEC Directives, part 1, subclause 2.5.6):
>
> “*consensus*: General agreement, characterized by the absence of
> sustained opposition to substantial issues by any important part of the
> concerned interests and by a process that involves seeking to take into
> account the views of all parties concerned and to reconcile any conflicting
> arguments.
>
> NOTE     Consensus need not imply unanimity.”
>
> Also, the following paragraphs describe the process in more details:
>
> In the process of reaching consensus, many different points of views will
> be expressed and addressed as the document evolves. However, “sustained
> oppositions” are views expressed at minuted meetings of committee, working
> group (WG) or other groups (e.g. task forces, advisory groups, etc.) and
> which are maintained by an important part of the concerned interest and
> which are incompatible with the committee consensus. The notion of
> “concerned interest(s)” will vary depending on the dynamics of the
> committee and shall therefore be determined by the committee leadership on
> a case by case basis. The concept of sustained opposition is not applicable
> in the context of member body votes on CD, DIS or FDIS since these are
> subject to the applicable voting rules.
>
> Those expressing sustained oppositions have a right to be heard and the
> following approach is recommended when a sustained opposition is declared:
>
> —    The leadership shall first assess whether the opposition can be
> considered a “sustained opposition”, i.e. whether it has been sustained by
> an important part of the concerned interest. If this is not the case, the
> leadership will register the opposition (i.e. in the minutes, records,
> etc.) and continue to lead the work on the document.
>
> —    If the leadership determines that there is a sustained opposition, it
> is required to try and resolve it in good faith. However, a sustained
> opposition is not akin to a right to veto. The obligation to address the
> sustained oppositions does not imply an obligation to successfully resolve
> them.
>
> The responsibility for assessing whether or not consensus has been reached
> rests entirely with the leadership. This includes assessing whether there
> is sustained opposition or whether any sustained opposition can be resolved
> without compromising the existing level of consensus on the rest of the
> document. In such cases, the leadership will register the opposition and
> continue the work.
>
>
>
> Again, this AHG is not in a position to make final resolutions – we are
> producing proposals and recommendations that are, when based on AHG
> consensus, would find their way into WG resolutions and the text of
> standards/amendments. IF and when a sustained objection is raised, and
> attempts to devise a mechanism (a core experiment, reference
> implementation, test cases, etc.) would not allow us to reach an agreement,
> THEN the only possible outcome for us would be to document all discussions
> and views of all interested parties, and bring it to consideration of the
> WG. We are not in a position to conduct formal voting procedures, other
> than a simple straw poll to indicate support for a particular outcome. The
> final decisions would be made by the WG, most likely after an additional
> set of mandates is imposed on this AHG to conduct a series of experiments /
> tests to help collect data that would be used in final decision making
> process.
>
>
>
> Finally, according to this statement in the Directives
>
> In case of doubt concerning consensus, approval by a two-thirds majority
> of the P‑members of the technical committee or subcommittee voting may be
> deemed to be sufficient for the committee draft to be accepted for
> registration as an enquiry draft; however every attempt shall be made to
> resolve negative votes.
>
> Abstentions are excluded when the votes are counted, as well as negative
> votes not accompanied by technical reasons.
>
>
>
> it is, therefore, in the WG and Subcommittee power to ask for a formal
> approval by a 2/3 majority of voting members.
>
>
> In the next 17 months (to 1/1/2022) what are the possible pathways that a
> proposal to change "X" in the OFF spec can take? X could be COLRv1, or 32
> bit GIDs, or anything. I'd like to understand a map out of all the
> pathways.
>
>
>
> In our established practice, when a concrete proposal (or a set of
> proposals) are reviewed and agreed upon by the group, we would present them
> to the WG with the recommendation to start a new work item – either a new
> amendment or a new edition of the OFF standard, where applicable. It can
> happen at any time [when we feel the proposal(s) are ready to be introduced
> as work items, and the only limitation is that the proposals (with the AHG
> report and recommendations) need to be submitted in due time prior to the
> scheduled WG meeting (typically, there are four WG meetings a year, with
> the next one being scheduled on Oct. 12-16, 2020). It is truly up to us to
> make a determination when a proposal is ready for prime time, and this AHG
> long record of successful development made it rather easy for us as a
> community to develop and follow our own schedule, taking into consideration
> ISO process requirements (like ballot term requirements for different
> stages in the standards development process, etc.)
>
>
>
> However, it is also possible that we can ask the WG to open a new work
> item (e.g. an amendment) and create a working draft that remains a WD for
> as long as we feel is necessary to make further improvements and additions.
> Only after the WD is deemed sufficiently mature we can recommend its
> promotion to the next Committee Draft stage, where a ballot approval
> process would become necessary.
>
>
>
> Thank you,
>
> Vlad
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200910/a5379b2b/attachment-0001.html>