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?

[MylesBorins]

@ljharb I disagree with your premise that it is disenfranchising and that a primary way to engage in the committee is through having the ability to block

[ljharb]

In the case of proposal advancement, it’s not in fact blocking. Specifically, without consensus here, the foundation doesn’t have consensus for advancement, and as such, should explicitly note that in plenary.

[MylesBorins]

@ljharb the action is "blocking consensus for advancement"... that action should have consensus. I guess what we are talking about here is what the default mode should be... but this is the difference between consensus and unanimity. You don't need everyone to say "yes" to have consensus... you simply need no one to be objecting.

An objection in turn then actively blocks the consensus for advancement. This type of objection comes at a cost... social + physical (time). This type of action should not happen without consensus at the foundation, is the premise I've been saying this entire time.

Letting the committee know that OpenJS does not have consensus for advancement but is not actively blocking seems like a good middle ground in the case where we do not have consensus on the block. That could be enough to encourage other delegates to block. In lieu of anyone else blocking, and not having consensus to block in OpenJS, it would seem to me that we should not be the lone blocker.

[devsnek]

I think if a delegate has technical concerns that have some bearing in reality, it's reasonable for them to block on that without having to muster up the consensus of the org. However if the decision is more principled than that (for example blocking a proposal from stage 1 because they don't think the feature belongs in js or whatever) that requires more consensus.

[MylesBorins]

@devsnek a TC39 delegate of OpenJS is a representative of our foundation at the committee. When opinions are expressed and shared it is important to be able to distinguish between those of the individual and those of the organization.

I think if a delegate has technical concerns that have some bearing in reality, it's reasonable for them to block on that without having to muster up the consensus of the org

This is an extremely difficult thing to gauge, as we may not have consensus that the technical concerns have bearing in reality... that is subjective.

I think an important premise here, which we may not agree on, is the purpose and role of a OpenJS rep at TC39. A couple I can think of right away:

1. Represent the views / opinions of OpenJS to the committee
2. Giving access to the committee to our community members
3. Bring subject matter expertise the committee would otherwise not have.

If a subject matter expert is unable to build some degree of consensus within the foundation of their position, and that we should indeed be blocking a proposal I do not believe that it aligns with the first goal of representing the view / opinions of OpenJS to the committee.

I also don't think that the need to build internal consensus works against the goal of giving access to the committee, folks can attend and participate in the meetings. I'm not even against individuals bringing their opinions and presenting them. If we do not have consensus around a block I see no concern with an OpenJS delegate making it clear to Tc39 that they, and potentially certain projects, have concerns with the proposal and while they are not blocking as there is not foundation wide consensus they would like to encourage others to reconsider the decision.

What I am not ok with is a representative of the foundation taking a nuclear option at the committee due to their own opinions that have not built consensus.

[littledan]

I was really hoping that the OpenJSF representation at TC39 could be focused on gathering feedback from OpenJSF projects (and Node.js in particular) and bringing that to committee, ensuring that they're represented. One part is getting people in the room (which I'm glad we've accomplished), and another, equally important part is ensuring the constituency is represented.

It's been quite confusing for TC39 in the past to interpret what's going on when people talk with the voice of projects without having had some broader discussion with project participants. I've tried to gather broad feedback a little bit when I presented on TC39 topics at past Node Collaborator Summits, and was hoping that this would become more institutionalized with OpenJSF joining TC39.

This discussion comes at a really unfortunate time, where I have an obvious conflict of interest due to #91 . My intuition on what OpenJSF does sort of aligns with @MylesBorins FWIW. Nevertheless, consensus, blocking, and TC39 are all social processes; I think that, regardless of what we say in this thread, given their history in committee and past invited expert status, @ljharb and @devsnek will be able to say "I object" and it will be taken seriously. We don't have any written rules on whether invited experts can or can't object, so there you go.

[devsnek]

To be clear, I'm not planning to object if I don't feel like I'm comfortably within our expectations of delegates.

[MylesBorins]

So a thought that I'm having right now. The conversation in #91 albeit it dense is actually quite healthy and good to have as a foundation. It is ensuring that multiple projects are getting a chance to review a controversial proposal that has the potential to significantly affect their projects.

I'm still not at a conclusion as to how / when a "block" should come from our foundation reps... but I wanted to point out that I am glad the process as it currently exists is creating more visibility and engagement from our projects.

[ljharb]

+1 - to be clear, with anything knowable in advance, this is exactly what we should be doing.

[dtex]

I believe @sendilkumarn summed the takeaway here in MEMBER_EXPECTATIONS.md quite well. It's a nuanced topic that will change shape over time. If revisions are necessary I propose they be framed in the context of a PR against that document.