[MPEG-OTSPEC] Consensus Protocol

[Dave Crossland]

On Wed, Aug 26, 2020 at 11:42 AM Levantovsky, Vladimir <
Vladimir.Levantovsky at monotype.com> wrote:

> On Wednesday, August 26, 2020 12:42 AM Dave Crossland wrote:
> In thread RE: [MPEG-OTSPEC] Updates to specification, On Wed, Aug 19, 2020
> at 2:22 PM Peter Constable <pgcon6 at msn.com> wrote:
>
> I have pointed out in the past and again this morning in another thread
> that a weakness in the current AHG process is that it’s possible for things
> to go into OFF without really having had a lot of review from implementers.
> Not that there hasn’t been reasonable opportunity for review, but more that
> the engagement is passive: a proposal can be made and incorporated unless
> objections are raised, with silence treated as implicit consent. But I
> don’t think it can really be considered consent if a proposal wasn’t
> actually reviewed: silence gives no indication up, down or sideways. I’d
> prefer to see more thumbs up on anything before adoption.
>
>
>
> Hmm... Whose thumbs ought to go up, and if someone gives a thumbs down,
> what then?
>
> Vlad, I'd like to request from you that, as chair, you write down and
> share the full AHG consensus protocol you want the group to use, as a
> proposal, and see if the group can agree to it, according to itself :)
>
>
>
> The long standing practice in MPEG and in this AHG group has been rooted
> in the simple principle that silence means approval, whatever the topic of
> a discussion might be.
>
> ...
>
> The alternative approach of asking for explicit approvals before the group
> can proceed (proposed by Peter) is an open invitation for abuse
>

I think that principle is good.

However, the underlying need that Peter has expressed seems valid to me,
and abuse can be entirely avoided by having thhe current
silence-is-consent-based protocol be maintained completely unchanged, but,
still taking note in a non-blocking way of anyone's silence, approval,
disapproval, or concrete objection.

With the better forum of a Github Issue Tracker, this can be extremely
light weight, and can be easy to track too, per issue. I've started another
email thread to request such a tracker.

Using the https://github.com/MPEGGroup/FileFormat repo as a live example,
there issue #6 was created by David Singer, who is here on this list.

The following unix command calls the Github API (api.github.com) and
returns a JSON fragment with the 'reaction' I just placed on his issue:

  curl \
  -H "Accept: application/vnd.github.squirrel-girl-preview+json" \
  https://api.github.com/repos/MPEGGroup/FileFormat/issues/6/reactions;

<https://github.com/MPEGGroup/FileFormat/issues/6>

[

  {

    "id": 82357877,

    "node_id": "MDg6UmVhY3Rpb244MjM1Nzg3Nw==",

    "user": {

      "login": "davelab6",

      "id": 261579,

      "node_id": "MDQ6VXNlcjI2MTU3OQ==",

      "avatar_url": "https://avatars0.githubusercontent.com/u/261579?v=4",

      "gravatar_id": "",

      "url": "https://api.github.com/users/davelab6",

      "html_url": "https://github.com/davelab6",

      "followers_url": "https://api.github.com/users/davelab6/followers",

      "following_url": "
https://api.github.com/users/davelab6/following{/other_user}",

      "gists_url": "https://api.github.com/users/davelab6/gists{/gist_id}",

      "starred_url": "
https://api.github.com/users/davelab6/starred{/owner}{/repo}",

      "subscriptions_url": "
https://api.github.com/users/davelab6/subscriptions",

      "organizations_url": "https://api.github.com/users/davelab6/orgs",

      "repos_url": "https://api.github.com/users/davelab6/repos",

      "events_url": "https://api.github.com/users/davelab6/events{/privacy}
",

      "received_events_url": "
https://api.github.com/users/davelab6/received_events",

      "type": "User",

      "site_admin": false

    },

    "content": "+1",

    "created_at": "2020-08-26T16:17:19Z"

  }

]

So you can see in this JSON that I (user/login = davelab6) used the "thumbs
up" emoij reaction (content = +1")

I can imagine that it will be straightforward to build a "issue dashboard"
webpage that uses the Github API to tally the reactions for each open
issue.

This webpage can itself be hosted on the MPEGGroup github repo itself,
using pages.github.com hosting, so it is totally transparent.

I imagine it that anyone could submit their own username to a config file,
that makes explicit on the page when they have NOT reacted to an issue; a
view of that data would provide a 'TODO list' for each user to know which
issues they haven't responded to.

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?

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.


> 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 :)

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.

Cheers
Dave
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20200826/186334d5/attachment-0001.html>