Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP - Improvements toward Addressing #173 #240

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Conversation

jorydotcom
Copy link
Member

This PR attempts to update our documents to reflect deeper thinking and general consensus around participation expectations for our SMEs.

Governance.md has been cleaned up & simplified.
Member Expectations has been built out to reflect some of the process we've developed as well as to distinguish between what we are looking for from our official delegates as well as how the broader community can start to engage with us.

Cleans up out-of-date and/or inaccurate info in governance.md; partially resolves #173
Re-organizes document under clearer headings and disambiguates expectations for those who are official Representatives vs. "invited experts" from a given community.
@jorydotcom jorydotcom added the standards-agenda To be discussed in bi-weekly meeting label Jun 5, 2023
@tobie
Copy link
Contributor

tobie commented Jun 6, 2023

This LGTM.

Copy link
Contributor

@tobie tobie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some thoughts and a specific change request to match the CPC charter.

* The relevance and potential impact of the work to OpenJS Foundation Projects
* Any participation costs (e.g. membership dues) needed

Note that new liaisons or memberships must be discussed with OpenJS Foundation Executive Director Robin Ginn and must be approved by the Board of Directors.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Note that new liaisons or memberships must be discussed with OpenJS Foundation Executive Director Robin Ginn and must be approved by the Board of Directors.
Note that new liaisons or memberships must be approved by the CPC.

My understanding is this role is actually delegated to the CPC via its charter (see § 5.15)

The CPC serves as the OpenJS Foundation's primary technical liaison body with external open source projects, consortiums and groups and is also responsible for ensuring that the OpenJS Foundation has appropriate technical participation in standards bodies by finding an encouraging members from individual projects to participate in these bodies.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update this: this group is empowered to decide whether to participate; ED will be required if a signature on legal agreement; Board approval may be required if $$ is required for the membership.

* Commit to ongoing development and learning best practices for governing.
* Follow the code of conduct of both the Open JS Foundation, _and_ the organization they are a representative to.
### Representatives and Decision-making
Some of OpenJS Foundation's memberships and liaison relationships permit Representatives to participate in their formal decision-making processes (e.g. voting). Representatives should disclose any vote to the Standards Working Group, and provide a recommendation. If the Representative has an objection or plans to cast a dissenting vote, they should express it as early as possible to ensure there is ample time to discuss and reach consensus on the intended approach.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's important to make a distinction between whether the person casting the vote is operating as a representative of OpenJSF in that particular vote or in a personal capacity.

For example, W3C's AC rep voting in an AC vote is representing OpenJSF's position and should honor the group's consensus. If they dissent and refuse to cast that vote, they should resign from them position or be demoted.

On the other hand, if the same AC rep is then further elected in an individual capacity to say an AB or TAG role, votes they may cast in that context aren't subject to this group consensus. Actually, this group might not even be privy to the content of the vote.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Some of OpenJS Foundation's memberships and liaison relationships permit Representatives to participate in their formal decision-making processes (e.g. voting). Representatives should disclose any vote to the Standards Working Group, and provide a recommendation. If the Representative has an objection or plans to cast a dissenting vote, they should express it as early as possible to ensure there is ample time to discuss and reach consensus on the intended approach.
Some of OpenJS Foundation's memberships and liaison relationships permit Representatives to participate in their formal decision-making processes (e.g. voting). Representatives should disclose any vote to the Standards Working Group, and provide a recommendation. If the Representative has an objection or plans to cast a dissenting vote while representing the Foundation, they should express it as early as possible to ensure there is ample time to discuss and reach consensus on the intended approach.

Copy link
Contributor

@tobie tobie Jun 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That a good step forward. I'd be a little more prescriptive:

Suggested change
Some of OpenJS Foundation's memberships and liaison relationships permit Representatives to participate in their formal decision-making processes (e.g. voting). Representatives should disclose any vote to the Standards Working Group, and provide a recommendation. If the Representative has an objection or plans to cast a dissenting vote, they should express it as early as possible to ensure there is ample time to discuss and reach consensus on the intended approach.
Some of OpenJS Foundation's memberships and liaison relationships permit Representatives to participate in their formal decision-making processes (e.g. voting). Representatives should update the Standards Working Group of such opportunities that are relevant to the interests of OpenJSF or its projects well ahead of time so that the group is able to reach consensus on the intended approach. The Representative must represent the group's decision and abstain in case the group hasn't been able to reach consensus.

I feel that this covers dissent (as the WG won't reach consensus in case the Rep disagrees with the majority).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit confused.

While wearing the Foundation hat, we've already discussed and decided on how objections work - brought to Standards beforehand, and if it can't be for any reason, best judgement can be used and may need defending at the next Standards meeting.

While not representing the Foundation, an individual is under no obligation to interact with the Standards group about objections, even if they're a member of the Standards group.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I understand the source of confusion.

Following some of the discussion and proposed changes in #239, I was using the term Representative in a much narrower way, i.e. to specifically mean when a person is representing OpenJSF (e.g. "@jorydotcom is OpenJSF's W3C Representative") but not when a person is operating in a working group in more of an Invited Expert capacity.

Would it make sense to distinguish these roles more precisely? I think @rginn used the term subject matter expert (SME) in a related issue which is more common than Invited Expert. Would that work for folks?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While wearing the Foundation hat, we've already discussed and decided on how objections work - brought to Standards beforehand, and if it can't be for any reason, best judgement can be used and may need defending at the next Standards meeting.

Sorry, I didn't see this documented anywhere. To be clear, I much prefer this as a solution. I think trusting that people will do the right thing and be proactive about building consensus if the topic feels more contentious is the right thing to do. However, I don't think it is acceptable for a Representative of the OpenJSF in the narrow sense (i.e. not an SME), to vote against the consensus of the WG (and if the WG can't get to consensus, the Rep should abstain).

While not representing the Foundation, an individual is under no obligation to interact with the Standards group about objections, even if they're a member of the Standards group.

100%. We should also make very clear that the persons is acting in an SME capacity in that case and not representing OpenJSF.

Copy link
Contributor

@tobie tobie Jun 8, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, your last comment didn't show up until I finished writing the above.

A person might be operating as a delegate of their employer while still being associated with OpenJS, and as such they don't need to answer to the Standards WG, so it's got nothing to do with IE/SME status imo.

I think we're saying the same thing but don't agree on terms.

I'm suggesting there are two kinds of roles:

  1. Someone representing the opinion of the OpenJSF as a whole. They need to get consensus from the WG (before the fact if the topic is contentious). Maybe we should call them Liaisons instead of Representatives.
  2. Someone participating in standardization activities but who isn't representing OpenJSF's position. They don't need to get consensus from the WG at all. I was suggesting to call those SMEs. (Note: We might need to make a distinction between folks who are affiliated with OpenJSF in those circumstances and folks who are just loosely associated with it, but maybe we don't).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See #84 for previous discussion.

I completely agree with your two roles, and I think that's basically what #84 came to decide :-) we can bikeshed the terms later.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome. I wasn't aware of that thread. Thanks for sharing. I don't really care what the terms are either. It would just be good if we could avoid them creating more confusion by overlapping with common terms already used by SDOs (e.g. delegate which means completely different things for Ecma and OSI).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it does seem like we need a mapping table 😄

representing the foundation and the consensus/expectations that we’ve built to those organizations (if they are representing
OpenJS Foundation).
Representatives must also conduct themselves in a professional and respectful manner. General guidelines include:
* Avoid invoking multiple "roles" when discussing challenging topics. This helps avoid [appeals to authority](https://en.wikipedia.org/wiki/Argument_from_authority) or the allusion that one's opinion is fully shared by multiple groups.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a little confused about this first bullet point. My initial reaction was to try and spin it the other way round, e.g.: "Always be specific about whose position you are representing." But that then is just a repeat of the first paragraph of this section. Furthermore, if you are representing the consensus of multiple groups, or there is documented consensus that you can point to, that seems valuable information to share. So I guess what you're alluding to is listing your titles and then trying to pass personal opinion as somehow shared by these different organizations? That's just so unethical. I don't even know where to begin.

Could we maybe reaffirm (1) being explicit about whose position is being represented, (2) not speculating about other group's position, (3) never, in any circumstances trying to pass personal or employer-held positions as group consensus?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This addresses the importance of avoiding "pulling rank" and misrepresenting others' positions. You're right that there's nothing wrong with "documented consensus that you can point to" and this can help clarify things and/or prevent bikeshedding.

MEMBER_EXPECTATIONS.md Outdated Show resolved Hide resolved
Since many members are often a part of one or more projects in the foundation, feel free to discuss it with the members
if there is a potential conflict while representing. The representative can raise an issue and discuss them during
the Standards Working Group meeting.
## Expectations for Representatives
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could we consider starting off by saying that consensus of the Standards WG allows a Representative to represent the position of OpenJSF as a whole on a particular topic? And that conversely, unless Rep has said consensus, you're not in a capacity to represent OpenJSF's position on that topic?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

tl;dr: this would effectively prevent participation

This would be a very high bar to meet. Organization representatives are practically always representing their organization's positions on topics. For example, where participants in W3C working groups or delegates in Ecma committees represent an organization, those are the terms of their participation. Strictly speaking, they do not participate in a personal capacity at all, so, at least in matters pertaining to normative topics, they are unable to represent a personal position, and as such are exclusively representing the position of their organization.

The OpenJS standards group does not have time to get consensus on all topics that may come up at standards bodies, and would very often find it difficult to even get a quorum of members that could speak to a given proposal. We also typically only know topics one or two weeks in advance, if that.

Copy link
Member

@ctcpip ctcpip May 29, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

having read some of your comments further below, it sounds like you may be referring to things at, for example, the AC (W3C) or GA (Ecma) level rather than at the WG or TC level. I think this section on member representation of the OpenJS standards group refers to participation in WGs/TCs.

in any case, it's good to be on the same page one way or the other

Copy link

@Ethan-Arrowood Ethan-Arrowood left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All looks good here. As someone unfamiliar with policy speak, this reads clearly enough for me to understand my own membership expectations, and the expectations of others too. Nice work!

MEMBER_EXPECTATIONS.md Outdated Show resolved Hide resolved
Co-authored-by: Ethan Arrowood <ethan@arrowood.dev>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
standards-agenda To be discussed in bi-weekly meeting
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants