[MPEG-OTSPEC] Consensus Protocol

Fri Sep 11 03:57:21 CEST 2020

Hello AHG,

I am back from vacation to a huge backlog of emails. Vacations are great, coming back … not so much ☹
(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<mailto: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/20200911/15fb7ee7/attachment-0001.html>