additional details needed on adjudication by oversight committee

[lhawthorn]

For any who are curious about the timing and content of this issue, the Oversight Committee plans to convene tomorrow and decide on the outcome of community issue #279, hence me realizing we didn't have the above details in place.

Right now we have a very good description of the duties of the Oversight Committee.

What we do not have are some guidelines around meetings/decision making that should be included in this light weight charter. For example:

• What constitutes quorum for a meeting held by the oversight committee
• What constitutes quorum for a decision required from the oversight committee
• If a vote is required, what is our process therefore

And reading all the above, we probably require a secretary role, but I have no wish to get that fussed about making our light weight charter more heavy weight this early in our project history. I am simply noting it as a need. Our chair can record votes, etc.

I, for one, am also comfortable with our chair deciding the process for voting ad hoc for the moment, but other members of the OC may be less comfortable with that. We should determine voting process real soon now^TM, though, because some discussions that seem simple questions can be contentious and/or not easily resolved due to strong opinions, strongly held.

I am adding all the members of the OC that we might discuss here and, hopefully, come to rapid consensus so we can update our documentation.

[lhawthorn]

My concrete proposal on the above:

• Meetings make take place via phone call, video conference call, or real-time chat such as Slack.
• Some decisions will be made asynchronously, e.g. via discussion in GitHub issues (like this one), on a mailing list, or in real-time chat.
• Quorum for a meeting where talk occurs real-time shall be considered 4 out 7 members of the OC. In an ideal world, all members of the OC are present.
• Decision making by the OC requires the at least 4 out of the 7 OC members to agree to the decision outcome, whether the decision is made in real-time chat, via email, or in meeting.
• It is welcome and encouraged that an OC member who cannot be present for discussion submit their thoughts/vote to the committee via email or real-time chat prior to the meeting so we have their voice recorded and their thoughts available when available members of the OC convene for discussion.
• In truly exceptional circumstances, a smaller number of OC members can push forward a decision for the project due to extreme need. How many OC members must weigh in and whose voices are 100% required is at the decision of the OC chair. It is expected that in the case of truly exceptional circumstances, the chair has exhausted all reasonable means of convening quorum of the OC to make the decision. (All reasonable means constitutes e.g. sending SMS communications to OC body to get their attention quickly on the decision that must be made.)

While we may wish to revisit the above proposed governance details real soon now^TM, I believe they will suffice for now in this stage of our project's evolution.

[danmcp]

+1 to @lhawthorn's proposal. Thanks for putting it together.

[russellb]

Just to recap where we have existing related content:

• The governance doc has a section called Decision making at the InstructLab organization level. This covers some specific expectations of what it takes to approve a certain type of change (majority or supermajority of the O.C.).
• The README.md in the dev-docs repo has a Governance section. This clarifies two things: the O.C. are the ultimate owners of the repo, and any change in this repo can be flagged as requiring a full O.C. vote.

In the case of changes to a file in dev-docs or O.C. owned content in the community repo, we have the GitHub pull request workflow available to us to capture our votes. I really like this as it's very explicit and nicely capture the history of a discussion and decision along with the history of the associated content.

I've been interpreting feedback on issues as a lighter-weight mechanism for a consensus check, though not as a way to capture a formal vote on important matters. It's a bit less clear.

You make great points that the definition of quorum for live discussions that may result in decisions.

In general I'm happy with the text you've written here. Would you be willing to push it forward as a PR against the governance document? That way we can record O.C. approval via the pull request. Per our governance, such a change requires a supermajority of the O.C. to vote in favor (approve the PR).

[lhawthorn]

Will create this as a PR against the governance doc real soon now but have to run to a personal appointment this afternoon. This issue / PR is non-gating on our OC decision on issue #279, obviously, but noting that it's better to get this refactored as PR to the governance docs sooner rather than later.

[lhawthorn]

Work in progress to address dev-docs issue 91, once merged will update with this info for the governance doc.

[github-actions]

This issue has been automatically marked as stale because it has not had activity within 90 days. It will be automatically closed if no further activity occurs within 30 days.