Discuss foundation TC39 delegate expectations

[ljharb]

In previous meetings, we've been very clear that when expression an opinion - either a statement, approval, or objection to something - an OpenJS standards delegate must be able to clearly understand, and explicitly describe, which "hat" they are wearing. Examples might be "representing one or more specific projects", or "representing the overall foundation's standards working group".

What we did not explicitly discuss, but where some of us may have inferred differently, is personal actions (statements/approvals/objections).

My interpretation of this is that as long as the "personal hat" is explicitly called out, and as long as it does not obstruct an action the standards working group has consensus on taking (eg, if the WG says "block X", then the delegate must not approve of X; if the WG says "accept X", then the delegate must not block X), that the delegate may (just like every other Ecma member delegate to TC39) act based on their personal beliefs.

One alternative inference that I've heard is that OpenJS delegates specifically must not at any time block (but may approve or make statements) based on a personal belief.

I'd like us to discuss this in the next meeting, especially in light of #83 :-)

[MylesBorins]

I'd like to chime in that I was thinking along the lines that objections coming from a TC39 delegate must be representing some form of Foundation built consensus. The granularity of this is debatable, should it be per project or working group or within a small group of like minded members... the wigglyness of this does make it harder to nail down. What I was hoping to avoid was individuals using the OpenJS foundation membership in different foundations to push personal agenda. My hope was that there was a degree of consensus building required.

This vision might turn out to not be wise or enforceable... so if I am the lone individual holding this opinion I'd be happy to drop it.

[mikesamuel]

Just to reiterate my comments from last week:

A delegate is there to use their judgement. A decision to block progress that was not previously discussed seems like such a judgement call.

I think following practices should hopefully mitigate downsides and avoid regrets:

• we make it clear that blocking will definitely require justification after the fact.
• try to make sure that all items that are up for progression are discussed ahead of time
• document in-foundation consensuses on these items
• make clear during these discussions when blocking might be with prejudice; might preclude further discussion before the standards body

[jorydotcom]

Another theme we identified from these discussions was that of the OpenJS Foundation's role in the standards forum - for example, what the expectation of not-for-profit member participation in these groups is. We discussed the implication of being a (c)6 Member Organization and the need to balance interests (and not advocate for the interest of any specific employer). I think in addition to developing practices and guidelines, this position should be clarified and documented so that we can return to it as a first principle when questions like this arise.

[mikesamuel]

I wonder whether different conceptions of "rule" might make a small disagreement seem large.

When y'all talk about rules are you:

• Describing a line that, repeatedly crossed, is evidence of bad faith, or
• Pairing boundaries and consequences such that one may, in good faith cross a boundary provided one is willing to accept the consequences.

@ljharb , @MylesBorins do you tend to prefer one of these modes or something entirely different?

[mikesamuel]

Rules are oft phrased as binary predicates but are oft used to triage.

Behavior obviously OK	Behavior unclear	Behavior obviously not OK	Kind of rule
Rule says NOPE	Rule says OK	Rule says OK	Type 1
Rule says NOPE	Rule says NOPE	Rule says OK	Type 2

[ljharb]

I would assume that there are "musts" and "shoulds" (and "must nots" and "should nots") - repeatedly violating a "should" (without group consensus on it being justified), or even once violating a "must" (without extraordinary mitigating circumstances according to group consensus), is grounds for the individual no longer being able to represent the foundation (and potentially, to no longer be able to participate in the standards group).

I believe Myles would classify "block stage advancement of a proposal, or consensus on a PR, at TC39, without prior group consensus" as a "must not", where i would classify it as a "should not".

[devsnek]

So as this currently stands, how do we discuss potentially blocking a proposal?

[mikesamuel]

I think that allowing block votes only with prior approval is unwise.

Standards processes have been abused in the past.

The ISO approval process for OOXML has been plagued by allegations of misconduct. Critics accuse Microsoft of encouraging its business partners to become members of various national standards bodies in order to push through votes for approving OOXML. For instance, more than 20 new companies joined the Swedish Standards Institute immediately prior to the organization's vote on OOXML earlier this week. According to Swedish news publication The Local, Microsoft has admitted to sending e-mails to partner companies telling them that they were "expected" to vote in favor of approving OOXML, and that they would receive "market assistance" and "extra support in the form of Microsoft resources" for doing so.

Our policy on blocking should be crafted to strengthen organizations we participate in against gaming, and I worry that a must not without prior approval rule does the opposite. If many members of an SSO were to require blocking votes to be discussed beforehand then the SSO as a whole would be less resistant to this kind of abuse.

[MylesBorins]

@mikesamuel I have to be honest that I'm having a hard time following the logic here.

If many members of an SSO were to require blocking votes to be discussed beforehand then the SSO as a whole would be less resistant to this kind of abuse.

I don't really see how this scales to TC39. Any single member can join and block a proposal. That is the risk. I don't really see how stacking standards bodies with folks to vote has anything to do with the discussion here about if OpenJS reps should block.

I've stated previously that I don't think our delegates should be blocking without building some degree of consensus... since we are very likely to have a mix of folks both for + against the proposal in OpenJS I'm not really sure how we move this forward. Does a lack of clear consensus mean a block is not possible? Do we merely require a certain threshold of +1s? It would seem like it could get fairly complicated fairly quickly here... which is leading me to a potentially more drastic conclusion. Perhaps this shouldn't be a flexible thing... either we allow our delegates to block, or we don't.

It seems to me extremely rare that a controversial block would ever be able to build consensus in OpenJS, maybe that's ok.

[ljharb]

An individual who represents an OpenJS project may not have any way to join TC39 besides this foundation. Why should they be disenfranchised just because they don't have an employer who is willing or able to pay the membership fees?