HVNC Discussions and Decisions Process

[ahwagner]

We have a growing backlog of issues to be resolved by committee. Over the last year, several issues have been raised, discussed at length, and then left without resolution. These are periodically raised again, reintroduced, re-discussed, and again left without resolution.

Part of the issue was summarized by @jtdendunnen:

When a proposal is on the agenda, we link to GitHub for all to see the discussions. The consequence is I think that we do not all prepare for the meeting properly but during the meeting start reading the discussions, loose valuable time and start to discuss all over again. I think it would be better a proposal can only get on the agenda when somebody makes a concrete proposal to discuss, something like "based on the discussions on topic # I propose: ...". We can then directly get to the point and hopefully get to an agreement.

This Discussion forum is useful for asynchronous discussion on technical issues (and internal operational issues such as this one) and inviting broader community engagement–all good things. However, we are missing agreed-upon conventions for resolving discussions, and we should decide how we would like to operationalize:

1. Introducing a topic
2. Summarizing an open discussion
3. Constructing a specific proposal
4. Preparing the committee to discuss it
5. Taking a vote
6. Maintaining a decision record

This thread is for proposing and discussing ideas for formalizing the above processes.

[ahwagner]

1. Introducing a Topic

I have found that a detailed introduction of a technical topic by a committee member, using examples, can be very helpful for informing discussion of an issue.

Proposal for discussion

It might be useful that a new topic is first presented to the committee on a call, in a presentation lasting no more than 15 minutes, with an additional 5-10 minutes for follow-up questions and discussion. These introductions will often be by committee members, but could also be invited community participants that have raised issues for discussion. These calls should be recorded and made available to the committee for subsequent review of the topic. The topic should have an associated Discussion thread, using the open label.

[ifokkema]

Perhaps it would be good to start with the Discussion thread and make the presentation optional. This has two advantages;

1. It's easier for somebody else in the community to get something on our agenda. Creating a Discussion is open to everybody (right?) and if we make a habit of properly logging all non-closed discussions in our agenda (writing them all down with their current status, just like we have tasks in there), we always have an overview during our meetings and we can't forget them.
2. Some subjects may be very simple, so they may not need a presentation, and/or somebody external may not want to or be able to come onto our call in the time that's booked for it, which is quite an unforgiving time for anyone in East Asia or Oceania.

[gm-bee]

What is the difference between the 'open label' (is:open) and 'filter:open' (which can be easily selected from a dropdown at top right)? If these are meant to be used differently by us or community, then I suggest choosing a different label, and ensuring other threads are closed or labeled appropriately.

[ifokkema]

What is the difference between the 'open label' (is:open) and 'filter:open' (which can be easily selected from a dropdown at top right)? If these are meant to be used differently by us or community, then I suggest choosing a different label, and ensuring other threads are closed or labeled appropriately.

That's a good point. The labels are explained here, but I agree that they need review after we have a more rigid system for proposals.

[ahwagner]

2. Summarizing an open Discussion

It would be useful to create a brief, public-facing summary of the problem statement and key arguments in lengthy Discussion threads (e.g. #2, #18), to minimize time spent in review of those conversations.

Proposal for discussion

The committee member or community participant leading the discussion should be responsible for creating and maintaining a summary of the problem statement and key arguments before work on a resolution begins. These summaries should not exceed ~1/2 page, and should be added to the originating post for the Discussion.

[ifokkema]

Although this has clear advantages, I can also see the situation where complex discussions with strong statements from both sides (like #18) may be oversimplified in the abstract. I'm all for saving time for everybody, but I realize this could cause issues when one of the parties considers the summary too one-sided. Of course, we can just try this out and see what happens.

[gm-bee]

Although this has clear advantages, I can also see the situation where complex discussions with strong statements from both sides (like #18) may be oversimplified in the abstract. I'm all for saving time for everybody, but I realize this could cause issues when one of the parties considers the summary too one-sided. Of course, we can just try this out and see what happens.

Perhaps in this scenario it would be appropriate to ask for two persons to write a summary - each from an opposing perspective.

[ifokkema]

Perhaps in this scenario it would be appropriate to ask for two persons to write a summary - each from an opposing perspective.

I think that is a good solution!

[ahwagner]

3. Constructing a specific proposal

To effectively vote on a resolution to a Discussion, a specific resolution needs to be proposed for vote.

Proposal for discussion

When a proposal is ready to go to vote, the proposal should include specifics on what specific changes are to be adopted (e.g. what specific text will be added or removed, and to what pages). This should be prepared and sent to the committee at least two full weeks before the session in which a vote will be requested.

[ifokkema]

+1. If needed, complex situations could be split into multiple rounds, e.g., first propose to vote on whether we need to do anything at all; if so, continue with the process of a clear proposal of what should be done. Perhaps this initial vote to have a detailed proposal at all could save time. The opposite could also happen, that opinions are mixed because there is no well-defined proposal. But perhaps documenting the possibility of a two-step approach may benefit us in the future.

[ahwagner]

4. Preparing the committee to discuss a proposal

The committee should be sufficiently prepared to discuss a proposal, and should be given adequate time to do so. I have noticed that preparation for the meeting has often waited until the days immediately prior due to a lack of any agreed timelines for preparing or distributing the agenda.

Proposal for discussion

The draft agenda must be prepared and sent to the committee for review two weeks prior to the meeting. Any topics for which a vote should be considered must be clearly indicated as an upcoming vote on this initial agenda. It is the responsibility of the committee members to review the agenda and any associated proposals up for vote in the two weeks prior to the meeting.

[jfjlaros]

I think we should add a step to allow the committee members to respond in writing prior to discussion. They may want to share a rebuttal or an alternative viewpoint. Both the proposal as well as the responses should be discussed together.

Perhaps we should also describe the community consultation phase in this step.

[gm-bee]

Given that we all have other responsibilities and schedules, I wonder if a preliminary agenda could be made even sooner? Say, within a week after the prior meeting? I reason that not much of what should be discussed changes within that 1.5 months. Committee members will thus have ample time to review and discuss issues offline. With the agenda set ahead, we could then impose a two deadline before each meeting to have formal proposals, summaries, or any other materials prepared and sent around.

[ahwagner]

5. Voting on the proposal

HUGO committee decisions, when not unanimous, are expected be determined by simple majority vote. However, a given committee member may need to be absent during a particular meeting in which a vote is to be held.

Proposal for discussion

Votes should be formalized via an online form (e.g. Google Forms) and the results of these votes maintained as part of the HVNC public record. If a proposal is adopted without unanimous support, a consensus dissenting opinion may be presented by the dissenting members as part of the HVNC public record for the proposal. If the majority opinion is to adopt, the discussion label is changed from open to drafting, and work begins on the specific code changes needed to adopt the recommendation. If the majority opinion is to not adopt, the discussion label is changed from open to rejected.

[ifokkema]

This is a very good idea, to do this through a Google Form. This also allows a member who can't make it to the meeting to review the proposal and vote before the meeting takes place to still get their vote in. I'm not sure I follow this though: what do you mean by "a consensus dissenting opinion may be presented by the dissenting members as part of the HVNC public record for the proposal"? Will any proposal be accepted if 6 out of 11 accept the proposal? And what when some abstain or don't vote within a certain timeframe? E.g., we're 11, 2 didn't vote, 5 voted yes, 4 voted no. Will the proposal then be accepted with a 5 out of 9 score?

[ifokkema]

Also, if the proposal is rejected, can the person who submitted the proposal adapt the proposal and try again? This may be useful when the rejection was because of how something was planned to be corrected on the HGVS website, but it may also create a never-ending story of proposals being discussed again and again.

[ahwagner]

From @jtdendunnen during 10/7 call: current operation on votes is simple majority, so an 11 person committee would need 6 votes to pass a measure.

[ahwagner]

6. Maintaining a decision record

Currently, proposals are kept on the site as Community Consultations, though our current process refers to the use of this Discussion forum for new proposals.

Proposal for discussion

We move the SVD WG001 - WG010 records to GitHub Discussions, and apply the adopted / drafting / rejected labels as indicated in our community consultation process. Decision records are maintained on the GitHub platform and linked via label filters on the HGVS website consultation page.

[ifokkema]

I'm not sure about this. The current SVD WG pages are often linked to from the docs or are even used as extensions to our documentation (especially when the proposal has been open for a long time). Also, not all discussions may "deserve" a SVD WG "status" simply because they're in the first phase and may be shot down immediately (e.g., #133) or because they're kind of questions, actually (#161). The SVD WG pages, as far as I know, were the place for proposals that made it through all initial steps; the committee agreed that something should be done, somebody (often from the committee) came up with a detailed proposal of how to adapt the documentation, and then community was asked to vote on it. So, I kind of feel these are two different things, and we shouldn't mix them by moving the older SVD WG pages to GitHub Discussions. We definitely can create SVD WG pages from Discussions that have made it through the first steps of the process, but I don't see any community voting described in this page; do we still want to keep this?