Document the process for submitting, evaluating, and implementing proposals

[reece]

We should be transparent about how HGVS Nomenclature users may submit proposals, discuss and evaluate proposals, and, if approved, eventually see implementation progress (typically by writing the guidelines).

Strawman proposal:

• Anyone may submit a proposal to Discussions. The proposal is initially considered OPEN and under discussion.
• Anyone may comment on an OPEN proposal.
• The HVNC will evaluate all proposals from time to time. For each proposal, the committee may choose to leave a proposal 1) OPEN for further discussion; 2) REJECTED if the proposal is deemed unworkable, incomplete, or inconsistent with the existing guidelines, or if it is similar to existing or recently considered proposals; or 3) ACCEPTED for drafting.
• When a proposal is ACCEPTED, a GitHub issue is created to track writing for the intended documentation change.
• Writing proceeds as a branch dedicated for the assigned issue. Typically, a PR will eventually be submitted and evaluated. Evaluation of the PR is limited to HVNC members (i.e., not for public discussion), although specific users may be asked for comments when warranted.
• If the PR is eventually merged, the discussion proposal is marked as ADOPTED. If the PR is not merged for any reason (e.g., if we realize that the PR creates unforeseen issues with the nomenclature), the proposal will either be re-opened for more discussion or rejected at the discretion of the committee.

[jfjlaros]

I like the idea of working with pull requests, but may be too technical for some people. Perhaps we can accomplish the same goal by using a release branch or something along those lines for the actual proposal and labels (e.g., the documentation label on this discussion) for the accompanying discussion.

Perhaps we can also think about a separate discussion category for proposals?

[ahwagner]

I think the flow described by @reece is great. The only revision I would propose is to relabel the ACCEPTED state. While this does describe an outcome of the review / approval process that leads to technical drafting, I think it might be more informative to have the label IN DRAFT or APPROVED FOR DRAFT, to avoid potential confusion between ACCEPTED and ADOPTED. Specifically, the use of ACCEPTED could create confusion if the proposal does not ultimately become ADOPTED, due to unforeseen incompatibilities that cause a reversion to OPEN (or even REJECTED) during the draft process.

[reece]

Great. I'm totally in favor. I didn't like APPROVED either, so thanks for fixing it.

DRAFTING sounds better to my ear than IN DRAFT, but that's a trivial distinction.

[reece]

This text is already in our web pages and has been for some time, so any changes should now be a change proposal.